"David Abrahams" <dave@boost-consulting.com> wrote in message news:uacnl8qsf.fsf@boost-consulting.com...
I had this disagreement with Thorsten in Lillehammer (or was it Oxford?) but he was unimpressed with my arguments.
With mine too :(
I was wondering what Boost as a whole would think:
My Thesis: the library should support copying and assignment of pointer containers using the usual copy/assignment syntax, rather than only allowing a copy via a clone() function.
Agreed. But we should provide some traits class to support Clone, CloneMe and so on. And some compile-time checking if user didn't provide any clone functions.
Rationale: Not being able to copy and assign pointer containers is an arbitrary restriction that limits usefulness and expressivity. The argument Thorsten gives against copyability is that the elements would have to be clone()d rather than copied, which is expensive because there's a dynamic allocation per element. I don't get it;
We might face with some problems with ptr_container's allocators and the only solution is something to it is something like: class Base { size_t size_of () const; // returns sizeof(*this); Base * placement_clone (void * address); }; Or support only heap_clone_allocator... which might be undesirable for some users. P.S. What's your opinion about comparison operators? User is most likely to going to have some polymorphic-related problems because C++ doesn't provide virtual function specifier "must be overriden in all derived classes". -- Pavel Chikulaev