Re: C++17 skeleton with move semantics and std::variant

[Frank Heckenbach]

Hans Åberg wrote:

> >> Before it gets integrated into the Bison distribution, you might
> >> want to put it in the package source directory.
> > 
> > I won't for my code (but you, or anyone else, may want to). FWIW, I
> > need patches to some Debian packages, some of them for years as many
> > maintainers don't seem very interested in bug fixes (that don't
> > affect them personally), unfortunately. So I keep a directory of all
> > such patches, so I can easily reapply them after upgrades, and my
> > Bison patch will just join them there, until it's integrated, or
> > otherwise forever (probably not the only one): ...
> 
> I meant in the source directory of your program.

I understood that. I won't put it in my source directory, just like
I won't put patches to JACK, FTGL and other long-time-no-maintenance
packages there. I put those patches separately, install them once
when I set up a new system, and keep my source code clean.

> >> I was able to do it, with the following changes:
> >> 
> >> In the .yy file, I had to put in "./", to:
> >>  %skeleton "./lalr1-c++17.cc"
> >> There seems to be a bug in Bison 3.0.4, looking only in the installation 
> >> directory if it is not there.
> > 
> > Bug or feature, I don't know. Maybe it's supposed to work this way.
> 
> Check %skeleton in Bison Declaration Summary, 3.7.12.

So the behaviour seems correct, to find it in the current directory
you do need "./":

: If file does not contain a /, file is the name of a skeleton file in
: the Bison installation directory. If it does, file is an absolute
: file name or a file name relative to the directory of the grammar
: file. This is similar to how most shells resolve commands.

> > I will now submit my changes to savannah. If the maintainers react
> > to them, great, and we can discuss the details; otherwise, I think
> > doing anything else now would just be a waste of time.
> 
> If you get it accepted, there may not be need for special file
> names: It would suffice to set '#if (__cplusplus >= 201103L)'
> around the C++11 code.

Not sure. My code changes user-visible behaviour (e.g. building of
tokens, see my reply to Piotr), and changes the available
%directives, so it doesn't seem suitable to make all that dependent
on the compiler settings. Also, the skeletons would get (even more)
unreadable, containing near-duplicated versions of a lot of code.

I think in this regard, it's better to consider C++03 and C++17 two
different languages, like C vs. C++. In the long run, maybe the
C++03 skeleton can be faded out, but that's not my decision to make.

Regards,
Frank