Howard Hinnant <hinnant@twcny.rr.com> writes:
On Apr 26, 2005, at 12:08 PM, David Abrahams wrote:
I had this disagreement with Thorsten in Lillehammer (or was it Oxford?) but he was unimpressed with my arguments. I was wondering what Boost as a whole would think:
My Thesis: the library should support copying and assignment of pointer containers using the usual copy/assignment syntax, rather than only allowing a copy via a clone() function.
Rationale: Not being able to copy and assign pointer containers is an arbitrary restriction that limits usefulness and expressivity. The argument Thorsten gives against copyability is that the elements would have to be clone()d rather than copied, which is expensive because there's a dynamic allocation per element. I don't get it; we don't arbitrarily prohibit copying of std::vector<std::string> even though that incurs a dynamic allocation per element.
Example: Consider std::pair<int,some_pointer_container>. Almost nothing works. IIUC, it's not copyable, can't be initialized, and can't be clone()d.
Why not just a clone_ptr<T> which calls clone on copy construction / assignment? Then you could std::container<clone_ptr<T>>.
That makes insertion in a std::vector<clone_ptr<T> > expensive. But this is really beside my point.
On your thesis: The library should only support copying and assignment of pointer containers using the usual copy/assignment syntax if a non-destructive copy of the pointer can be made.
The pointers are just plain pointers, so it can.
The proposed std::container<unique_ptr<T>> won't be such a container. Having std::container<auto_ptr<T>> fail at compile time is still a good idea. Otherwise it would destructively copy with copy syntax.
This seems to be beside my point also.
<sigh> I realize these thoughts are a little ahead of their time at the moment due to the lack of compilers/libs which would make std::vector<clone_ptr<T>> acceptably efficient.
In preparing my notes for speaking about rvalue references at ACCU I realized that move semantics can be fully accomplished within the current language, if clumsily. The forwarding problem really makes new compilers _necessary_. Of course, move without forwarding is not really all that compelling anyway. -- Dave Abrahams Boost Consulting www.boost-consulting.com