Re: RFC: api.value.automove

[Frank Heckenbach]

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