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

[Frank Heckenbach]

Hans Åberg wrote:

> > On 14 Apr 2018, at 10:19, Frank Heckenbach <address@hidden> wrote:
> > 
> > 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.
> 
> That wouldn't work in a distribution, as the user may not want or
> be able to change installation.

One can always have a local installation. I prefer modularization;
I don't want to clutter my packages with foreign patches. It would
also make maintenance more difficult in the future; e.g. I've just
found an unrelated problem (https://savannah.gnu.org/patch/?9620)
that affects both the old and new skeletons. I applied it in my
Bison data file; otherwise I'd have to apply it in each of my
packages (and if some of them used the old skeleton, make a full
copy of them, and patch them).

Anyway, this is only my choice. As I said, anyone can do it as they
like.

> > 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.
> 
> But if someone uses their of variants type, would that require C++11?

Yes, the skeleton uses move semantics (i.e. rvalue references), so
C++11 is the minimum. (Not entirely sure if I accidentally used some
C++14 feature, as that's what I tested with besides C++17, but if
so, it may be rather easy to avoid.)

> > 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.
> 
> It would be best to just have one. But the variants may not have been used 
> much.

I have no idea how much they are used. I think/hope most of them
should be able to switch to the new skeletons rather easily (though
not entirely without changes, see above). And of course, I agree
that it would be best to just have one C++ skeleton, especially if
maintenance manpower is sparse.

Regards,
Frank