[Top][All Lists]

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

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

From: Hans Åberg
Subject: Re: C++17 skeleton with move semantics and std::variant
Date: Sat, 14 Apr 2018 10:43:13 +0200

> 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.

>>>> 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.

Yes. I was thinking about the program directory.

>>> 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.

But if someone uses their of variants type, would that require C++11?

> 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.

reply via email to

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