Re: Fwd: Re: [Libclc-developers] Introducing the double linked list interface

[Bryan D. <bd...@bd...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 19 March 2003 10:35 am, Bj=F8rn Augestad wrote:
> Michael B.Allen wrote:
> > On Wed, 19 Mar 2003 06:59:32 +0100
> >
> > Bj=F8rn Augestad <bo...@me...> wrote:
> >># Sequences
> >>    1. vector
> >>    2. deque
> >>    3. list
> >>    4. slist
> >>    5. bit_vector
> >>
> >># Associative Containers
> >>    1. set
> >>    2. map
> >>    3. multiset
> >>    4. multimap
> >>    5. hash_set
> >>    6. hash_map
> >>    7. hash_multiset
> >>    8. hash_multimap
> >>    9. hash
> >>
> >>Need more containers? :-)
> >
> > I think we should start with something simple, perfect it, debate it,
> > and let it stew a little. Then we can move on and think about
> > transcendent ideas that facilitate exotic functionality. The linked list
> > is a good start.
>
> Agree, but we need to agree on a few things and the STL works well as a
> specification. STL gives us concepts, naming conventions and semantics
> for e.g. iterators and e.g. push_back() and push_front(). So instead of
> discussing these issues to death, why not adapt what's usable from STL?
> (and then discuss it to death :-))
>
> >>void* is OK for data, I guess. The hard part will be to find a *good*
> >>way to represent keys. Does anyone have a good concept for keys?
> >
> > I'm not sure what you mean. What is a key? How about void *.
>
> void* is OK, but we need length for some data types. We may even want to
> know the data type itself, for optimization purposes[1]. It would also
> be nice to avoid lots of casts...

void* won't work with structs. Or anything else. The compiler can add paddi=
ng
bits - we can't know what's in them without using a proper comparator
function.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+eNH5x533NjVSos4RAhJGAJ9dB9+kgJBzcICniDcAmQ6WbkiO1ACeIOdN
8S3tVZVGHhXe4Z0ZyxXutO0=3D
=3D+I0F
=2D----END PGP SIGNATURE-----