From: Dave Harris (brangdon_at_[hidden])
Date: 2007-03-21 16:51:32
igaztanaga_at_[hidden] (=?ISO-8859-1?Q?Ion_Gazta=F1aga?=) wrote (abridged):
> Sink sounds good but now I need a name for operations:
I would be tempted by:
leaving open what the passed functor was expected to do. Alternatively:
because for me "dispose" is a less committed word than "destroy". It still
has the connotation that the container is getting rid of them, but leaves
it more open as to what that entails. "Dispose" does have a more specific
meaning in garbage collection circles; I don't know if that would be a
> > Could remove_and_destroy take a default Destroyer argument that
> > deleted the value?
> Well, functions can't have default template parameters
Ah, OK. (Sometimes these language restrictions take me by surprise.)
> I understand that maybe replacing code using list<value*> is not an
> easy task, but I prefer to stick to the STL interface.
You would still do that, but instead of instantiating ilist<T> you would
instantiate ilist<T*>. To me there is a fairly strong sense in which the
list does not contain values, but only pointers to them, because of the
lifetime issues. I see myself creating objects and then adding them to the
collection, rather than adding copies of them, so the semantics are closer
to std::list<T*> than to std::list<T>. Where there are differences they
are restrictions (no NULLs, no putting items in multiple lists etc) rather
The main drawback I see to my suggestion is that a signature like:
void push_back( T * );
suggests that we can pass NULL, where-as your current signature makes it
clear we can't (because it takes a T reference argument). And we would
have the usual std inconvenience of having to use things like (*i)->member
instead of i->member for iterators.
I don't know; it's just something which surprised me. Do other people
think ilist is closer to list<T> or list<T*>?
> Well, comparing sizes of STL containers is a bit misleading, because
> how many bytes are we supposed to use in memory bookeeping if we use
> standard allocators?
I'd say none. For example, I believe the overhead for a std::slist<T*>
node is 2 pointers, half that of ilist<T>.
(And that is the comparison I would make, because I see ilist<T> as a
replacement for std::list<T*> rather than for std::list<T>, but maybe I
am unusual in that.)
-- Dave Harris, Nottingham, UK.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk