|
Boost : |
From: Martin Bonner (martin.bonner_at_[hidden])
Date: 2005-08-17 03:58:23
----Original Message----
From: Axter [mailto:boost_at_[hidden]]
Sent: 17 August 2005 01:54
To: boost_at_[hidden]
Subject: Re: [boost] Propose adding Clone Smart Pointer (clone_ptr) to
the boost library
> The documents state that the clone_ptr class is based on strict
> pointer ownership logic.
I am not familiar with that term, so it didn't help.
> The above code is not using strict ownership logic, and instead the
> object is created using a dumb pointer.
But your example code has this problem.
> I also think you're right in that I should add more to the
> documentation
Absolutely.
I am sure that this code satisfied a real need that you had. What is not at
all clear is whether that need is widespread enough to justify including the
clone_ptr in boost.
What is needed is some clear documentation including:
- an explanation of what problems the class solves ("motivating examples").
Note this doesn't need to be very detailed as too why the problem exists at
this point. I imagine most people on this list understand concepts like
"slicing".
- An overview of the class usage (including the restrictions on how the
class may be used)
- A description of the specification of the class and its members, including
the concepts that the template parameters must model.
(Don't worry too much about getting the English right. If the library does
go into boost, plenty of people here can help with that later.)
Finally you might like to consider the following:
A) I can see how something like this might be useful to allow a copyable
class which owns an object of a polymorphic type. However, under what
circumstances is this better than providing a clone() member in the
polymorphic type?
B) Under what circumstances is a std::container<clone_ptr<T> > better than a
boost::ptr_container<T>?
-- Martin Bonner Martin.Bonner_at_[hidden] Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk