Re: [boost] [Boost-announce] Review of Intrusive library begins today

From: Dave Harris (brangdon_at_[hidden])
Date: 2007-03-21 16:51:32

In-Reply-To: <46001891.5080209_at_[hidden]>
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:
    clear_and()
    erase_and()

leaving open what the passed functor was expected to do. Alternatively:
    clear_and_dispose()
    erase_and_dispose()

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 
problem here.

> > 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 
than changes.

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.