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

From: Daniel James (daniel_james_at_[hidden])
Date: 2008-06-22 17:00:36

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

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.

I'm not going to work on a new way of making the container itself
movable when its elements aren't. 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 think this might be a good idea. We could possibly bring together
all the containers from the C++0x draft (of the top of my head: your
containers, the unordered containers and Boost.Array). It'll also be
good to cooperate when implementing some of the latest features (such
as 'emplace') which will probably require similar features across the
containers.

Daniel