Daniel James wrote:
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 good.
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.
Great. We should try to add MultiIndex, Bimap, CircularBuffer (and maybe for some features Intrusive) to the game.
Daniel
Regards, Ion