> 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.

Reply via email to