In-Reply-To: <46001891.5080209@gmail.com> igaztanaga@gmail.com (=?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.