Ilya Sokolov wrote:
Thomas Klimpel wrote:
It seems my answer to Oliver wasn't clear enough. This is not a problem of Boost.Move,
Yes, it is (arguably). The problem is that error is reported too late.
From my point of view, there is not much difference between link-time and compile-time. An error at run-time would be too late.
but a simple programmer error in "X X::create()" that would have a significant performance penalty even if the compiler/linker would accept the code.
There is no implementation of copy ctor in the original example. How compiler/linker could accept the code? What "performance penalty" you are talking about?
I'm talking about the BOOST_COPYABLE_AND_MOVABLE case. Most compilers won't do RVO for code written like "X X::create()".
Probably, but that is not important for me. I like the following benefits: - one macro less - uniformity between boost::movable_only and boost::noncopyable
You're probably right that a macro "BOOST_MOVABLE" just containing the conversion operators would be enough for the non-optimized mode. The BOOST_MOVABLE_BUT_NOT_COPYABLE case would derive privately from boost::movable_only and implement move constructor and move assignment operator, the BOOST_COPYABLE_AND_MOVABLE would just implement the correct move constructor and assignment operator. Regards, Thomas