Hi Antony, On Monday, 15. April 2013 13:19:26 Antony Polukhin wrote:

2013/4/15 Jürgen Hunold <jhunold@gmx.eu>:

...

Hi!

It seems that introducing move semantics to Boot.Any in r 83901 breaks compilation of program_options.

/home/hunold/src/devel/boost/boost/program_options/variables_map.hpp:58:38 : note: no known conversion for argument 1 from ‘boost::program_options::variable_value’ to ‘boost::program_options::variable_value&’

Full build log attached.

Any Ideas?

This looks like Boost.Move known limitation: http://www.boost.org/doc/libs/1_53_0/doc/html/move/emulation_limitations.htm l#move.emulation_limitations.assignment_operator

Thanks. Clang had a better diagnostic, so I figured out I had to implement operator= (patch attached) to get this working.

I'm afraid that this will confuse a lot of people who use Boost.Any... May be it would be better to disable ravlue emulation and use rvalues only in C++11?

I'm only using ProgramOptions at the moment. And not following the move discussion for pre-c++11 not closely enough to comment on this. C++11 only support for be enough for me. My 0.02€. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

On Mon, Apr 15, 2013 at 8:58 AM, Steven Watanabe <watanabesj@gmail.com>wrote:

AMDG

On 04/15/2013 02:19 AM, Antony Polukhin wrote:

...

This looks like Boost.Move known limitation:

http://www.boost.org/doc/libs/1_53_0/doc/html/move/emulation_limitations.htm...

...

I'm afraid that this will confuse a lot of people who use Boost.Any... May be it would be better to disable ravlue emulation and use rvalues only in C++11?

Yeah. Adding Boost.Move emulation in existing libraries is probably a bad idea.

Should be almost as good to change Boost.Any's copy assignment operator to accept by value on C++03 and implement as swap, no? And keep the move constructor and move assignment for both C++03 and C++11. C++11 copy assignment would continue to accept by reference-to-const. - Jeff

Antony Polukhin wrote:

2013/4/15 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com>:

...

On Mon, Apr 15, 2013 at 8:58 AM, Steven Watanabe <watanabesj@gmail.com>wrote:

...

Yeah. Adding Boost.Move emulation in existing libraries is probably a bad idea.

Should be almost as good to change Boost.Any's copy assignment operator to accept by value on C++03 and implement as swap, no? And keep the move constructor and move assignment for both C++03 and C++11. C++11 copy assignment would continue to accept by reference-to-const.

Just removed rvalues emulation via Boost.Move from Boost.Any.

Now rvalues of Boost.Any work only on C++11 compilers (r83917, #6999).

If the problem is that the compiler can't generate implicit copy assignment when your class with move emulation is wrapped in some other one, you might leave move emulation and just add an explicitly defined copy assignment if there is no rvalue references support. It won't generate rvalue reference when the object is returned from a function but it will be possible to move objects. And it will be backward compatible. Regards, Adam Wulkiewicz