From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14753 invoked by alias); 29 Oct 2009 21:40:37 -0000 Received: (qmail 14742 invoked by uid 22791); 29 Oct 2009 21:40:35 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-yx0-f180.google.com (HELO mail-yx0-f180.google.com) (209.85.210.180) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Oct 2009 21:40:32 +0000 Received: by yxe10 with SMTP id 10so2348110yxe.12 for ; Thu, 29 Oct 2009 14:40:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.180.3 with SMTP id h3mr1216337anp.145.1256852430544; Thu, 29 Oct 2009 14:40:30 -0700 (PDT) In-Reply-To: <1256848906.19313.25.camel@manticore.lanl.gov> References: <1254708349.18519.4.camel@ForbiddenPlanet> <7f1eaee30910050750l738876b1p41e6bd8ae5aa6d16@mail.gmail.com> <1254783367.28192.98.camel@manticore.lanl.gov> <1256684949.19313.2.camel@manticore.lanl.gov> <1256848906.19313.25.camel@manticore.lanl.gov> Date: Thu, 29 Oct 2009 21:40:00 -0000 Message-ID: <7f1eaee30910291440r58566738l8105bc0d8faf849b@mail.gmail.com> Subject: Re: containers tentative design summary From: James Bergstra To: Gerard Jungman Cc: gsl-discuss@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00031.txt.bz2 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 wrote: > On Thu, 2009-10-29 at 16:51 +0000, Brian Gough wrote: >> At Tue, 27 Oct 2009 17:09:09 -0600, >> > =A0 /* claims not to twiddle v.data[] */ >> > =A0 gsl_some_typical_const_function((const gsl_const_vector *) &v); >> > >> >> The problem with anything involving explicit casts is that we lose >> type-safety. =A0If 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 > > > --=20 http://www-etud.iro.umontreal.ca/~bergstrj