From: David Abrahams (dave_at_[hidden])
Date: 2008-06-22 22:03:01
Daniel James wrote:
> On 22/06/2008, Ion Gaztañaga <igaztanaga_at_[hidden]> wrote:
>> Current move-emulation is still based on Interprocess' own types. For Boost
>> 1.37 I would like to change move emulation to a general Boost.Move library
>> (if that library is ready).
> It might not meet all your needs. My work so far has been based on the
> Adobe move library, which only supports 'regular' types, and move-only
> types are not considered regular. For details see:
I have a hunch that it would be really easy to add support for move-only
types, though. Do you see any specific obstacles?
> In most cases it relies on return value optimization to move the type.
> The library also supplies several functions and algorithms for dealing
> with movable types. So my plan was to separate the library into two
> parts - move emulation and the move functions and algorithms. And then
> work on making the algorithms generic enough to support other move
> emulation methods. So that a container will be able to efficiently
> deal with Boost.Thread's move-only objects, Adobe movable object and
> objects using rvalue references.
Sounds like a good strategy.
> I'm not going to work on a new way of making the container itself
> movable when its elements aren't.
Hm. I don't know what you mean by "a new way," but for most containers,
movability of the element is irrelevant. boost::array and tuples are
the only exceptions I can think of. Could you clarify?
> I think there are already ways of
> doing this in boost. One of these could possibly be brought into the
> move library. But I'm not sure that consensus could be reached on a
> single way to emulate move semantics which is why I'm going to try to
> support multiple emulation types.
> So, in summary, the library will supply algorithms for moving the
> containers' elements (e.g. when resizing an array or implementing
> emplace), but you might want to use one of the existing mechanisms to
> make the container itself movable.
>> With new containers (forward_list) in the standard and having move-aware
>> containers in Interprocess, I was wondering if it would be a good idea to
>> move those containers outside Interprocess. In the future we could make
>> those containers compatible with Scoped Allocators (2554,
I don't know whether you consider this relevant, but I think that Boost
ought to adopt something like Adobe's move-aware standard container
collection, just to avoid layering issues (something in boost needs a
move-aware container, so it uses ASL, which in turn uses boost).
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk