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

From: David Abrahams (dave_at_[hidden])
Date: 2008-06-23 16:26:44

Daniel James wrote:
> 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,

Agreed.

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

If you have been proposing some kind of external adaptation that allows
the library to recognize the funky conversions used... that makes sense
and I don't have any better ideas.

A few litmus tests we could consider are the ability to work with
http://www.coderage.com/move_ptr, the usual std::auto_ptr
implementations, and the one proposed in
http://groups.google.com/group/comp.std.c++/msg/71e5799e3c1b70c7

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

Well, yeah, but I mean for the regular std:: containers

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com