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