Re: bison'd files don't compile under Microsoft VC++

[Hans Aberg]

At 11:39 -0800 2002/02/14, Paul Eggert wrote:
>> these developers on the one hand put off the genuine C++ issue off
>> indefinitely for a long period of time (several years), while on the
>> same time compiling the C parser as C++ in their own projects. Then
>> one day, their own C++ projects started to break, because they got
>> hold of a C++ compiler that checked the C++ code properly, catching
>> errors in the earlier dirty compile C as C++ code.
>
>I believe you're referring to the fact that Bison has never supported
>C++ objects on the stack that require constructor/destructor support.
>If so, the current situation is an improvement, since the newer C++
>compilers now are rejecting such parsers at compile-time, rather than
>having the code fail mysteriously at run-time.

Not really, because I think a correct C+ compiler will always reject the
code. This makes the C++ compatibility somewhat funny, if one never can
compile it using a correct C++ compiler.

I think that the problem is (bison.simple) the type
  /* A type that is properly aligned for any stack member.  */
  union yyalloc
which is somehow used to compute the alignments of the dynamic stack.

By contrast, a correct C++ compatibility feature would only complain when
YYSTYPE has (say) types with non-trivial constructors. (Or strictly, when
the copy constructors disagrees with raw memory copying.)

But I don't know of a good way to implement such a thing.

>This problem as far more serious than the namespace problem, since the
>namespace problem is easily worked around,

Right. This is what I have tried to say all along.

> whereas there's often no
>good substitute for having full-fledged objects on the stack.

Right. For this, it seems best to use real C++ containers, like the
standrad ones. This is essentially what I did in my C++ skelton file.

> On my
>list of things to do is to fix the C parser so that it is properly
>robust even in this situation.  However, this fix is not something
>that I want to put into the next minor release, as it will take some
>time to shake out the porting bugs.  It should wait for a major
>release.

I think that you just should drop this altogether, and wait for real C++
support if that is near (within two months).

Or do you have any need for a compile C as C++ feature if real C++ support
is at hand?

>> >The fact that Bison parsers used to work with C++ in the past is
>> >more by accident than by design.
>>
>> It was actually by design, ...
>
>What gives you that impression?  It's news to me.

This was my impression from comments by Akim in the Bison mailing lists,
where he suggested one to use the compile C as C++ feature. He said he had
used that feature in a major C++ project that later broke, so I just
guessed it was not purely by accident. -- But I do not know. :-)

  Hans Aberg