Daniel James wrote:
On 22/06/2008, Ion Gaztañaga <igaztanaga@gmail.com> 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