bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bison 1.30f


From: Hans Aberg
Subject: Re: Bison 1.30f
Date: Fri, 14 Dec 2001 22:41:16 +0100

At 10:33 -0800 2001/12/14, Paul Eggert wrote:
>> Here the code makes an unconditional assignment $$ = $1, in order to
>> implement the deafult in case no action has been given.
>>
>> The problem with C++ is that two $$ = $1 need not be equivalent to one
>> assignemnt $$ = $1, for example, that is the case of the std::auto_ptr.
>
>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. The problem here is that Bison may apply an action more than once:
Bison is making something funny, which the comment indicates, which also
can break semantically under C++.

>There are probably a lot of other undocumented constraints about C++
>code -- after all, Bison wasn't designed for C++ originally.  It would
>be nice if someone could go through the parser with a fine-tooth comb,
>find them all, and document them.  But this would be a nontrivial
>task, and require a C++ expert (which I am not).

If there are some such problems, one may discover them after a while.

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

>> Further, it may be time consuming, in view of that C++ admits one to write
>> ones own copy constructors, which might be compilicated.
>
>That's yet another argument for not using such types in a parser.
>I don't think this issue is worth worrying about in practice.

There is not a problem using large types if one has control over the
operations applied to them. Bison should not apply operations more than is
semantically expected from a parser.

>> As for the real C++ support, I think that names yyfoo should become
>> yy::foo, and YYFOO macro names should as far as possible be eliminated and
>> replaced by yy C++ names. For example, in C++, one might replace
>>   # define   help_key        258
>> by
>>   const int help_key = 258;
>> which would make use of fewer macros.
>
>For C, this would contradict the POSIX standard, which requires that
>the symbols be visible to the preprocessor.  It would also break some
>real code.

My guess that you speak about POSIX having some Yacc compatibility
instructions; right?

Then this would affect Bison's Yacc compatibility mode, but not a regular
Bison mode. Recall that Bison already allows one to change yy to something
else, which I figure isn't Yacc then. -- I always use that, because I often
use more that one parser. If one changes yy, then the POSIX ideas become
irrelevant, it seems.

In any way, I think that with the appropriate enhancement of the skeleton
file language, it would be easy to write out a label as either
   # define     help_key        258
or
   const int help_key = 258;
by choice of the Bison user.

>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, as C++ did not exist when Yacc was
constructed, and nor has POSIX any information about C++ I think. I have a
vague memory from some C++ newsgroup to this effect: If one does not like
POSIX macros, one can easily write a C++ compatibility header, putting
those in a C++ namespace named say POSIX, and then undefining those POSIX
macros.

So under C++, this stuff should be irrelevant.

  Hans Aberg





reply via email to

[Prev in Thread] Current Thread [Next in Thread]