Subject: Re: [boost] [GSoC 2013] Moving to Boost to Boost.Move
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-27 09:00:50
Le 27/04/13 09:05, Antony Polukhin a écrit :
> 2013/4/27 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>:
>> In case there are some students that are looking for a last idea.
>> There a re a lot of Boost libraries that don't support move semantics.
>> It would be nice if one student propose to adapt the some of the existing
>> The idea is to use Boost.Move so that an emulation is provided for compilers
>> not supporting rvalue references.
>> Accepted for C++14
>> *  optional
> As I know author of the library is now working on that.
>> *  Function
> Added move assignment and move constructor for C++11 compilers a few
> releases ago.
>> *  Any
> Added rvalues support to trunk version for C++11 compilers
>> *  Variant
> Rvalues work since last release for C++11 compilers
Glad to see that Boost libraries are moving to C++11 move semantics.
I was locking on the documentation of some of these libraries and I
didn't found too much. Is this documented?
Maybe we can at least add the C++11 move semantic on the libraries that
are not providing it now. This will be better than nothing.
> Boost.Move is not always suitable for old libraries, it may break
> users code http://www.boost.org/doc/libs/1_53_0/doc/html/move/emulation_limitations.html#move.emulation_limitations.assignment_operator
> . There was a thread about that
> http://lists.boost.org/Archives/Ioost/2013/04/202436.php .
The link doesn't works.
> It would be great to provide rvalue references for old Boost libraries
> just for C++11 compatible compilers, without Boost.Move usage.
I can understand that having C++11 move semantics could be enough for
you (I will be in your place ;-) but others could not move to them.
What are the benefit of Boost.Move into Boost if we don't make use of
it, at least on all the Boost libraries having an equivalent on C++11?
> Also, I would like to add
> *  Bimap
> to list.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk