Re: A generic list package

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> writes:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> 
> <snip>
> 
> > I find it curious that you expect the client to provide the "next"
> > field/operation, rather than declaring a Node_Type containing the
> > user's type and a Next field. Can you elaborate on this?
> 
> Using this approach, you can save one indirection in the case of
> indefinite types.  (The redirection seems necessary as well if you
> need a non-constant view of the actual data.)  In such cases, your
> approach seems to result in the following:
> 
>                                     +-------------- ...
>        +------------------+         |
>        |         o========#=======>>| actual data
>        |                  |         |
>        | fields specific  |         +-------------- ...
>        | to the container |
>        +------------------+
> 
> 
> The getter/setter aproach permits the following:
> 
>        +------------------+
>        | fields specific  |
>        | to the container |
>        |                  |
>        |    actual data   |
>        .                  .
>        :                  :
> 
> 
> And it is still possible to obtain a non-constant view of the actual
> data.

Yes. I have an indirection and cleaner abstraction; you have less
clean abstraction and no indirection. I guess that's a useful
tradeoff. 

> > Your approach leaves everything up to the user; mine ensures that
> > garbage is collected appropriately, when necessary; the user only
> > needs to provide the appropriate 'free' operation.
> 
> I think our approaches are not much different in this regard; if an
> element is removed from a list, it is also freed by my implementation.

Ok, guess I missed that in your comments.

-- 
-- Stephe