Re: C++17 skeleton with move semantics and std::variant

[Frank Heckenbach]

Hans Åberg wrote:

> >> Akim Demaille gave two motivations on not using this: avoiding the
> >> external dependency, and the overhead of storing the type. I think
> >> that the C++17 variants may have the latter, but it is not so
> >> important on modern computers.
> > 
> > Yes, they do, and it's needed. That's exactly what fixes the
> > problems with $<type> -- the type must be stored somewhere.
> > 
> > Not storing the type seems a nifty idea with Bison which knows about
> > the type most of the time, but it breaks down just there.
> 
> Perhaps there is a bug in %union in the same place then, as it does not store 
> the type.

I'm not so familiar with the C skeleton, but I think the difference
is that %union is completely unchecked. Store foo, retrieve foo, all
is fine; store foo, retrieve bar, get garbage (UB).

Whereas the C++ skeleton adds some checking (only statically) which
results in $<type> not working at all. If it didn't do that (that's
where I wrote "if not for the previous bug"), the behaviour would be
similar to the C version, just a bit worse when types with
non-trivial constructors/destructors come into play.

So for C++ we could either go back and disable the static type
checking completely, or do full dynamic checking (which std::variant
does by itself). I choose the latter. As you said, the performance
impact should be small, and the safety benefit substantial. (If
someone doesn't want it, they might be able to use an alternative
variant implementation without checks, or not use variant at all
...)

> >> But, anyway, GCC7 supports C++17.
> > 
> > Yes, and I've also tested it with gcc-6 with mpark's variant.
> 
> One can have a preprocessor macro '#if (__cplusplus == 201703L) ...', would 
> it be of interest.

What would it do? (BTW, I think it should be ">=".)

I don't want the skeleton to depend on an external library (and as I
said, there might be at least two candidates), so I think it's
better to leave it to the user. (For me, I've put mpark's variant
header in /usr/local/include for g++-6 to use, while g++-7 will use
its own variant implementation, so the parser will work with both
compilers without change.)

Regards,
Frank