[Top][All Lists]

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

Re: yet another C++ implementation bug to work around in Bison

From: Hans Aberg
Subject: Re: yet another C++ implementation bug to work around in Bison
Date: Mon, 6 Feb 2006 13:55:03 +0100

On 6 Feb 2006, at 09:01, Paul Eggert wrote:

I do not see why std::map would be needed as a part of the generated
Bison parser, i.e., if the user code does not include it.

It is not needed.  The map stuff is used only by the user-code example
in the Bison manual, which is tested by compiling it.  Please see the
Bison source code for details.

So, if not, the installation of Bison need not check it, but only as
a part of a "make check".

That would make sense, yes, but it will require that someone (not me!)
actually implement such a change, and not just talk about it.

I just pointed it, in case somebody would be interested. :-) I guess the GNU philosophy that anything beyond GCC is extra. :-)

It is also strange if a C++ compiler, at
this late date, cannot handle std::map properly.

I don't find it strange at all, and I'm not a bit surprised by it.

I guess I do not know the world of contemporary C++ compilers that well. The problem was said (in the links you provided) depending on that operator++() was applied to std::map iterators, and the C++ standard from 1998 says that these iterators are bidirectional, and such iterators should admit this operator. So it has been some seven years plus time to fix the compiler.

  Hans Aberg

reply via email to

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