> On 9 Apr 2018, at 00:17, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > >>> On 8 Apr 2018, at 23:05, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: >> >>> - Uses std::variant (C++17) instead of Bison's own variant >>> implementation. >>> >>> If you don't have C++17 support yet, you can use an alternative >>> variant implementation such as https://github.com/mpark/variant . >>> Boost.Variant might also work; I have not tried it. >> >> 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. >> 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.