[Top][All Lists]

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

Re: syntax_error constructor is declared inline

From: Frank Heckenbach
Subject: Re: syntax_error constructor is declared inline
Date: Wed, 09 May 2018 05:00:16 +0200

Hans Åberg wrote:

> > On 8 May 2018, at 11:13, Akim Demaille <address@hidden> wrote:
> > 
> > I'm all rusted on Bison.
> Welcome back, though!

Yes, nice to see you again!

> >> I will apply this patch in my C++17 version, but since I'm not a
> >> Bison maintainer, I can't promise it will go in the C++98 parser, or
> >> in the official Bison sources at all. For now, you can apply the
> >> patch manually (your installation directory may vary).
> > 
> > I will try to make soon a maintenance release of Bison, with
> > bug fixing and gnulib updates.  Then it will be great to address
> > modern C++.  However, I'd prefer sticking to a single skeleton
> > rather than having to maintain several (not to mention the CI
> > headaches...)
> That is what I thought, too. The fixes that Frank made requires
> only C++11 from what I understand, except that C++17 comes in when
> using variants, though there is an easy workaround to use external
> ones.

In fact, I'm mostly using g++6 in C++14 mode with mpark's variant
implementation currently (occasionally testing with g++7 in C++17
mode with std::variant). I can't test my actual parsers in C++11
mode as my application code requires C++14, but I don't think I've
used C++14 features in my skeletons (and if so, probably minor ones
that can easily be removed).

> Your idea of letting Bison to keep track of the type does not work
> in mid-actions as it is needed to decide which copy constructor to
> use, unlike C then.

And likewise for %destructor and %printer.

My skeletons are not 100% drop-in replacements (e.g., see the small
change required in
I don't know how widely the C++ skeletons are used and if we can
expect users to make such changes. In the long run, I think having
only one skeleton will be much better.


reply via email to

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