| ______________________________________________________ | > | 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. ok, I can't imagine it, but maybe the library author can show that? | And it should be stressed Clonable concept is | mere requirement of one (default) clone manager. | Now Clonable docs comes before clone manager. ok. it is also a concept of it own. | 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, hm... how would that work? | - 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 can't you do that from within T* allocate_clone( const T* ptr ) { return my_clone_func( ptr ); } ? | - one using serialization/deserialization to create | clone (the serialization process may for example | fluch internal caches or re-adjust some internal | structures) hm...the thing is that the clone manager controls all cloning, also when clones are inserted coming from other containers...seems wierd to me. br Thorsten