[Top][All Lists]
[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
- Re: Bison 1.30f, (continued)
- Re: Bison 1.30f, Hans Aberg, 2001/12/12
- Re: Bison 1.30f, Paul Eggert, 2001/12/12
- Re: Bison 1.30f, Hans Aberg, 2001/12/12
- Re: Bison 1.30f, Paul Eggert, 2001/12/12
- Re: Bison 1.30f, Hans Aberg, 2001/12/13
- Re: Bison 1.30f, Akim Demaille, 2001/12/13
- Re: Bison 1.30f, Hans Aberg, 2001/12/13
- Re: Bison 1.30f, Paul Eggert, 2001/12/13
- Re: Bison 1.30f, Hans Aberg, 2001/12/14
- Re: Bison 1.30f, Paul Eggert, 2001/12/14
- Re: Bison 1.30f,
Hans Aberg <=
- Re: Bison 1.30f, Paul Eggert, 2001/12/14
- Re: Bison 1.30f, Hans Aberg, 2001/12/15
- Re: Bison 1.30f, Akim Demaille, 2001/12/15
- Re: Bison 1.30f, Hans Aberg, 2001/12/15
- Re: Bison 1.30f, Hans Aberg, 2001/12/15
- Re: Bison 1.30f, Paul Eggert, 2001/12/17
- Re: Bison 1.30f, Paul Eggert, 2001/12/16
- Re: Bison 1.30f, Hans Aberg, 2001/12/16
- Re: Bison 1.30f, Paul Eggert, 2001/12/17
- Re: Bison 1.30f, Hans Aberg, 2001/12/18