[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 13:37:19 +0100

On 14 Feb 2006, at 08:02, Paul Eggert wrote:

when people compile your C-parser using a C++ compiler, they are
not compiling C-code actually,

If they are not compiling C source code, then it's up to them to get
things to work.  yacc.c is designed for C source code.

You are already writing C++ code by restricting to the common C/C++ language subset (and using __cplusplus), apparently not giving thought to that this is actually C++ code -- but Akim has to check that this is legal C++ code. This is what he was saying: he checks that the code you write is also legal C++ code. Thus, users are not on their own, because Akim gives them support.

It does not
work well with C++ source code, and we shouldn't recommend it for

Because of those problems, I just tacitly assumed that the C compile as C++ feature had been retired. But Akim says he does support its presence.

Thus, I would not mind this feature would become retired completely, in favor of a genuine C++ skeleton only. This would be the right development move, but I cannot assess the legacy issue. In such a case, the C parser would have get added:

#ifdef __cplusplus
#error "Bison C-parser does not support compile by a C++ compiler."

Then you can use C-language constructs whatever.

but a C-like language subset of C++
that can be linked to proper C-code at need.

If the user wants to use different C compilers for different parts of
the application, it's up to them to get things to work.  This is true
for random combinations of C compilers; it's also true for C++
compilers masquerading as C compilers (which are just special cases of
C compilers).  We shouldn't need to document all the issues here.
They are generic issues, and are not specific to Bison.  Anybody who
wants to mix C compilers should know what they're doing anyway; it's
not the Bison documentation's job to educate them.

Right, I just wanted to explain the difference between the C code compiled using a C compiler and a C++ compiler. The C++ standard requires that one should be able to link to a C compiler, but it is up to the compiler manufacturer to make sure such a C compiler exists.

It is only a Bison issue in the part that it is possible to write a C- parser skeleton which does not compile at all under C++, but which still is usable to C++ users, as they still can link to it.

I don't sense that we are making much progress here.  It would help if
you would propose specific patches, in "diff -u" format.

I'll think about it.

Otherwise I
fear that we are just going around in circles.

You and Akim need to figure out what you want with the compile C as C+ + option that now exists.
- Should it exist unaltered in its current form?
- Should be phased out completely in future Bison versions, in favor of a C++ skeleton? - If it is retained, is it necessary, as now is possible, to be able to use C++ non-POD types, even though it results in a strange semantics (destructors not invoked immediately as expected)? If it is retained, and only POD types are needed (and required when using % union), then one can just as well use the dynamic C-parser already in place.

  Hans Aberg

reply via email to

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