Re: [boost] Performance comparison between ptr_vectorandvector<cow_ptr<Shape> >, vector<copy_ptr<Shape> >
"Sam Partington" <sam.partington@gmail.com> wrote in message news:<546fdb840601060205w76ed8be9n2bf73c4323c78c20@mail.gmail.com>...
On 1/5/06, David Maisonave <dmaisonave@commvault.com> 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 code for each new type, this increases the chances of slicing. And therefore (IMHO) it's easier to introduce bugs using this method.
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 slicing. The assert logic can be placed in the constructor of the cow_ptr and copy_ptr. 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 slicing. With cow_ptr/copy_ptr the slicing would be caught when the object gets instantiated. So you have a much higher probability of catching slicing using the cow_ptr clone method, *than* you would using the boost pointer container method. 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 function. 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 type. Any way, it's food for thought.
David Maisonave wrote:
"Sam Partington" <sam.partington@gmail.com> wrote in message news:<546fdb840601060205w76ed8be9n2bf73c4323c78c20@mail.gmail.com>...
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 slicing. The assert logic can be placed in the constructor of the cow_ptr and copy_ptr. 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 slicing.
With cow_ptr/copy_ptr the slicing would be caught when the object gets instantiated. So you have a much higher probability of catching slicing using the cow_ptr clone method, *than* you would using the boost pointer container method.
I'm not sure I fully understand how the detection mechanism would work in your cow_ptr. Nevertheless, as soon as the object is outside a cow_ptr might be sliced. That's reason enough not to allow it. -Thorsten
participants (2)
-
David Maisonave -
Thorsten Ottosen