Re: Growing stacks in C++

[Akim Demaille]

Le 23 juil. 2010 à 00:00, Paul Hilfinger a écrit :

Hi Paul,

>>> 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 don't think so.

> I intend to remove
> the __cplusplus test for exandability in glr.c. 

I think this piece of documentation is completely obsolete and should be 
removed.  I have no idea about what I meant originally (it's coming from

commit d1a1114f7f257f89887ea5825ba0d896dfaa747b
Author: Akim Demaille <address@hidden>
Date:   Tue Sep 24 12:32:36 2002 +0000

    * doc/bison.texinfo (Stack Overflow): xref to Recursion.
    (Frequently Asked Questions, Parser Stack Overflow): New.
)

Also, Paul Eggert, being extremely cautious/suspicious(/nauseous?) when it 
comes to C++, might have added too many belts to the suspenders of the airbags, 
and vice versa (in addition to leaving the hand break blocked :).

About a related issue: the current C++ parsers use a deque to avoid having to 
move things around.  But I'm considering providing support for vectors, I doubt 
there are many non moveable structures out there.