From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19430 invoked by alias); 5 Nov 2014 22:52:49 -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 19415 invoked by uid 89); 5 Nov 2014 22:52:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: proofpoint4.lanl.gov Received: from proofpoint4.lanl.gov (HELO proofpoint4.lanl.gov) (204.121.3.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 05 Nov 2014 22:52:48 +0000 Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by mailgate4.lanl.gov (8.14.7/8.14.7) with ESMTP id sA5Mqk1w031374 for ; Wed, 5 Nov 2014 15:52:46 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 4E9A4E99432 for ; Wed, 5 Nov 2014 15:52:46 -0700 (MST) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay2.lanl.gov Received: from manticore.lanl.gov (manticore.lanl.gov [130.55.124.157]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 3F76CE992B8 for ; Wed, 5 Nov 2014 15:52:46 -0700 (MST) Message-ID: <545AAA3E.7090802@lanl.gov> Date: Wed, 05 Nov 2014 22:52:00 -0000 From: Gerard Jungman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: gsl-discuss@sourceware.org Subject: orthogonal issues Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-11-05_08:2014-11-05,2014-11-05,1970-01-01 signatures=0 X-SW-Source: 2014-q4/txt/msg00005.txt.bz2 The previous message does not address a couple of orthogonal issues. The first one seems simple, but I am unsure of the consequences of a change. Currently, the 'stride' arguments are all size_t, and therefore unsigned. This seems odd, since it precludes the possibility of traversing vectors in reverse. Could all the strides be changed to signed quantities? As an aside, I will say that I really loathe unsigned types. They are almost useless. The common arguments for their use are spurious. I learned this many years ago, from painful experience, and from Lakos' book "Large-Scale C++ Software Design", where he advocates eliminating unsigned types from all interfaces. The second issue is big and painful. What do we do about the 'restrict' keyword? There is no doubt that 'restrict' helps in some situations. Sometimes it helps a lot. The 'restrict' keyword is technically a modifier of the same class as 'const'. So it multiplies the number of implied types in your head. Very nasty for interface explosion. One possibility is to bake-in the 'restrict' keyword to the container types. It could be turned off with a compile-time option. Of course, this requires that all GSL implementations be truly restrict-correct. But I am willing to guess that they are. When used in C++ code, the headers can test for an appropriate platform-dependent substitute, like '__restrict__' or '__restrict'. It would become part of the contract that clients should insure that their data segments do not overlap, just like when they choose to use memcpy(). Is this too much to ask? Be careful how you answer. For example, if you are using a drop-in replacement for matrix operations or linear algebra (any library other than libgslcblas), then you might already be subject to such a contract. The underlying implementation may well be written in Fortran. To understand aliasing problems and the motivation for 'restrict', I recommend reading Ulrich Drepper's series of articles, starting with part 5 if you are in a hurry: https://lwn.net/Articles/255364/ -- G. Jungman