[Top][All Lists]

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

Re: too many warnings from Bison CVS for Pike

From: Hans Aberg
Subject: Re: too many warnings from Bison CVS for Pike
Date: Tue, 14 Feb 2006 06:37:09 +0100

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;

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

reply via email to

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