bug-bison
[Top][All Lists]
Advanced

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

Re: GLR C++ Variants


From: Valentin Tolmer
Subject: Re: GLR C++ Variants
Date: Mon, 13 Jan 2020 14:51:26 +0100

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



reply via email to

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