[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: api.value.automove

From: Frank Heckenbach
Subject: Re: RFC: api.value.automove
Date: Fri, 21 Sep 2018 19:54:00 +0200

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]