On 09/12/2007, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Just a few simple remarks. Why not add support for moving and in-place construction?
Short answer: If accepted, it's pretty likely that they will be supported, but maybe not in the first release. Long answer: The main reason for not supporting move is that boost doesn't have a move library. Recently Adobe's and Boost.Thread's move libraries have been discussed on this list so I'll look into them. Boost.Thread's is probably more appealing since it's already in Boost, but I'd need to review it first. There's no support in the standard yet, but I don't think that's a problem. In place construction has been added to the standard, but only recently and I haven't had a chance to catch up. There are some problems since existing allocators aren't going to support it and std::pair will be missing the extensions to support constructing its members in place. It's possible to use a replacement class, or perform some sort of hack (i.e. constructing the members yourself instead of using std::pair's constructor). Allocators are more of a problem, but perhaps some compromise could be made. Some people (including Ion) think that the allocator shouldn't be used for construction and destruction. This was proposed, and then opposed: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2339.htm If I don't use construct and destroy there wouldn't be a problem here (and the implementation would perhaps be a little simpler). If I do, then maybe I could provide a default allocator that supports it and use some sort of marker in the allocator to indicate if it supports in place allocation. (IIRC there was proposal to add version information to allocators, although I haven't heard about that for a while, and it's too late for me to look it up right now). Daniel