From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2006-07-04 17:59:32
David Abrahams wrote:
> Thorsten Ottosen <thorsten.ottosen_at_[hidden]> writes:
>>Matt Calabrese wrote:
>>>On 7/3/06, Thorsten Ottosen <thorsten.ottosen_at_[hidden]> wrote:
>>>>As long as C++ does not have move-semantics, the semantics of clone_ptr
>>>>seems to be far too expensive to be useful: std::vector<clone_ptr<T>>
>>>>will have to re-clone all objects on buffer expansion, whereas
>>>>boost::ptr_vector<T> will not.
>>>Firstly, while it is true that it may be expensive to copy such objects for
>>>some users, it certainly isn't "far too expensive" for all users, as many
>>>programmers likely are simply not bound by the copy operations of the types
>>>they may be using with it -- an assumption either way made at the library
>>>level, in my opinion, is a mistake in design.
>>Well, we usually prefer "as efficient as possible" for libraries.
> I don't know who "we" is supposed to refer to. Your philosophy seems
> to be the same as the one you used to forbid copying of
> ptr_containers: if you think the user _might_ be unhappy with the
> cost, don't provide the capability through the usual interface. This
> approach has no precedent in Boost or the STL.
Right, because neither Boost nor the STL has ever dealt with anything
>>>If value semantics are desired for a given type, a programmer
>>>shouldn't have to jump through hoops using a type with reference
>>>semantics and explicit cloning in order to get the functionality
>>>they want -- this is refering to the types in general, not just
>>>with respect to them being stored inside of containers.
>>If value semantics are desired, then why not provide them directly?
>>Having polymorphic types with value semantics is fairly rare.
> Only because it's more work to implement than it should be. I've had
> to do it several times. And, just to point at one familiar example,
> see boost::function.
I fail to see the relevance of boost::function is this context. It's not
exactly exposing any virtual functions in its interface.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk