Re: Growing stacks in C++

[Paul Hilfinger]

 > > 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