[Top][All Lists]

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

Re: assertion failure / double destruction triggered by parser::symbol_t

From: Akim Demaille
Subject: Re: assertion failure / double destruction triggered by parser::symbol_type's move constructor
Date: Wed, 26 Dec 2018 07:06:30 +0100

Hi Wolfgang!

> Le 25 déc. 2018 à 19:50, Wolfgang Thaller <address@hidden> a écrit :
>> Why do you want to avoid including the header?  What could have we done to 
>> spare you this effort?
> Nothing, really.
> The declaration of my lexer is visible from some other modules, and I was 
> trying to limit the amount of code I had to recompile when making many small 
> grammar changes. In my day job, I have to suffer through 5-minute-recompiles 
> for tiny changes, so I guess I just prefer to err on the side of “too much 
> decoupling”.

I understand that...  I have the same experience.  And I'm eager to use C++ 
modules and see what compile time speedup it provides us with.

>> I have not added the copy-assignment.  I'll address this in Bison 3.3 
>> instead, I think it was ok in 3.0 at all.

[was not ok]

> I agree. Bison 3.0 declared all assignment as private, so allowing assignment 
> is just “luxury” for the future.

My main goal was to make sure that _I_ was not making useless copies in the 
implementation of the parser itself.

>> Wow, if that was without cheating, congratulations :)  Yet I need Google to 
>> answer, although my wife is German...  Shame on me.
> J’ai verifié l’orthographie sur Internet… je n’etais plus sur. Est-ce qu’on 
> appelle ça «tricher» ?

Wow, ok, tu parles vraiment français sans difficulté :)   (let's go for "le 

Oui, ça s'appelle tricher :)

(minor nits: orthographe without 'i', j'étais, and sûr for "sure" — without the 
accent it's "on top of", but maybe your keyboard does allow you to type it).

reply via email to

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