"David Abrahams" <dave@boost-consulting.com> wrote in message news:uacnl8qsf.fsf@boost-consulting.com... | | 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 ^^^^^^^^ It was not an arbitrary choice. It makes little sense in my world to give the same syntax to different semantics. Oh, I cannot copy X, but if I put it into ptr_vector, I can. | 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. There is another point: if the compiler don't do RVO and NRVO and/or has to use assignment internally when handling vector< ptr_vector<T> >, it *really, really* hurts performance. I would like to see some benchmark that showed vector< ptr_vector<T> > would be as fast as ptr_vector< ptr_vector<T> >. Big objects are not nice to copy IMO; they should however be movable. -Thorsten