From: David Maisonave (dmaisonave_at_[hidden])
Date: 2006-01-06 12:04:32
"Sam Partington" <sam.partington_at_[hidden]> wrote in message
> On 1/5/06, David Maisonave <dmaisonave_at_[hidden]> wrote:
> > > It seems to me that the first has the disadvantage of making it
> > > relatively easy to provide an incorrect cloner that allows
> > > slicing. However this is relatively easy to avoid by making your
> > > hierarchy noncopyable, (Perhaps a way around this is to remove the
> > > default implementation of new_clone?)
> > Sorry Sam, but that's incorrect.
> > As I posted in one of my previous examples, the noncopyable method
> > does not work on pointer idioms. Noncopyable is for preventing
> > slicing via concrete types. Noncopyable does not help for cloning.
> > Since using the clone function method requires adding additional
> > for each new type, this increases the chances of slicing.
> > And therefore (IMHO) it's easier to introduce bugs using this
> I don't agree with that. The clone concept is a well established
> idiom for polymorphic types. Sure missing out a clone _does_ lead to
> slicing, but that is understood, and as Thorsten says we can help
> check for that with an assert. We can only help the user to get it
> write, we can't do it all for them.
The cow_ptr and the copy_ptr can use the same assert code to catch
The assert logic can be placed in the constructor of the cow_ptr and
This would make it easier to catch slicing in the cow_ptr/copw_ptr
*than* it would be in the boost pointer containers.
That's because in the boost pointer containers you would only catch
slicing via assert if and when the object is clone.
If the object never gets clone during testing, you would never catch the
With cow_ptr/copy_ptr the slicing would be caught when the object gets
So you have a much higher probability of catching slicing using the
cow_ptr clone method, *than* you would using the boost pointer container
It's possible that the boost pointer containers could catch some of the
slicing issues at compile time, if it new the name of the T::Clone
If the boost pointer containers cought the type in the constructor, it
could *than* do a test for T::my_clone_function.
This could catch it if the correct type is being passed in, but again
would still fail if being passed in via base type or parent derived
Any way, it's food for thought.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk