On 20 Oct 2007, at 10:09, David Fang wrote:
I meant: do you Bison-compile to generate C or C++ output.
I generate the C LALR(1) output, but compile it in C++ (using STL
containers and algorithms). (I also perform some major
postprocessing and automatic source-rewriting on the resulting .cc
file, but that doesn't change the current problem.)
That is not supported. It might work if you use a POD in the semantic
type (a must if %union is used), but the C output does support C++
copy constructors when the parser stack is reallocated.
Once upon the time, the C output had informal support for C++, but
that was dropped, I think. The "if __cplusplus" suggests you have
some compile for C that does not work with C++.
I'm not sure what ever happened officially. But I have been using
the C lalr1 skeleton in C++ compiles for years (from v. 1.35 to
2.3, also good-old Berkeley yacc) on FreeBSD, SuSE-linux, Mac OS X,
without ever having run into this problem (or other problems for
that matter), until someone else reported this build-fail on
ubuntu6. I've been counting on that LALR C skeleton to be rather
stable, which is why I compile it instead of the C++ parser.
My impression was that the C output is still supported with C++
compilation given the success I've had with it, and seeing evidence
of accommodating C++ in the resulting output. (It would be a good
thing to maintain!) Since this (above) seems like an easy and safe
fix, I hope that it might be adopted. I can generate the proposed
patch after I get some test feedback from the reporter.
Compile C as C++ was never officially supported, but some time
inofficially.
But because of problems with that, it was decided to keep C and C++
skeletons and thus parser output separate.
So for C++, use a C++ parser output.
Hans Aberg
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison