[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 02:50:44 +0100
> Yes, I agree. See the patch below.
Great! That was quick, looking forward to 3.2.4 :-)
> 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 contract.
The contract was, “you can write a yylex that returns this type”, and before
meant that there *had* to be a copy constructor.
But mainly, it’s just that I tend to assume that any type that is semantically
“just a value” (as opposed to holding resources or managing state) is
copy-constructible and assignable unless documented otherwise, and I got away
with it in bison 3.0.
> 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
> I'm fine with releasing 3.2.4 soon with this fix, and the copy support for
> symbol_type if you think it makes sense.
+1 for a soonish 3.2.4 with this fix. I haven’t yet figured out a way to make
my project work with 3.2 at all (bison invokes the broken move constructor on
the return value of my yylex, and crashes), so I have to tell people to either
downgrade or wait.
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
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. 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?
Joyeux Noël !