[boost] Re: [review] Formal review of the Smart Container library

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
>
> 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