public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: James Bergstra <bergstrj@iro.umontreal.ca>
To: Gerard Jungman <jungman@lanl.gov>
Cc: gsl-discuss@sourceware.org
Subject: Re: containers tentative design summary
Date: Thu, 29 Oct 2009 21:40:00 -0000	[thread overview]
Message-ID: <7f1eaee30910291440r58566738l8105bc0d8faf849b@mail.gmail.com> (raw)
In-Reply-To: <1256848906.19313.25.camel@manticore.lanl.gov>

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

  reply	other threads:[~2009-10-29 21:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-05 10:12 Gerard Jungman
2009-10-05 14:50 ` James Bergstra
2009-10-05 23:00   ` Gerard Jungman
2009-10-05 23:45     ` James Bergstra
2009-10-06 19:59       ` Gerard Jungman
     [not found]     ` <645d17210910060537s762d6323pfd2bec8590ad28e9@mail.gmail.com>
2009-10-06 20:02       ` Gerard Jungman
2009-10-23 21:28     ` Brian Gough
2009-10-27 23:06       ` Gerard Jungman
     [not found]         ` <7f1eaee30910271628h70785125m68e47c7a7b5c25b7@mail.gmail.com>
2009-10-27 23:49           ` Gerard Jungman
2009-10-29 18:06         ` Brian Gough
2009-10-29 20:41           ` Gerard Jungman
2009-10-29 21:40             ` James Bergstra [this message]
2009-10-30 16:54               ` Brian Gough
2009-10-30 16:54             ` Brian Gough
2009-10-05 23:04   ` some general questions Gerard Jungman
2009-10-06 16:21     ` Brian Gough
2009-10-06 20:32       ` Gerard Jungman
2009-10-10 14:45         ` Tuomo Keskitalo
2009-10-24 11:16           ` Brian Gough
2009-10-14 20:00         ` Brian Gough
2009-10-15 18:39           ` Tuomo Keskitalo
2009-11-03 19:44 containers tentative design summary Gerard Jungman
2009-11-09 20:41 ` Brian Gough
2009-11-09 23:06   ` Gerard Jungman
2009-11-14 15:25     ` Brian Gough
2009-11-15  9:13       ` Tuomo Keskitalo
2009-11-15 16:44         ` Jonathan Underwood
2009-11-15 18:41           ` Robert G. Brown
2009-11-16 11:56         ` Brian Gough
2009-11-20  9:37 Justin Lenzo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f1eaee30910291440r58566738l8105bc0d8faf849b@mail.gmail.com \
    --to=bergstrj@iro.umontreal.ca \
    --cc=gsl-discuss@sourceware.org \
    --cc=jungman@lanl.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).