Re: [boost] [move semantics] Containers supporting movable-only types

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:
> 
> http://stlab.adobe.com/group__concept__regular__type.html
> http://stlab.adobe.com/group__concept__movable.html

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,
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf).

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