> On 18 Apr 2018, at 11:19, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
>> 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 d
Hans Åberg wrote:
> 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.
Not really dang
> On 18 Apr 2018, at 10:03, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
>>> On 14 Apr 2018, at 10:19, Frank Heckenbach wrote:
>>>
>>> Hans Åberg wrote:
>>>
>> Before it gets integrated into the Bison distribution, you might
>> want to put it in the package source directory.
Hans Åberg wrote:
> > On 14 Apr 2018, at 10:19, Frank Heckenbach 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 wan
> On 14 Apr 2018, at 10:19, Frank Heckenbach 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 t
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
> > mai
> On 14 Apr 2018, at 07:33, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
>>> On 10 Apr 2018, at 17:24, Frank Heckenbach wrote:
>>>
>>> Hans Åberg wrote:
>>>
Rename, if possible, all these patched files to location-c++17.cc,
stack-c++17.hh, etc, as they are not in the original d
Hans Åberg wrote:
> > On 10 Apr 2018, at 17:24, Frank Heckenbach wrote:
> >
> > Hans Åberg wrote:
> >
> >> Rename, if possible, all these patched files to location-c++17.cc,
> >> stack-c++17.hh, etc, as they are not in the original distribution.
> >
> > I called it stack-c++11.hh because it on
Hans Åberg wrote:
> > And I've explained why I didn't rename
> > location.cc. If you disagree, please reply to those posts of mine.
>
> You said it is the same, but 'patch' reported it patched, and it
> did not work with the original. So it should probably have a
> different name to avoid confusi
> On 10 Apr 2018, at 17:24, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
>> Rename, if possible, all these patched files to location-c++17.cc,
>> stack-c++17.hh, etc, as they are not in the original distribution.
>
> I called it stack-c++11.hh because it only uses move (C++11), not
> varia
> On 10 Apr 2018, at 17:24, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
>>> Don't forget to copy location.cc back to /usr/local/share/bison/.
>>> As I said, this file is the same between the old (C++03) and new
>>> (C++17) skeletons and therefore not included in my new skeleton.
>>> (You ca
Hans Åberg wrote:
> > Don't forget to copy location.cc back to /usr/local/share/bison/.
> > As I said, this file is the same between the old (C++03) and new
> > (C++17) skeletons and therefore not included in my new skeleton.
> > (You can also copy back stack.hh and lalr1.cc, if you want full
> >
> On 9 Apr 2018, at 20:36, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
So, try this:
cd /usr/share/bison
sudo patch < /path/to/extra-header-prefix.diff
cd /your/source/dir
rm -f stack.hh position.hh location.hh
make clean
make
>>>
>>> I wouldn't do
Hans Åberg wrote:
> >> So, try this:
> >>
> >> cd /usr/share/bison
> >> sudo patch < /path/to/extra-header-prefix.diff
> >> cd /your/source/dir
> >> rm -f stack.hh position.hh location.hh
> >> make clean
> >> make
> >
> > I wouldn't do that for two reasons: screwing up the installation, and
> >
> On 9 Apr 2018, at 20:25, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
>>> So, try this:
>>>
>>> cd /usr/share/bison
>>> sudo patch < /path/to/extra-header-prefix.diff
>>> cd /your/source/dir
>>> rm -f stack.hh position.hh location.hh
>>> make clean
>>> make
>>
>> I wouldn't do that for t
> On 9 Apr 2018, at 20:15, Hans Åberg wrote:
>
>> On 9 Apr 2018, at 19:19, Frank Heckenbach wrote:
>>
>> Hans Åberg wrote:
>>
>> You should apply the patch in /usr/share/bison (or your respective
>> Bison data directory), not in your build directory (where a stack.hh
>> exists, but is differ
Hans Åberg wrote:
> > So, try this:
> >
> > cd /usr/share/bison
> > sudo patch < /path/to/extra-header-prefix.diff
> > cd /your/source/dir
> > rm -f stack.hh position.hh location.hh
> > make clean
> > make
>
> I wouldn't do that for two reasons: screwing up the installation,
> and security reaso
> On 9 Apr 2018, at 19:19, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
> You should apply the patch in /usr/share/bison (or your respective
> Bison data directory), not in your build directory (where a stack.hh
> exists, but is different, being generated from the stack.hh
> template, so th
Hans Åberg wrote:
> Not that the patch is not for files with 'c++17-' in them.
Exactly. For the c++1[17] files, I provided the patched ones in my
original archive. But location.cc is used otherwise unchanged, so it
needs to be patched separately (didn't want to call it
location-c++17.cc as there'
> On 9 Apr 2018, at 18:55, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
>>> position.hh is also generated from location.cc (a bit confusing
>>> perhaps; not my choice). If you remove all generated files and start
>>> from scratch, does it work for you with the above patch?
>>
>> It is malfo
Hans Åberg wrote:
> > position.hh is also generated from location.cc (a bit confusing
> > perhaps; not my choice). If you remove all generated files and start
> > from scratch, does it work for you with the above patch?
>
> It is malformed, perhaps mangled by the mailing system: they
> should be
> On 9 Apr 2018, at 18:19, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
>>> On 9 Apr 2018, at 17:04, Frank Heckenbach wrote:
>>>
The option
%define extra_header_prefix {calc-c++17-}
does not seem to work: I got both location.hh and position.hh.
>>>
>>> Ah, sorry, I think yo
> On 9 Apr 2018, at 18:17, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
>>> So for C++ we could either go back and disable the static type
>>> checking completely, or do full dynamic checking (which std::variant
>>> does by itself). I choose the latter. As you said, the performance
>>> impac
> On 9 Apr 2018, at 18:16, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
One can have a preprocessor macro '#if (__cplusplus == 201703L) ...',
would it be of interest.
>>>
>>> What would it do? (BTW, I think it should be ">=".)
>>
>> Something like, but with suitable template arg
> On 9 Apr 2018, at 18:16, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
One can have a preprocessor macro '#if (__cplusplus == 201703L) ...',
would it be of interest.
>>>
>>> What would it do? (BTW, I think it should be ">=".)
>>
>> Something like, but with suitable template ar
Hans Åberg wrote:
> > On 9 Apr 2018, at 17:04, Frank Heckenbach wrote:
> >
> >> The option
> >> %define extra_header_prefix {calc-c++17-}
> >> does not seem to work: I got both location.hh and position.hh.
> >
> > Ah, sorry, I think you need to apply my original patch from
> >
> > http://lis
Hans Åberg wrote:
> > So for C++ we could either go back and disable the static type
> > checking completely, or do full dynamic checking (which std::variant
> > does by itself). I choose the latter. As you said, the performance
> > impact should be small, and the safety benefit substantial. (If
>
Hans Åberg wrote:
> >> One can have a preprocessor macro '#if (__cplusplus == 201703L) ...',
> >> would it be of interest.
> >
> > What would it do? (BTW, I think it should be ">=".)
>
> Something like, but with suitable template arguments:
>
> #if !(__cplusplus >= 201703L)
> namespace std {
>
> On 9 Apr 2018, at 17:04, Frank Heckenbach wrote:
>
>> The option
>> %define extra_header_prefix {calc-c++17-}
>> does not seem to work: I got both location.hh and position.hh.
>
> Ah, sorry, I think you need to apply my original patch from
>
> http://lists.gnu.org/archive/html/bug-bison/20
> On 9 Apr 2018, at 16:55, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
But, anyway, GCC7 supports C++17.
>>>
>>> Yes, and I've also tested it with gcc-6 with mpark's variant.
>>
>> One can have a preprocessor macro '#if (__cplusplus == 201703L) ...', would
>> it be of interest.
>
>
> On 9 Apr 2018, at 16:55, Frank Heckenbach wrote:
>
> Hans Åberg wrote:
>
Akim Demaille gave two motivations on not using this: avoiding the
external dependency, and the overhead of storing the type. I think
that the C++17 variants may have the latter, but it is not so
impo
Hans Åberg wrote:
> (As for the Makefile might have 'CXX = g++': My GCC7 is not named 'g++-7'.)
Indeed. That was left over from my various tests.
> The option
> %define extra_header_prefix {calc-c++17-}
> does not seem to work: I got both location.hh and position.hh.
Ah, sorry, I think you ne
Hans Åberg wrote:
> >> Akim Demaille gave two motivations on not using this: avoiding the
> >> external dependency, and the overhead of storing the type. I think
> >> that the C++17 variants may have the latter, but it is not so
> >> important on modern computers.
> >
> > Yes, they do, and it's n
> On 8 Apr 2018, at 23:05, Frank Heckenbach wrote:
>
> Following the discussion starting in
> http://lists.gnu.org/archive/html/bug-bison/2018-03/msg2.html
> I have implemented a Bison skeleton for C++17 supporting features
> such as move semantics and std::variant, based on the existing C++
> On 9 Apr 2018, at 00:17, Frank Heckenbach wrote:
>
>>> On 8 Apr 2018, at 23:05, Frank Heckenbach wrote:
>>
>>> - Uses std::variant (C++17) instead of Bison's own variant
>>> implementation.
>>>
>>> If you don't have C++17 support yet, you can use an alternative
>>> variant implementation su
Hans Åberg wrote:
> > On 8 Apr 2018, at 23:05, Frank Heckenbach wrote:
>
> > - Uses std::variant (C++17) instead of Bison's own variant
> > implementation.
> >
> > If you don't have C++17 support yet, you can use an alternative
> > variant implementation such as https://github.com/mpark/vari
> On 8 Apr 2018, at 23:05, Frank Heckenbach wrote:
> - Uses std::variant (C++17) instead of Bison's own variant
> implementation.
>
> If you don't have C++17 support yet, you can use an alternative
> variant implementation such as https://github.com/mpark/variant .
> Boost.Variant might als
Hi,
Following the discussion starting in
http://lists.gnu.org/archive/html/bug-bison/2018-03/msg2.html
I have implemented a Bison skeleton for C++17 supporting features
such as move semantics and std::variant, based on the existing C++
skeleton. It is included in this mail.
To use the new ske
38 matches
Mail list logo
