From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2008-06-23 12:05:16
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.
>> 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,
> 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
Great. We should try to add MultiIndex, Bimap, CircularBuffer (and maybe
for some features Intrusive) to the game.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk