"Thorsten Ottosen" wrote: ______________________________________________________
| > | 15. Clonable concept implementation: | checked_delete accepts 0. smart containers cannot.
yes, so you want
try { if( t == 0 ) throw something(); checked_delete( t ); }
? :-)
No, BOOST_ASSERT should be enough. ______________________________________________________
| there's semifinished library (polymorphic_map) in Files section | that could be used for such purpose.
I took a look at this stuff. It has AFAICT nothing to do with smart containers, in ptr_map<key,T>, T will be heap-allocated. in polymorphic_map<key,T>, key might be heap-allocated. The usage for poymorphic_map seems to be very narrow AFAICT.
The library would allow to simulate the virtual function clone() without need to change interface of the base class. It could be really relevant for a special clone_manager. ______________________________________________________
| - if I have polymorphic hierarchy, will the allocate_clone(T*) | clone the dynamic type of class or its static type?
it's up to you. If you let it return ptr->clone() which is virtual, then its virtual ortherwise its not. So in the examples from the toturial, animals are cloned virtually.
Lets enumerate posibilities: a. class has virtual member clone() (could have different name), b. the clone() function is standalone function, then class may or may not have support in form of virtual member clone(), c. class hierarchy with mix of above, possibly diferent names and function signatures. And how to construct objects: a. with plain new and copy constructor, b. with placement new and copy constructor, c. via allocator and placement new d. via object factory. Reading again the docs, I think decision what to use and how could be left to user, via a. overloading allocate_clone/delete_clone b or by using different clone manager and this should cover all options from above. So my opinion now is that smart containers cloning functionality is complete and doesn't need change. I was at first confused what is relation between Clonable and clone managers. This should be more explained in docs, possibly with flowchart or other diagram. And it should be stressed Clonable concept is mere requirement of one (default) clone manager. Now Clonable docs comes before clone manager. It may be also useful to provide few more clone managers in library: - the one relying on virtual T* clone(T*) member, - possibly the one that is able to detect dynamic type at runtime and properly contruct clone, w/o need for special clone support in class, - one which allows to bind parameters to constructor early (those parameters being added to copy constructor first parameter). - maybe one for COM objects as example of using object factory (or something simpler) - one using non-default allocator and then placement new - one using serialization/deserialization to create clone (the serialization process may for example fluch internal caches or re-adjust some internal structures) (I am still unsure how view_clone_manager fits here.) /Pavel