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