Re: GLR C++ Variants

[Сергей Фасман]

Hello. I am looked in glr.cc and guessing, do we need to remove some
defines to stackp members and also move yyparse to class?

Also, I've find one TODO about constructor.

пн, 13 янв. 2020 г., 16:51 Valentin Tolmer <address@hidden>:

> Hi!
>
> On Sat, Jan 11, 2020 at 4:08 PM Akim Demaille <address@hidden> wrote:
> > > Le 11 janv. 2020 à 12:00, Сергей Фасман <address@hidden> a écrit :
> > > So, there are plans to rewrite GLR to C++. What expect to done first:
> variants or refactoring?
> >
> > Rewrite.  It's not about refactoring, it's about writing it from
> > scratch.  The lack of support for variants comes from the fact that
> > the core of glr.cc is glr.c, in a C style that does not respect
> > C++ object lifetime.  That's why it must be first rewritten in C++.
>
> This is correct, it started as a "refactoring" but feels more like a
> rewrite. Although we are keeping the algorithm, most of the code
> changes to introduce modern (or as modern as we can get while being
> retro-compatible) C++ equivalents and object support (constructor +
> destructor). There are some tricky challenges, which requires us to
> move slowly. Additionally, we're trying to keep the high performance
> that we had with the C code.
>
> You can see what I've been up to on the "glr_cc" branch on my github:
> https://github.com/nitnelave/bison/tree/glr_cc
>
> I've been mostly changing the glr.c code (copied to glr.cc) to look
> like C++, with classes, methods, and modern containers. Last I
> remember, I hit a snag trying to update an arena-style container with
> internal pointers to std::vector, due to the potentially moving
> memory. I had to stop for a while for personal reason, but I might get
> back on it soon.
>
> If you want to help, try to see what I've been doing, and see whether
> you can help. Maybe try checking the places where we would need to add
> constructor/destructor calls, in preparation for variants?
>
> If you have any question, I'll do my best to help.
>
> Cheers,
>
> --
> Valentin Tolmer
>