From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2151 invoked by alias); 9 Nov 2009 23:06:10 -0000 Received: (qmail 2143 invoked by uid 22791); 9 Nov 2009 23:06:10 -0000 X-SWARE-Spam-Status: No, hits=-10.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: sourceware.org Received: from proofpoint2.lanl.gov (HELO proofpoint2.lanl.gov) (204.121.3.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Nov 2009 23:06:06 +0000 Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by proofpoint2.lanl.gov (8.14.3/8.14.3) with ESMTP id nA9N64Vm001539 for ; Mon, 9 Nov 2009 16:06:04 -0700 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay1.lanl.gov (Postfix) with ESMTP id BCFC7181B33 for ; Mon, 9 Nov 2009 16:06:04 -0700 (MST) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id BBC577D00B3 for ; Mon, 9 Nov 2009 16:06:04 -0700 (MST) X-NIE-2-Virus-Scanner: amavisd-new at alvie-mail.lanl.gov Received: from [130.55.124.157] (manticore.lanl.gov [130.55.124.157]) by alvie-mail.lanl.gov (Postfix) with ESMTP id A353C7D00B1 for ; Mon, 9 Nov 2009 16:06:04 -0700 (MST) Subject: Re: containers tentative design summary From: Gerard Jungman To: gsl-discuss@sourceware.org In-Reply-To: References: <1257277549.19313.118.camel@manticore.lanl.gov> Content-Type: text/plain Date: Mon, 09 Nov 2009 23:06:00 -0000 Message-Id: <1257808063.11663.3.camel@manticore.lanl.gov> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2009-11-09_13:2009-10-29,2009-11-09,2009-11-09 signatures=0 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/msg00040.txt.bz2 On Fri, 2009-11-06 at 14:42 +0000, Brian Gough wrote: > > 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. How does this comment help us in designing a C library? > 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. How does this solve the const-ness problem? -- G. Jungman