I was wondering if boost has considered a smart pointer that is similar to scoped_ptr but supports deep copy semantics. This would be useful in classes which use the pimpl idiom, as a common way to program these classes is with a scoped_ptr or auto_ptr, but then a copy constructor and copy assignment operator needs to be defined. Herb Sutter worked on an implementation at http://www.gotw.ca/gotw/062.htm, so there's precedent. Is there any interest for this?
On Thu, Jul 16, 2009 at 1:46 PM, Ross Levine<ross.levine@uky.edu> wrote:
I was wondering if boost has considered a smart pointer that is similar to scoped_ptr but supports deep copy semantics. This would be useful in classes which use the pimpl idiom, as a common way to program these classes is with a scoped_ptr or auto_ptr, but then a copy constructor and copy assignment operator needs to be defined.
My common way to program these classes is with shared_ptr actually. Yes, it does require copy ctor and op= if deep copy semantics are needed but that's rare (in my experience anyway) and the benefit of shared_ptr is that you have complete control over the memory allocations, all done in the cpp file completely decoupled from the interface. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Thu, Jul 16, 2009 at 4:46 PM, Ross Levine<ross.levine@uky.edu> wrote:
I was wondering if boost has considered a smart pointer that is similar to scoped_ptr but supports deep copy semantics. This would be useful in classes which use the pimpl idiom, as a common way to program these classes is with a scoped_ptr or auto_ptr, but then a copy constructor and copy assignment operator needs to be defined. Herb Sutter worked on an implementation at http://www.gotw.ca/gotw/062.htm, so there's precedent. Is there any interest for this?
You might want to consider copy on write. eg http://stlab.adobe.com/classadobe_1_1version__1_1_1copy__on__write.html http://stlab.adobe.com/wiki/index.php/Copy_On_Write Tony
I have a work-in-progress Cloneable proposal here http://tinyurl.com/ndy5n8.
From the documentation:
Motivation We still use object type hierarchies, and we often use them with containers. However, doing so often means that we lose value semantics for those containers, becuase they typically contain base pointers. We would like to have the ability to copy containers of base pointers and maintain value semantics, and also to safely clone and query individual object instances. Description The Boost.Cloneable library provides a means for creating, duplicating, and querying instances of object types that are specified in class hierarchies, and a set of containers for those objects. Cloneable objects can create clones of derived types from base types, can do so given any STL-compliant allocator, and supports multiple clone type targets. The user of the library is able to override the default cloning process, and may supply custom allocators. Cloneable types can derive from other cloneable types, in which case the user can specify which subobject type to duplicate or create when making a new clone or new object from an existing instance. You can use Boost.Cloneable with existing, external types without modification to those types by using the supplied adaptor mechanism. Boost.Cloneable also supports types that are not default-constructable. There is a fundamental requirement that a common base class type is shared for each type in a given class hierarchy. The user can supply their own base classes, or sensible defaults are generated. Key features of the library: * Can make any class-type Cloneable with or without modification to its definition * Optional user-supplied base classes * Base types can be queried for the interfaces they support * Clones can be created from base types * Supports multiple inheritance, cloning of sub-objects * Supports types with no default constructors * Customisation of the cloning process * Support for custom allocators * A set of heterogenous containers with emplace semantics for object insertion The complete source code for the library, with unit-tests, are available in the Boost SVN respository here http://tinyurl.com/nnj7kd Note that this is still a work in progress... I mention it here because it intends to solve the issue raised by the original poster. Regards, Christian. On Fri, Jul 17, 2009 at 9:40 AM, Gottlob Frege <gottlobfrege@gmail.com>wrote:
On Thu, Jul 16, 2009 at 4:46 PM, Ross Levine<ross.levine@uky.edu> wrote:
I was wondering if boost has considered a smart pointer that is similar to scoped_ptr but supports deep copy semantics. This would be useful in classes which use the pimpl idiom, as a common way to program these classes is with a scoped_ptr or auto_ptr, but then a copy constructor and copy assignment operator needs to be defined. Herb Sutter worked on an implementation at http://www.gotw.ca/gotw/062.htm, so there's precedent. Is there any interest for this?
You might want to consider copy on write. eg
http://stlab.adobe.com/classadobe_1_1version__1_1_1copy__on__write.html http://stlab.adobe.com/wiki/index.php/Copy_On_Write
Tony _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Gottlob Frege wrote:
On Thu, Jul 16, 2009 at 4:46 PM, Ross Levine<ross.levine@uky.edu> wrote:
I was wondering if boost has considered a smart pointer that is similar to scoped_ptr but supports deep copy semantics. This would be useful in classes which use the pimpl idiom, as a common way to program these classes is with a scoped_ptr or auto_ptr, but then a copy constructor and copy assignment operator needs to be defined. Herb Sutter worked on an implementation at http://www.gotw.ca/gotw/062.htm, so there's precedent. Is there any interest for this?
You might want to consider copy on write.
Copy on write is nothing more than a possible implementation for the utility he's requesting, and arguably a pretty bad one (it's only useful in the absence of move semantics).
Mathias Gaunard wrote:
Gottlob Frege wrote:
On Thu, Jul 16, 2009 at 4:46 PM, Ross Levine<ross.levine@uky.edu> wrote:
I was wondering if boost has considered a smart pointer that is similar to scoped_ptr but supports deep copy semantics. This would be useful in classes which use the pimpl idiom, as a common way to program these classes is with a scoped_ptr or auto_ptr, but then a copy constructor and copy assignment operator needs to be defined. Herb Sutter worked on an implementation at http://www.gotw.ca/gotw/062.htm, so there's precedent. Is there any interest for this?
You might want to consider copy on write.
Copy on write is nothing more than a possible implementation for the utility he's requesting, and arguably a pretty bad one (it's only useful in the absence of move semantics).
I have the impression that the copy_on_write will not work well together with serialization, but I haven't tried. By this statement I mean that objects that were shared before serialization (saving) "should" also be shared after deserialization (loading). So I have the impression that shared_ptr has a definitive advantage over copy_on_write here. Regards, Thomas
Ross Levine wrote:
I was wondering if boost has considered a smart pointer that is similar to scoped_ptr but supports deep copy semantics. This would be useful in classes which use the pimpl idiom, as a common way to program these classes is with a scoped_ptr or auto_ptr, but then a copy constructor and copy assignment operator needs to be defined. Herb Sutter worked on an implementation at http://www.gotw.ca/gotw/062.htm, so there's precedent. Is there any interest for this?
I believe the reason why there is no such thing in Boost is that there is no agreement about how the copying would work, and also about how operator= would work either. Indeed, one could argue the most natural way to enhance those is to layer on top of virtual functions, but virtual operator= has limitations and the language provides no virtual copy constructor facility (and if it did, it would need to change its allocation model anyway). Some methods nevertheless exist, with allocation a real problem there since it is often too tightly coupled with construction. Another approach would be to ditch the virtual function model altogether and use boost.any-like techniques instead, but that means additional space overhead as well as possibly decayed type information. I think none ever managed to satisfy everyone.
participants (6)
-
Christian Schladetsch -
Emil Dotchevski -
Gottlob Frege -
Mathias Gaunard -
Ross Levine -
Thomas Klimpel