bug-bison
[Top][All Lists]
Advanced

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

Re: Bison & C++


From: Hans Aberg
Subject: Re: Bison & C++
Date: Sun, 16 Dec 2001 15:12:31 +0100

At 12:45 +0100 2001/12/16, Pascal Bart wrote:
>I want better compatibility for generated parser, but the most of C++ compiler
>don't like namespace,

This must have been a long time ago: The C++ standard appeared in 1998,
called ISO+IEC+14882-1998 at ansi.org.

Besides, GCC is said to be one of the most C++ standard conforming
compilers, so that should be the first objective of Bison, then.

And if you insist on using an outdated compiler, it is probably easy to
downgrade bison.simple for that purpose on just your platform.

I think though that it is wholly inadvisable to use an older C++ compiler,
in view of the strong developments that have been taken place the last
couple of years.

> I haven't a great experience with C++ portability, and I
>prefer leave Akim and Paul take decisions about that.

I guess they did: Paul Eggert volunteered to make the changes, and asked me
to check for bugs; so I fed that back.

Please be aware of that we are speaking about two types of C++ support: One
is enhancing the current bison.simple so that it better compiles under C++
(C compiled as C++), which is what we do now.

The other development, the future C++ paradigm generated parser would
probably sport an entirely new skeleton file.

I find the current C++ enhancements of bison.simple interesting, because it
gives some hints of what may and may not be done with the future C++
paradigm generated parser.

For example, it would be unwise to use malloc directly, but one should rely
on the std:: containers (perhaps on the std::stack adaptor). Some of the C
union's must be changed to struct's, in view that under C++, unions can not
contain types with non-trivial containers. The Bison %union option should
probably be augmented with a %polymorphic or %object option, implementing a
polymorphic object class instead, for use with types having non-trivial
constructors.

So those are some of the things I can see are suitable for the genuine, C++
paradigm support.

  Hans Aberg





reply via email to

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