From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7044 invoked by alias); 19 Aug 2014 09:19:31 -0000 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 Received: (qmail 7010 invoked by uid 89); 19 Aug 2014 09:19:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: rgout06.bt.lon5.cpcloud.co.uk Received: from rgout06.bt.lon5.cpcloud.co.uk (HELO rgout06.bt.lon5.cpcloud.co.uk) (65.20.0.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Aug 2014 09:19:28 +0000 X-CTCH-RefID: str=0001.0A090207.53F3169E.006B,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-Junkmail-Premium-Raw: score=27/50,refid=2.7.2:2014.8.19.72420:17:27.888,ip=31.53.17.199,rules=__MOZILLA_MSGID, __HAS_MSGID, __SANE_MSGID, __HAS_FROM, __PHISH_FROM2, __FRAUD_WEBMAIL_FROM, __USER_AGENT, __MOZILLA_USER_AGENT, __MIME_VERSION, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __CTE, __SUBJ_ALPHA_NEGATE, __FORWARDED_MSG, BODY_SIZE_1300_1399, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, SXL_IP_DYNAMIC[199.17.53.31.fur], HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __PHISH_FROM, __PHISH_SPEAR_STRUCTURE_1, RDNS_SUSP, BODY_SIZE_2000_LESS, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS, NO_URI_FOUND X-CTCH-Spam: Unknown Received: from [192.168.1.64] (31.53.17.199) by rgout06.bt.lon5.cpcloud.co.uk (8.6.122.06) (authenticated as J.D.Lamb) id 53F20EF5001533F4 for gsl-discuss@sourceware.org; Tue, 19 Aug 2014 10:19:26 +0100 Message-ID: <53F3164F.50508@btinternet.com> Date: Tue, 19 Aug 2014 09:19:00 -0000 From: John D Lamb User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: gsl-discuss@sourceware.org Subject: Re: const gsl_vector * References: <53EAAB60.3080701@lanl.gov> In-Reply-To: <53EAAB60.3080701@lanl.gov> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2014-q3/txt/msg00001.txt.bz2 On 13/08/14 01:03, Gerard Jungman wrote: > The constness of gsl_vector interfaces makes no sense. This is a > simple observation, but it seems to have escaped discussion for > over a decade. Consider the following code (file attached). > > #include > > void notwhatyouthink(const gsl_vector * v) > { > v->data[0] = 42.0; > } > > The goals: > - const-correctness > - no "doubling" of interfaces > - an architecture where views are central > - memory management factored out (allocation/deallocation) > > Ideas? I mainly use C++. But I think C now works so that you could use gsl_vector* const v in place of a const gsl_vector* v argument, and get the desired result. I don’t know if there would be unintended consequences of rewriting the arguments of the GSL functions this way. I know that C can’t handle both of int function( const gsl_vector* v ); int function( gsl_vector* const v ); in the same code. So it would need a rewrite. One issue would be that if the code were rewritten any code that passed a const gsl_vector* argument would cause a compilation failure. The workaround might be to use a gsl_vector const* const v argument. But I don’t know if that would cause problems, for example with older compilers. -- John D Lamb