Re: containers tentative design summary

[Gerard Jungman <jungman at lanl dot gov>]

On Fri, 2009-10-30 at 16:03 +0000, Brian Gough wrote:
> 
> I don't think this interface is safe to use in a normal manner it it
> requires an explicit cast to pass a non-const object to a function
> accepting the const version.

You really do want to use a strongly-typed language.
But C is not it.

> Any error in the argument of an explicit
> cast is undetectable.

If the container stuff is designed properly,
then it hardly matters, because it just works
anyway, for any container type for which the
operation is meaningful.

If your world were limited to the vector and
const_vector types, as in the example, it wouldn't
matter what you did, the result would obviously be correct.

If, on the other hand, you try to jam your externally-defined
square peg into the GSL round hole, it could be bad. So?
How is this surprising?

If you think about the full container design, you will see that
it is possible to design a rational and useful system, where the
types fully inter-operate. The basis would be a generic multi-array
implementation. The vector example given was purely to address the
const-ness problem, and I think it does that.

It's not enough to scare people with notions of the wrong-cast
bogeyman. You should explain how these things can happen. When
you face the fear directly, you may realize it is not such a
big deal after all.


> We should not require the use of explicit casts
> for common operations, it would endorse a bad practice.

Actually, it endorses a "C" practice. It's "bad"-ness is
a theological issue. See the attached paper by Siff et al.,
[sorry, I tried to attach the paper, but the list won't
 accept a message with an attached pdf; the paper is
 "Coping with Type Casts in C", 1999 Bell-Labs report]
where this construct is labeled "physical sub-typing".
They give data on actual usage in the world, see Table 1.

The whole business is far from perfect. But, again, if you
want to do things in C, you need tricks, because the
language has no support for expressing relationships
between types.


In my opinion, the idea of a container library in C is
somewhat brain-damaged anyway. But here we are...


There are other ways to design containers. Some ways
involve radical change to the GSL container methodology.
For example, the const-ness of the data pointer could be
explicitly divorced from the layout meta-data which constitutes
the rest of the container. After all, the headaches with const-ness
come from the simple fact that the data pointer is embedded in the
struct and it conflates the semantics in un-desirable ways.

Example separation:

  typedef struct {
    size_t size;
    int    stride;
  } gsl_vector_layout;

  gsl_fnc_on_stuff(double * d, const gsl_vector_layout * l);
  gsl_fnc_on_const_stuff(const double * d, const gsl_vector_layout * l);


There are many ways to skin the cat. But a change like this
would effect all gsl interfaces involving container types.
It also has other noticeable imperfections.

Choose the form of the destroyer...

--
G. Jungman