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

From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2006-01-06 05:58:24

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.
> 
> 
> Agreed, so why do we encourage copyable types by providing a default
> new_clone that uses the copy constructor.  It almost gives the
> impression that that its a recommended way to do it.  The only time
> the default would be useful is when you are using the ptr_ containers
> to store non-polymorphic types, probably for efficiency problems.  Its
> not so much of a burden to require the user to write new_clone in
> those situations.

I guess not.

>>>curve and strange inconsitencies for the user.  i->first and i->second
>>>isn't pretty, but we're used to it now, and I can't see the std
>>>containers changing.
>>
>>This is not to fix the interface, but to hide direct write-access to the
>>pointer.
> 
> 
> How so?  Could you not emulate it with a proxy?  Or would the overhead
> be too high? Perhaps this could go in the docs FAQ / rationale.

So you mean i->second gives back a reference?

That is not a bad idea :-)

> 
>>>typename Container::value_type v = container.back();
>>>container.pop_back();
>>>return v;
>>>
>>>?
>>
>>I don't think so. The first statement won't compile. Secondly, your
>>types should not be copyable.
> 
> 
> I see, but is value_type not T*, so I'm guessing then that back
> returns a reference?  Oh, it has to doesn't it, to match the
> indirection semantics of the ptr_ containers.  Fair enough.  This does
> compile :
> 
> 
> template<class Container>
> 	typename Container::value_type f(const Container& container)
> {
> 	typename Container::value_type v = &container.back();
> 	container.pop_back();
> 	return v;
> }
> 
> But that wouldn't compile for a std container, and its quite apparent
> that the code is taking the address of something and then popping it -
> so I agree pop_back should stay as it is.  It would be nice to have
> something in the FAQ / rationale about why pop_back returns the popped
> element.

right.

It works that way because its exception-safe to do so.

>>I couldn't figure out what the type is either. I can figure out what you
>>want with that type either; AFAICT, it has no use (so maybe it is not
>>that serious it is not there).
> 
> 
> I wanted to know the type to figure out whether the code fragment I
> gave before would compile.  If value_type had been a reference, or
> back had returned a pointer then it would have compiled and would
> return either a reference or a pointer to a deleted object.

right, the typedefs could be better eplained for map/set.

> Of course you may feel that its all too much effort and the user
> should follow the hierarchy to find the member they want.  Which would
> be fair enough :-).

Right. You asked for a more logical way to navigate. What about 
splitting the *see also* bullet into *see also* and *hierachy*
(or something). The latter would only show links to the "virtual" base 
and derived classes, always showinf the same list, with the current page
being a "link" you can't follow.?

-Thorsten