Re: Comments in %union processed incorrectly

[Hans Aberg]

At 00:27 -0800 2002/01/03, Paul Eggert wrote:
>> 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.

I finished the macro interface, and started to see if it was implementable
in the C version, and then I noticed it. But in the C++ version, one is not
likely to get away with such a hybrid.

>  Also, in the common case where the stack entries are one
>word wide, the current code executes subscripting operations faster on
>most hosts.

This is correct, for every stack call, one will have one extra machine
instruction computing the offset, it seems. But it will make no practical
difference in terms of speed: Typical parsers do not spend much time in the
parser, but most of the time in the semantic code. And if it is possible to
optimize away any offset computation, the modern compilers will do that.

It's like the word "register" which is of no practical value with modern
compilers, as the compiler will know how to do that optimization anyway.

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

Right.

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

If the compiler works correctly, it should give an error when using a
union, but not when data is copied raw memory with memcpy.

The current bison.simple C & compile C as C++ file that we beefed up is
appropriate under C++ as long as one does not use the dynamic stack
reallocation that you have implemented, or when it is used, with C++ data
types T for which its copy constructors T::T(const T&) agrees with raw
memory copying (as when using memcpy).

When using %union and C++ data types T in that union having nontrivial
constructors, the problem is that with
  typedef union {
    T t;
    ...
  } U;
one does not when the default constructor, the destructor, and the copy
constructor T::T(const T&), should be appiled, as union's do not have any
runtime type information (RTTI) in them, telling which one to apply.

I also think that the current bison.simple should be kept within this
scope, and put correct C++ support for the 1.31+ versions.

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

This way you can concentrate on optimizing the C code without bothering
about the C++ problem: C++ is better at handling complex data types, and it
is inevitable that in doing that, some performance costs will show up.

  Hans Aberg