[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
Mon, 24 Dec 2018 18:40:08 +0100
> 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
>> that are not documented, and as such, are not considered part of the
> 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
>> 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.
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
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 !