From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7603 invoked by alias); 3 Nov 2009 19:44:14 -0000 Received: (qmail 7595 invoked by uid 22791); 3 Nov 2009 19:44:13 -0000 X-SWARE-Spam-Status: No, hits=-9.4 required=5.0 tests=AWL,BAYES_05,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: sourceware.org Received: from proofpoint1.lanl.gov (HELO proofpoint1.lanl.gov) (204.121.3.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Nov 2009 19:44:09 +0000 Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by proofpoint1.lanl.gov (8.14.3/8.14.3) with ESMTP id nA3Ji1dR023750 for ; Tue, 3 Nov 2009 12:44:06 -0700 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 9651D15CB6FE for ; Tue, 3 Nov 2009 12:43:48 -0700 (MST) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 950E77D00A5 for ; Tue, 3 Nov 2009 12:43:48 -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 858657D00A3 for ; Tue, 3 Nov 2009 12:43:48 -0700 (MST) Subject: Re: containers tentative design summary From: Gerard Jungman To: gsl-discuss@sourceware.org Content-Type: text/plain Date: Tue, 03 Nov 2009 19:44:00 -0000 Message-Id: <1257277549.19313.118.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-03_11:2009-10-29,2009-11-03,2009-11-03 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/msg00035.txt.bz2 On Fri, 2009-10-30 at 16:03 +0000, Brian Gough wrote: > > I don't think this interface is safe to use in a normal manner it it > requires an explicit cast to pass a non-const object to a function > accepting the const version. You really do want to use a strongly-typed language. But C is not it. > Any error in the argument of an explicit > cast is undetectable. If the container stuff is designed properly, then it hardly matters, because it just works anyway, for any container type for which the operation is meaningful. If your world were limited to the vector and const_vector types, as in the example, it wouldn't matter what you did, the result would obviously be correct. If, on the other hand, you try to jam your externally-defined square peg into the GSL round hole, it could be bad. So? How is this surprising? If you think about the full container design, you will see that it is possible to design a rational and useful system, where the types fully inter-operate. The basis would be a generic multi-array implementation. The vector example given was purely to address the const-ness problem, and I think it does that. It's not enough to scare people with notions of the wrong-cast bogeyman. You should explain how these things can happen. When you face the fear directly, you may realize it is not such a big deal after all. > We should not require the use of explicit casts > for common operations, it would endorse a bad practice. Actually, it endorses a "C" practice. It's "bad"-ness is a theological issue. See the attached paper by Siff et al., [sorry, I tried to attach the paper, but the list won't accept a message with an attached pdf; the paper is "Coping with Type Casts in C", 1999 Bell-Labs report] where this construct is labeled "physical sub-typing". They give data on actual usage in the world, see Table 1. The whole business is far from perfect. But, again, if you want to do things in C, you need tricks, because the language has no support for expressing relationships between types. In my opinion, the idea of a container library in C is somewhat brain-damaged anyway. But here we are... 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. After all, the headaches with const-ness come from the simple fact that the data pointer is embedded in the struct and it conflates the semantics in un-desirable ways. Example separation: typedef struct { size_t size; int stride; } gsl_vector_layout; gsl_fnc_on_stuff(double * d, const gsl_vector_layout * l); gsl_fnc_on_const_stuff(const double * d, const gsl_vector_layout * l); There are many ways to skin the cat. But a change like this would effect all gsl interfaces involving container types. It also has other noticeable imperfections. Choose the form of the destroyer... -- G. Jungman