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

From: Daniel James (daniel_james_at_[hidden])
Date: 2008-06-23 08:01:17

2008/6/23 David Abrahams <dave_at_[hidden]>:
>
> I have a hunch that it would be really easy to add support for move-only
> types, though.  Do you see any specific obstacles?

I haven't really thought about it much. Since there are already other
solutions, I thought the easiest thing might be to use one of them.
But I haven't looked at them in detail yet.

>> 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 believe that if the container uses the current Adobe move
implementation to make itself movable, then it will only be movable
when it is also copyable, which it won't be if the elements are
move-only. But we'd probably want the container to be movable in this
case, which would require something extra (the 'new way' I was
referring to). If it's easy to add support for move-only types, then
maybe this wouldn't be too much to do.

> 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).

I think that's pretty much what Ion is proposing for the Interprocess
containers.

Daniel