From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3965 invoked by alias); 5 Nov 2014 22:08:21 -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 3799 invoked by uid 89); 5 Nov 2014 22:08:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: proofpoint5.lanl.gov Received: from proofpoint5.lanl.gov (HELO proofpoint5.lanl.gov) (204.121.3.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 05 Nov 2014 22:08:18 +0000 Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailgate5.lanl.gov (8.14.7/8.14.7) with ESMTP id sA5M8FQn018983 for ; Wed, 5 Nov 2014 15:08:15 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id CC8911371987 for ; Wed, 5 Nov 2014 15:08:15 -0700 (MST) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay1.lanl.gov Received: from manticore.lanl.gov (manticore.lanl.gov [130.55.124.157]) by mailrelay1.lanl.gov (Postfix) with ESMTP id B3D001371986 for ; Wed, 5 Nov 2014 15:08:15 -0700 (MST) Message-ID: <545A9FCF.5070702@lanl.gov> Date: Wed, 05 Nov 2014 22:08: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: final (?) word on constness and containers 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/msg00003.txt.bz2 Once more on the container constness problem and container design, to express my final understanding of the problems and suggest a path forward. I have concluded that the design of the vector and matrix view types is completely brain-damaged. The two distinct types (non-const and const) are useless, because they cannot enforce their implied contract. Any client who uses the const-ified view type is forced to cast away the constness before using any GSL interface. So the const types are actually just an annoying trap. The full vector and matrix types are slightly less brain-damaged. They also do not enforce any implied contract, but they do not really claim to do so, since there is no const-ified type. There is only the current illusion of const-correctness. I have spent some effort trying to understand the state of the art for containers in C. The conclusion seems to be that const-correctness is essentially impossible in practical C code of this type. This is quite sad, when you think about it. But that's the way it is. On the bright side, you could argue that this situation is inevitable in an inter-language environment, where GSL might be wrapped in python, etc. The notion of constness is C-language-family specific and does not translate well to dynamic inter-language contexts. So here are my recommendations: R1) Introduce a set of "view constructors" which build gsl_vector objects (not views) that wrap existing memory. Objects are built on the stack. Examples: gsl_vector gsl_vector_as_view(double * x, size_t size, int stride); gsl_vector gsl_vector_as_subvector(const gsl_vector * v, size_t i, int stride, size_t n); The notion of "view" shifts from a distinct type to flexible methods of construction for the single main type. For parallelism, introduce stack constructors for heap-allocated data as well: gsl_vector gsl_vector_as_heap_data(size_t size); This is important, to encourage a more value-centric philosophy (rather than pointer-centric), which makes client code more flexible and probably more maintainable. The pointer-based idioms are retained, since they are also useful, especially in more dynamic contexts. Also, current client code depends on them. R2) Expand the semantics of the 'owner' member in the vector and matrix structs to be flags that delineate the supported actions in gsl_XXX_free(). Currently, the value is either 0 or 1, where 0 instructs gsl_vector_free() to not attempt to free the data segment. The new values and their semantics would be as follows: GSL_OWNER_EXTERN = 0 /* wrapper and data externally managed */ GSL_OWNER_MALLOC_DATA = 1 /* data is heap allocated */ GSL_OWNER_MALLOC_WRAP = 2 /* wrapper is heap allocated */ GSL_OWNER_MALLOC_BOTH = 3 /* (1 & 2) */ gsl_XXX_free will test these flags and act accordingly. The values are not quite binary compatible with the current design, because the current constants were badly chosen. R3) Deprecate the current view functionality. There is no reason to eliminate it, since it is orthogonal to everything, and some clients may be burdened if we removed it immediately. Consequences: C1) The constness problem is not solved. This is the only way forward that does not change everything. The library can handle the casting away of constness at construction time, continuing to propagate the current fiction that the design is const correct. C2) Clients gain more flexibility in managing their own memory and creating their own allocation strategies. This design is the most flexible and avoids alloc/free function wrappers and related "factory" style frameworks, which are just too rigid to be contemplated. C3) No changes are required in existing client code, unless they choose to use the new interfaces. C4) Uses of the current "view" types in GSL library code should be replaced with new-style constructs. This would not be difficult; these internal uses are well-delineated and easy to replace. There are, however, dozens of them. C5) Add the new constructor interfaces and make the small needed change to the gsl_XXX_alloc() and gsl_XXX_free() impls, to support the new 'owner' semantics. Overall, this seems like a simple and controlled plan. It's the kind of thing I could bang out in a few afternoons. And the consequences seem palatable. Please think hard about how this might impact future progress. That is the hard problem. -- G. Jungman