From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31230 invoked by alias); 9 Nov 2009 20:41:55 -0000 Received: (qmail 31222 invoked by uid 22791); 9 Nov 2009 20:41:54 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_50,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.network-theory.co.uk (HELO mail.network-theory.co.uk) (66.199.228.187) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Nov 2009 20:41:50 +0000 Date: Mon, 09 Nov 2009 20:41:00 -0000 Message-ID: From: Brian Gough To: Gerard Jungman Cc: gsl-discuss@sourceware.org Subject: Re: containers tentative design summary In-Reply-To: <1257277549.19313.118.camel@manticore.lanl.gov> References: <1257277549.19313.118.camel@manticore.lanl.gov> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Message-Mac: eba5eb7a7d0d158087c997ea53e9ab9e Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2009-q4/txt/msg00039.txt.bz2 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