Hans Åberg wrote: > > On 8 May 2018, at 11:13, Akim Demaille <[email protected]> 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
