Daniel James wrote:
2008/6/23 David Abrahams <dave@boostpro.com>:
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