Akim Demaille wrote: > > For std::unique_ptr, OTOH, it's > > guaranteed that it leaves it as nullptr. Can you use this in the > > tests? > > I was looking for a test that works with legacy and modern C++. > (But not expecting the same traces, of course. Just the same > outcome).
Implementing your own C++11-movable and otherwise copyable type might be the only way then. (It could be very simple, of course, like an int that's set to 0 when "moved".) > Yes, exactly. It's like when a C++98 project is compiled with > a C++11 compiler: your program is faster 'for free', thanks to > plenty of implicit moves and a library that is ready to embrace > them (e.g., all the operations on vectors). Indeed, the same would be true with Bison's internal moves at least. > That's why I was aiming first at not requiring modern C++ when > using automove: this way a project that does not require C++11 > can still compile in C++98, yet benefit from the move-speedup > if it turns out that the underlying compiler supports it. > > Hum. It seems that I'm convincing myself that I should accept > legacy C++ with automove :/. The question would then be: is > there a catch I did not see? Testing perhaps? Like if you enable automove, but keep testing with C++98 mostly and thus do not notice a bug caused by moving too much. But I'm not sure if a move-related bug is likely when Bison checks double-use. So perhaps no problem indeed. Regards, Frank
