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 <a...@epita.fr> 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. _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison