Re: Comments in %union processed incorrectly

[Paul Eggert]

> Date: Tue, 1 Jan 2002 12:43:43 +0100
> From: Hans Aberg <address@hidden>
> 
> In the first C++ skeleton file, I merely replace the stacks using C++
> standard containers (or a custom stack). In the second C++ skeleton file, I
> merge the two or three parser stacks into a single one. I think this might
> provide a faster parser, as one then only has to make one allocation
> instead of two or three.

But the current code makes just one allocation, so that won't make any
difference.  Also, in the common case where the stack entries are one
word wide, the current code executes subscripting operations faster on
most hosts.

My guess is that the performance will be slightly worse with one
stack, but that it'll be fairly close.  The only way to find out for
sure is to measure....


> So one could not rely on replacing memcpy for any C++ class.

If I understand you correctly, in C++ one cannot safely use memcpy,
alloca, malloc, or free, as all of these primitives operate at a low
level (merely copying the data bytes, as it were), and this is not
safe if the arrays contain types that have nontrivial C++ constructors
and destructors.

In that case, the current bison.simple seems to be about right for the
subset of C++ that it attempts to handle.  It doesn't work with
nontrivial C++ constructors and destructors, and if your C++ compiler
works correctly you'll get a compile-time error.  Adding support for
nontrivial C++ can wait until after the next release.

That being said, I can see some simplifications of the current copying
code, which should make the code run faster in the non-GNU case, and
which apply to C as well as to C-like C++.  I'll propose these in a
separate message soon.