Re: bison'd files don't compile under Microsoft VC++

[Hans Aberg]

At 12:31 +0100 2002/02/14, Akim Demaille wrote:
>Hans> On the one hand, the dynamic stack that Akim wrote for use with
>Hans> C cannot be used with C++ types that have non-trivial
>Hans> constructors. But on the other hand, some people may want it.
>
>I wrote nothing like this, and people should understand that C++ is
>not C.
...
At 12:35 +0100 2002/02/14, Akim Demaille wrote:
>>> I am curious as to why you "don't want to walk that tracks"...
>
>Hans> Which I figure is one reason that Akim, and for that matter
>Hans> no-one else wants to spend too much effort on a compile C as C++
>Hans> parser.
>
>No, no and no.  The fact is that that guy, so-called Akim, works on
>Autoconf, just as Paul does.  And we do have a fair bit of knowledge
>on how portability can be reached.  That way (#ifdef MY_SYSTEM), is
>not the right one.  We've been too greedy, willing the best for both
>worlds (C and C++).
>
>It doesn't work.
>
>So we keep targeting at C, and people who want to do C++ will know
>what they have to do.  We thought we could prepare the work for them.
>That's wrong, we cannot.  It is intrinsically wrong to try to do nice
>C++ with namespace and so forth, while on the other hand producing a
>function, not an object.

I am not sure I can parse these statements:

On the one hand there is the historical question who wrote the Bison parser
C dynamic stack; I thought it was Akim, but he says it was not.

The other fact is that it will not work with C++ classes that have
non-trivial constructors, which I at least knew all along (as soon Paul
Eggert pointed it out to me). It is sort of obvious that it not worth
upgrading the current bison.simple for that, but better to write a new one
for genuine C++ (as I did for myself).

The C++ namespace issue is orthogonal to that:

At 12:29 +0100 2002/02/14, Akim Demaille wrote:
>| Here is a proposed patch to implement this; basically, it reverts the
>| C++ stuff to the situation as of 2001-12-12, except that it removes an
>| inconsistency with YYPARSE_PARAM_ARG and YYPARSE_PARAM_DECL (C++
>| should be treated the same as __STDC__ there, just as it is
>| elsewhere).
>
>That's very much what I wanted.  Thanks Paul!  (just, don't forget
>NEWS, something like `failed experiment').

There is no problem having that feature unless one gets confused with C++
namespaces or erroneously believes that one can get genuine C++ support
that way.

So the failure does not have anything to do with the code as such, because
it could be easily made working, but probably rather a conflict in the
minds of those developing the code.


The thing is though that I can find no reason one should make use of the
compile C as C++ feature once one gets genuine C++ support. (Or does
anybody out there know of such a reason?) And if you feel sure you can have
the genuine C++ support in less than two months, there is no point at this
time continuing developing the compile C as C++ feature.

I felt myself it was too complicated developing a combined C and genuine
C++ file. So I think that once your the genuine C++ file has arrived, all
C++ support in the current bison.simple should be stripped out.

The next problem I arrived at, and which I think you are yet to discover,
is that although the C and C++ skeleton files will be different, one wants
their performance to be identical. This will be even more complicated with
multi-language and multi-algorithm support.

So therefore I was led to the idea of a common original skeleton language
that can be specialized to the various languages. -- Of course, you need
not consider this at this point in time, but when you have developed this
stuff for some time, it would be interesting to see how you eventually cope
with the problem. :-)

  Hans Aberg