Re: Bison 1.30f

[Paul Eggert]

> Date: Fri, 14 Dec 2001 11:26:52 +0100
> From: Hans Aberg <address@hidden>
> 
> 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.

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

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

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

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.