Hi Wolfgang, > Le 24 déc. 2018 à 02:50, Wolfgang Thaller <[email protected]> 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 !
