Re: Bison 1.30f

[Paul Eggert]

> Date: Fri, 14 Dec 2001 22:41:16 +0100
> From: Hans Aberg <address@hidden>

> >I can't imagine that this is the only instance of this problem in the
> >current code.  C++ parsers will simply have to not use a type that is
> >subject to the problem.
> 
> I am not sure there are any other problems with the C++ interpretation, if
> the code only makes sure to apply the actions when they are actually called
> for.

I'm sure.  I know that the Bison-generated parser copies values of
those types.  It assumes that the values can be copied merely by
copying their bits.  It uses memcpy in places.  This is a safe
assumption for C.  I don't think it's trivial to fix it for the C++
types that you mention.

> I always use C++, and apart from the problem mentioned above, I have not
> found any problems.

You're lucky.  :-)

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

No, POSIX standardizes that too.

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