This is the mail archive of the gsl-discuss@sourceware.org mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: containers tentative design summary


Taking a step back, why do we need to have const and non-const
versions of the struct?  I think we can get away with just having a
non-const version.

If the purpose of using const float * things is to permit compiler
optimizations, then this detail can be hidden at the level of using
gsl_vector.  Const-ness can be limited to use in functions that take
raw types (float *, int, etc.) and actually do algorithmic work.  Like
cblas functions.  C will automatically upcast from non-const pointers
to const pointers by the usual rules.

If the purpose is to protect the user from accidentally messing around
with data then, as Gerard suggests, maybe we shouldn't bother.  This
is not a battle that we can win in C.  Good naming conventions for
functions, which indicate the arguments that will be modified, is the
most that a C library is expected to provide.

Providing only non-const versions of these structs makes a lot of
problems disappear right?

All matrices are born non-const.

James

On Thu, Oct 29, 2009 at 4:41 PM, Gerard Jungman <jungman@lanl.gov> wrote:
> On Thu, 2009-10-29 at 16:51 +0000, Brian Gough wrote:
>> At Tue, 27 Oct 2009 17:09:09 -0600,
>> > ? /* claims not to twiddle v.data[] */
>> > ? gsl_some_typical_const_function((const gsl_const_vector *) &v);
>> >
>>
>> The problem with anything involving explicit casts is that we lose
>> type-safety. ?If v is not a vector there's no way to detect the error,
>> which closes the hole of const-related errors but opens another one.
>
> General statement: C is a weakly-typed language.
>
> Consequence: We cannot prevent people from loading the gun,
> pointing it at their heads, and pulling the trigger. They
> are always free to do this. In fact, it is a tenet of C
> that you should trust people to do what they need to do.
>
> You will never succeed in making an interface "safe" in
> this sense. However, you _can_ make an interface intuitive
> and safe to use in a normal manner. I don't think you
> can ask any more of C.
>
>
> Tangential but powerful argument: I talked to Tanmoy about it.
> He considers this normal and useful. The benefits outweigh the
> defects. "Just do it and stop worrying about it" is an exact quote.
>
> Everybody who understands C, including the standards committee,
> knows that const-ness is screwed up, because of the way it was
> tacked on to the old language. This is one of a small number of
> recognized ways to get around the defects in the language.
>
> --
> G. Jungman
>
>
>



-- 
http://www-etud.iro.umontreal.ca/~bergstrj


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]