From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-09-27 13:27:31
| ______________________________________________________
| > | 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