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
