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.
Hi,
(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...
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. :D
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.
Fang
David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)--- yacc-orig.c 2007-10-20 14:39:28.000000000 -0400
+++ yacc.c 2007-10-20 14:51:21.000000000 -0400
@@ -344,13 +344,24 @@
# ifndef YYMALLOC
# define YYMALLOC malloc
# if ! defined malloc && ! defined _STDLIB_H && ]b4_c_modern[
+# if defined(__cplusplus)
+ /* in case malloc has exception specification */
+# include <cstdlib>
+using std::malloc;
+# else
void *malloc (YYSIZE_T); /* INFRINGES ON USER NAME SPACE */
+# endif
# endif
# endif
# ifndef YYFREE
# define YYFREE free
# if ! defined free && ! defined _STDLIB_H && ]b4_c_modern[
+# if defined(__cplusplus)
+# include <cstdlib>
+using std::free;
+# else
void free (void *); /* INFRINGES ON USER NAME SPACE */
+# endif
# endif
# endif
# endif
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
