On 20 Oct 2007, at 21:31, David Fang wrote:
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.
(This is not the issue of the original problem, but I'll address
this while I'm at it.) If fact, I do use POD pointers in the
semantic type in a %union. I'm not depending on bison's C skeleton
for C++ features and semantics, those are merely in the way I use
the semantic types in my actions (e.g. member functions, calls to C+
+ library). And the source transformation I do emits type-safe
clean-up functions equivalent to %yydestruct before it came along
-- I still support older versions of bison and traditional yacc,
since many distros/vendors have not caught up. Anyways, back to
the original issue...
So then it might work, though you are on your own.
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.
It's clear where you stand on that matter, however, I ask you
+developers to consider the attached patch (for yacc.c) in bison 2.3
+ (looks similar to 2.1). This should not perturb C usage of the C
skeleton, only improve support for use with C++ in the rare case
I've encountered. It would be a shame to drop C++ compiling of the
C skeleton, since it has worked so well for such a long time -- it
has completely C++-warning-clean even with the strictest options.
(Or please give a reason why this patch won't work or is too
risky.) I am willing to help maintain unofficial support. :
You can send it to the Bison-Patches list. But it was decided once
for all, several years ago, to not support compile C as C++.
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.
Sure, the two parsers should be separate since they are different,
I'm not asking for a feature of one to be ported to the other.
However, for compatibility reasons, I cannot ask my users to use
the experimental C++ parser, just not yet.
It is not experimental. Compile C as C++ always was.
Hans Aberg
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison