Re: Using "%define location_type" c++ skeleton should exclude default location

[Akim Demaille]

Le 23 mars 2010 à 09:14, Chris Morley a écrit :

> Hi All,

Hi!

> I use Bison to generate a C++ parser using the lalr1 skeleton. I also use a 
> custom location class.
> 
> I just upgraded a project from using v2.3.1 to v2.4.2 and as I am on Windows 
> <windows.h> defines a max macro which breaks std::max now used in the 2.4.2 
> location.hh.

That's really a pain.  I guess you know NOMINMAX?  I use this.

/* We don't want the min and max macros that conflict with std::min
 * and std::max.  We might need some magic to bind _cpp_min and
 * _cpp_max to min and max eventually.  See
 * <http://raduking.homeip.net/raduking/forumwin/index.php?showtopic=270>.
 *
 * This must be done conditionnaly because MinGW already defines NOMINMAX in
 * some headers.  */
#  ifndef NOMINMAX
#   define NOMINMAX 1
#  endif


> In itself not much of a problem but it made me realise that the default 
> "location.hh" & forward decls of class location & position are included in 
> the src.hpp regardless of a manual "%define location_type" in the yy file. 
> IMO these should really be omitted if a custom location class is in use...

Wow.  I had completely forgotten about %define location_type.  Indeed, it's 
nice to be able to use a custom implementation.  But location_type is not 
documented :(  Well, actually, it is, but for the Java parsers, not for the C++ 
parsers (nor for the C parser actually).

It would also be useful to be able to use Bison location/position, but from 
some other parser.  A friend of mine has something like 5 or 6 Bison parsers in 
a single program, and that many location.hh, position.hh, not to mention 
stack.hh (whose existence I dearly regret).

I have started working on this in 2.5 and 2.6 branches.

> I never used m4 before but modified the lalr1.cc in v2.4.2 as follows to 
> achieve this. It is not pretty as I couldn't determine how to tell if the 
> user has defined "location_type" rather than the default - thus is a 
> dependency between this lalr1.cc & the c++.m4

It's a nice start.  But 2.4.* is really only on maintenance now.  Many things 
are ready for 2.5, and 2.6 has already started.


I have installed a first batch of changes in 2.5 and 2.6 to this end.  I think 
I failed to keep you in CC, please have a look at the archive (it should appear 
in http://lists.gnu.org/archive/html/bison-patches/2010-04/threads.html I 
guess).

Cheers!