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