> > The Bison documentation says that due to technical differences
> > between C
> > and C++, a C++ compiler wouldn't be able to compile or properly
> > execute
> > (not clear which) a Bison C program that tried to grow the parser
> > stack. What exactly is this technical difference? Producing a C++
> > program using the C skeleton (not lalr1.cc), tweaking the generated
> > code
> > to expand the parser stack regardless of __cplusplus, and compiling
> > with
> > C++ works in at least simple cases. What's the problem?
>
> One problem is that the C stack does not call C++ copy constructors
> when reallocating. So one can only use a POD semantic value.
I was indeed aware of the non-POD issue. However, this problem already
prevents the use of %union in C++ files if any members have constructors
or destructors. If one uses a %union that is legal for C++, is there
any other issue that prevents expansion of stacks? I intend to remove
the __cplusplus test for exandability in glr.c.
> But you have phrased is as an all through C program compiled as C++.
> That must work if the C parser and the program is written in the
> subset common to C++.
So I would assume. The documentation, therefore, seems to be slightly
misleading when it says:
Because of semantic differences between C and C++, the deterministic
parsers in C produced by Bison cannot grow when compiled by C++
compilers. In this precise case (compiling a C parser as C++) you are
suggested to grow `YYINITDEPTH'. The Bison maintainers hope to fix
this deficiency in a future release.
I suggest the paragraph be modified to say "when the semantic types have
constructors or destructors" or something of the sort.
BTW: I observe that ISO C++ has a template function
std::uninitialized_copy, defined in <memory>, which ought to work for
copying a stack properly.
Paul Hilfinger
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
