From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2004-09-27 02:54:48
"Thorsten Ottosen" wrote:
> | > | 15. Clonable concept implementation:
> | checked_delete accepts 0. smart containers cannot.
> yes, so you want
> 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
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
> 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
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
- maybe one for COM objects as example of using
object factory (or something simpler)
- one using non-default allocator and then
- one using serialization/deserialization to create
clone (the serialization process may for example
fluch internal caches or re-adjust some internal
(I am still unsure how view_clone_manager fits here.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk