Boost logo

Boost :

From: Daniel James (daniel_james_at_[hidden])
Date: 2007-12-09 19:36:18


On 09/12/2007, Mathias Gaunard <mathias.gaunard_at_[hidden]> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk