bug-bison
[Top][All Lists]
Advanced

[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: Wed, 18 Apr 2018 10:43:55 +0200


> On 18 Apr 2018, at 10:03, Frank Heckenbach <address@hidden> wrote:
> 
> 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.

Indeed. Others, may not want to patch their installations even it they can, as 
it may cause problems for other packages. Say if one writes package that uses a 
standard Bison installation, then it would be dangerous to patch it up with an 
experimental one.

It would be best if you could get your stuff integrated into the distribution, 
but if not, there might be the need for a workaround.

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

Would it in principle possible to use ones own variants that does not require 
C++11 and put the C++11 code within preprocessor directives so that it works 
for earlier C++ versions? - I am not sure there would be any use for this, just 
wondering.

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

Indeed. But that is for any eventual maintainer to decide.





reply via email to

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