public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Brian Gough <bjg@gnu.org>
To: Gerard Jungman <jungman@lanl.gov>
Cc: gsl-discuss@sourceware.org
Subject: Re: containers tentative design summary
Date: Mon, 09 Nov 2009 20:41:00 -0000	[thread overview]
Message-ID: <m3639nemv3.wl%bjg@network-theory.co.uk> (raw)
In-Reply-To: <1257277549.19313.118.camel@manticore.lanl.gov>

At Tue, 03 Nov 2009 12:45:49 -0700,
Gerard Jungman wrote:
> Actually, it endorses a "C" practice. It's "bad"-ness is
> a theological issue. See the attached paper by Siff et AL.,

Ok, I have read the paper now.  I do think the practice of casting
described there is rather dated.  When people had no viable
alternative to C, they had to resort to such tricks.  It is not
something that should be encouraged today -- programs should either be
written safely, following the rules of type-checking in C, or be
written in another language.

Our approach is actually described in the paper under the "first
member" section, in the &(cp.p) example -- although they don't point
out that it's the only one that doesn't require a cast and can be
checked by the compiler, unlike all the others.

> 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.

That is more interesting theoretically.  From a practical point of
view, I think we have to restrict ourselves to solutions where the
data pointer and the metadata are a single object though.

-- 
Brian Gough

  reply	other threads:[~2009-11-09 20:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-03 19:44 Gerard Jungman
2009-11-09 20:41 ` Brian Gough [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2009-11-20  9:37 Justin Lenzo
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
2009-10-30 16:54               ` Brian Gough
2009-10-30 16:54             ` Brian Gough

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=m3639nemv3.wl%bjg@network-theory.co.uk \
    --to=bjg@gnu.org \
    --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).