From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26708 invoked by alias); 24 Feb 2010 01:42:29 -0000 Received: (qmail 26683 invoked by uid 22791); 24 Feb 2010 01:42:27 -0000 X-SWARE-Spam-Status: No, hits=-10.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from proofpoint2.lanl.gov (HELO proofpoint2.lanl.gov) (204.121.3.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 24 Feb 2010 01:42:23 +0000 Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by proofpoint2.lanl.gov (8.14.3/8.14.3) with ESMTP id o1O1gCkO031517; Tue, 23 Feb 2010 18:42:12 -0700 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay2.lanl.gov (Postfix) with ESMTP id F406715FC037; Tue, 23 Feb 2010 18:42:11 -0700 (MST) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id F12E77D0054; Tue, 23 Feb 2010 18:42:11 -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 DED317D0050; Tue, 23 Feb 2010 18:42:11 -0700 (MST) Subject: Re: Feedback from GSL folks on libflame 4.0 From: Gerard Jungman To: "Field G. Van Zee" Cc: gsl-discuss mailing list In-Reply-To: <4B7F656C.5040406@cs.utexas.edu> References: <4a00655d1002171047t4e87fb85w88b609245e3f9a8e@mail.gmail.com> <4B7D90B5.4020707@cs.utexas.edu> <1266537635.27033.79.camel@manticore.lanl.gov> <4B7F656C.5040406@cs.utexas.edu> Content-Type: text/plain Date: Wed, 24 Feb 2010 01:42:00 -0000 Message-Id: <1266975834.27033.163.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=2010-02-24_02:2010-02-06,2010-02-24,2010-02-23 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: 2010-q1/txt/msg00047.txt.bz2 On Fri, 2010-02-19 at 22:30 -0600, Field G. Van Zee wrote: > > In very early versions of libflame (before it was even called "libflame") there > was only one object struct which contained all fields. Later, Robert separated > the "view" data from the base object data. It seemed like the smart thing to do > at the time, but I can see how it might incur quite a bit more memory overhead. > I can see arguments going both ways on whether we need to worry about that extra > memory cost. Memory overhead is not the issue. The problem is that any use of the C heap (malloc()/free() and friends) ties the implementation to that one allocation strategy. This makes it hard (impossible ?) for other environments to control the allocation strategies. Compare to the C++ STL containers, where the allocation strategy is parametrized (literally a template parameter), by design. Separating the views and the base objects is a good idea, since the views are (at least in principle) light-weight objects. But tying the composition of these objects to a heap allocation is restrictive. The way I think of this is that the 'view' is like the base class in the hierarchy. What you call the 'base object' is actually the derived object, since both views and bases must export the interface for access, but the object with the data extends this functionality by actually managing the data segment. Sorry if I'm stating obvious stuff. I'm sure you have thought about these things. But I wanted to explain how I look at it. I don't know if there is an easy answer for this type of container design in C, but its good to know the trade-offs. -- G. Jungman