Re: assertion failure / double destruction triggered by parser::symbol_type's move constructor

[Akim Demaille]

Hi Wolfgang,

> Le 24 déc. 2018 à 02:50, Wolfgang Thaller <address@hidden> a écrit :
> 
>> Yes, I agree.  See the patch below.
> 
> Great! That was quick, looking forward to 3.2.4 :-)

I just released it.  It includes a copy ctor.


>> The thing is that I don't know how people are using these types: they do 
>> things 
>> that are not documented, and as such, are not considered part of the 
>> contract.
> 
> The contract was, “you can write a yylex that returns this type”, and before 
> C++11 this
> meant that there *had* to be a copy constructor.

Well, RVO plays a role here, but I guess the difference is that you had a local 
variable, whereas I directly return (r)values.  NRVO is harder.


>> Why exactly do you need the copy constructor?  symbol_type was designed to 
>> be 
>> the return value of yylex, so it's not really needed.  I need to know how 
>> people use it :)
> 
> In my case it was just that I had written a wrapper whose only purpose was to 
> be able to forward-declare it without including the generated header file, 
> and I am not even sure any more why I explicitly mentioned the copy 
> constructor in there.

Ok.

Why do you want to avoid including the header?  What could have we done to 
spare you this effort?


> I like copy and assignment support for symbol_type as a matter of preference, 
> but I don’t need it (any more - and my fix is backwards-compatible to bison 
> 3.0).

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.


> It might be a good idea to make people write more efficient code by not 
> copying stuff that might contain expensive things like std::string; on the 
> other hand, when people write complex logic in an yylex function, it might 
> sometimes be more convenient to just copy stuff.

Well, I was indeed trying to push them to something faster.

> I’d lean towards making the symbol class as general-purpose as is reasonable 
> - who knows, maybe someone wants to implement some macro expansion feature at 
> the token level?

Yes.  Or maintain a queue of tokens to backtrack.  I agree it makes sense to 
make symbol_type a regular type.

> Joyeux Noël !

Wow, if that was without cheating, congratulations :)  Yet I need Google to 
answer, although my wife is German...  Shame on me.

Frohe Weihnachten !