Re: too many warnings from Bison CVS for Pike

[Hans Aberg]

On 14 Feb 2006, at 01:39, Paul Eggert wrote:

> > When compiled using a C++ compiler, that becomes C++ code,
>
> yacc.c contains C code.  That is true even when yacc.c is compiled
> using a C++ compiler.  Users who attempt to combine yacc.c with a
> C++-only feature, such as destructors, are on their own.  The only
> thing that I'd be willing to document is compiling C code.

I just try to indicate is how I think how the C++ compiler works,  
though I am not entirely sure: C++ has a language subset, which is  
equivalent to some subset of pre-C99. In addition, there is a  
language construct 'extern "C" ...' which admits one to link C++ code  
to code compiled using a properly with it synced C compiler.

So when you write your C-parser, if it should compile under C++, you  
need to use this common C/C++ language subset. Example of what will  
not work are the new C99 integral types that specify fixed binary  
sizes. But you likely do not need them. This is a problem with Flex,  
though, which I think uses them. A later revisios of C++ may include  
these new C99 integral types.

You probably do not need such C99 extensions, which is why it works.

> The problems that you describe, which are related to C++ destructors,
> should not be an issue here, because C++ destructors are not valid  
> in C.

So when people compile your C-parser using a C++ compiler, they are  
not compiling C-code actually, but a C-like language subset of C++  
that can be linked to proper C-code at need.

If one would want the C-parser to be proper C, and then linked to C++  
code, then it should just be compiled using a C compiler, and the  
header should generate an error if __cplusplus is defined. This  
excludes any C++ constructs, such as destructors. Then one should  
write another C++ header file with something like:

external "C" {

typedef union YYSTYPE {
  symbol *symbol;
  symbol_list *list;
  int integer;
  char *chars;
  assoc assoc;
  uniqstr uniqstr;
} YYSTYPE;

...
int yyparse (void *YYPARSE_PARAM);
...
}

When the C++ compiler sees this information, it can link its C++ code  
to these external C-compiled object files. In this setting, the  
parser cannot make use of any C++ code at all, so for example the  
semantic types cannot be a C++ type. When the C++ compiler sees the  
'external "C"' declaration above for this semantic type, it will be a  
POD. There is no semantic point in using the static array parser  
stack in this setting.

  Hans Aberg