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