[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
http://lists.gnu.org/archive/html/bug-bison/2018-04/msg00012.html).
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.
Regards,
Frank