[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: assertion failure / double destruction triggered by parser::symbol_t
Re: assertion failure / double destruction triggered by parser::symbol_type's move constructor
Wed, 26 Dec 2018 07:06:30 +0100
> 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
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).