help-bison
[Top][All Lists]
Advanced

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

Re: Using Standard C++ library with Bison .y files (or defining tokens w


From: Akim Demaille
Subject: Re: Using Standard C++ library with Bison .y files (or defining tokens with #define)...
Date: 02 Apr 2002 16:41:20 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)

>>>>> "Michael" == Michael Suodenjoki <address@hidden> writes:

Michael> Hi, I'm one of those C++ developers that's trying to use
Michael> Bison to integrate a parser into a C++ project. I'm using MS
Michael> Visual C++ 7.0 with the Dinkum Standard C++ Library 3.10.

Michael> I've found that the way Bison is defining its token's using
Michael> #defines is not clever - it may interfere with the use of
Michael> Standard C++ libraries (or other libraries for that matter).

Yes, it is a known problem.  This is to be addressed in the C++
parsers, but we still have not made up our minds on what to use.  We
should send an RFC about that.  Please, subscribe to help-bison if
you're willing to participate to C++ Bison/


Michael> As I can see it there are two solutions:

Michael> 1. Don't define token symbols that Standard C++ or any other
Michael> include file may use. This may be a huge amount, and it is
Michael> nearly impossible to know on beforehand. I know that the
Michael> normal convention is to use uppercase tokens like EQ, however
Michael> in principle these may be used elsewhere too.

Err, please note that you are free to use yourself better token
names.  Many people, for instance, have chosen to systematically
prepend t.  E.g., tIF, tELSE, tEQ.

Michael> 2. Change Bison so that it doesn't produces #defines but uses
Michael> constants, e.g. like "const int eq = 257;"

I like this, and I think this is what we are going to do.  See the
RFC.  Enums are attractive, but because of some limitations of C++
that I don't understand, you cannot import enums from a class without
importing the whole class.  Yet you do want to be able to use `using',
to avoid the painful yy::Parser::eq, yy::Parser::neq, etc. in the
scanner.

Michael> I like of course solution 2 best because it is the most clean
Michael> one - at least when dealing with C++ in which case #defines
Michael> should generally be avoided - see e.g. the very first item on
Michael> pp.13 in Scott Meyers book "Effective C++, Second Edition".

This is true for C too, anyway :)

Michael> Optionally or for the sake of backward compatibility Bison
Michael> could be extended with an extra option that tells it to use
Michael> constants in stead of defines.

Options are entropy.



reply via email to

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