Re: Bison 1.30f

[Hans Aberg]

At 18:09 -0800 2001/12/13, Paul Eggert wrote:
>> I am talking about _real_ C++ output, i.e., a Parser class.  You are
>> referring to making C parsers compile with strict C++ rules.
>
>OK, I see.  As far as I know we've achieved the latter (more modest)
>goal on GNU systems, and have come pretty close on non-GNU systems.
>(But I am not a C++ expert.)
>
>The former goal would be better, of course.

It might be good to keep the dual C/C++ compiling mode for the original
bison.simple, in view of the alloca issue.

One other C++ incompatibility I am aware of is the following
/*-----------------------------.
| yyreduce -- Do a reduction.  |
`-----------------------------*/
yyreduce:
  /* yyn is the number of a rule to reduce with.  */
  yylen = yyr2[yyn];

  /* If YYLEN is nonzero, implement the default value of the action:
     `$$ = $1'.

     Otherwise, the following line sets YYVAL to the semantic value of
     the lookahead token.  This behavior is undocumented and Bison
     users should not rely upon it.  Assigning to YYVAL
     unconditionally makes the parser a bit smaller, and it avoids a
     GCC warning that YYVAL may be used uninitialized.  */
  yyval = yyvsp[1-yylen];

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.
Further, it may be time consuming, in view of that C++ admits one to write
ones own copy constructors, which might be compilicated.

So for both types of C++ support (C compatibility and C++ paradigm) this
part must be changed.

Akim:
>> bison is meant to produce compilation units, not headers.  So I fail
>> to see why it is so important not to import the standard symbols.

The problem is that the name of C size_t under C++ compilation is no longer
that, but std::size_t. Then one can via a C-compatibility header get a
"using std::size_t", which defines an additional name "::size_t", that is,
i effect a "size_t".

So merely wanted the C++ compilation to not add any extra, non-standard
(compatibility) names.

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.

The latter is probably suitable for C as well, but I have not followed C99.

  Hans Aberg