Re: Bison 1.30f

[Hans Aberg]

At 16:16 -0800 2001/12/14, Paul Eggert wrote:
>I'm sure.  I know that the Bison-generated parser copies values of
>those types.

This is not a problem, as the C++ classes will be expected to have copy
constructors. All, the std containers expect that, so that seems reasonable
also for Bison.

In the example I gave, the problem was not that $$ = $1 invokes a copy
constructor, but that it performs two actions when only one was expected.

>  It assumes that the values can be copied merely by
>copying their bits.  It uses memcpy in places.

Can you give examples of this (so I can think more about it)?

>> I always use C++, and apart from the problem mentioned above, I have not
>> found any problems.
>
>You're lucky.  :-)

I figure that there are some standard ways to implement a C++ compiler,
which most compilers use, and as long as that happens, one is lucky. But,
as you say, there are non-standard ways to implement a C++ cmopiler, in
which case one might be unlucky.

>> Recall that Bison already allows one to change yy to something
>> else, which I figure isn't Yacc then.
>
>No, POSIX standardizes that too.

What exactly does POSIX say in the following sense: I figure POSIX says
something the presence of a Yacc compatible program.

It cannot be the case that POSIX says everything about every
compiler-compiler present on a compiler.

So as for Bison, this should mean that there should be present a POSIX Yacc
compatibility mode, which users can invoke.

>> >I don't think C++ should be any different from C here.  Any advantages
>> >of name space cleanness would be far outweighed by the disadvantages
>> >of incompatibility and confusion.
>>
>> Yacc did not produce C++ originally,
>
>Bison should treat C and C++ as similarly as possible, at least in its
>current configuration where it generates a single parser that works
>with both C and C++.  This simplifies things for both maintainers and
>users.  If it's not elegant C++, then that's too bad, but the problem
>of inelegance is unavoidable.
>
>If someone wants to modify Bison to optionally produce a C++-only
>parser that is "tuned" for C++, that would be a different story.  But
>that's a larger project that I have neither the time nor the expertise
>for.  And I'm not sure that all C++ programmers would agree that it's
>worth diverging from C in this matter, even in a C++-only parser.

This is also what I meant: I had the specifically C++ parser generator in mind.

It should be using the std library and as much possible of the other C++
stuff possible, in order to be sure that the sue with C++ becomes as
accurate and efficient as possible.

As for the current bison.simple, it looks like not too difficult to make a
C compile as C++ mode, and there would be no point in trying to extend it
beyond that scope.

  Hans Aberg