Re: Feedback from GSL folks on libflame 4.0

[Gerard Jungman <jungman@lanl.gov>]

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