Re: [boost] Performance comparison between ptr_vector and vector<cow_ptr<Shape> >, vector<copy_ptr<Shape> >

From: David Maisonave (dmaisonave_at_[hidden])
Date: 2006-01-05 16:51:50

"Thorsten Ottosen" <tottosen_at_[hidden]> wrote in message
news:<dpk19e$u4$1_at_[hidden]>...
> Thorsten Ottosen wrote:
> > Sam Partington 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?)
> > 
> > 
> > It's not very sensible to make the hierarchy copyable, because you 
> > can run into slicing in other places then.
> > 
> > As for the default, then I've been thinking about this too. It still
> > won't catch that one missed a clone() function longer down the
hiararchy.
> > 
> 
> Hm...I just came to think that a little assertion might help us out 
> here:
> 
> inline base* new_clone( const base& b )
> {
> 	base* res = b.clone();
> 	assert( typeid(*res) == typeid(b) );
> 	return res;
> }
> 
> That should catch any problems. I can even put this inside the
> clone-allocator, so the user don't have to specify this.
> 

That's a good idea, and it's something I could also add to cow_ptr and
copy_ptr.

However, doesn't boost have something better then typeid?