help-bison
[Top][All Lists]
Advanced

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

RE: enum instead of #define for tokens


From: Wayne Green
Subject: RE: enum instead of #define for tokens
Date: Tue, 2 Apr 2002 10:54:27 -0700

#define/enum  makes more sense to me over const, as storage management
and instruction times for compiled code may be the most optimal.
(Like the equivalent of a push-immediate instruction for parm passing)

Using an enum tickles the dragon of namespace issues. On the other
hand adding a enumerated type inside of a class definition makes
the most sense for C++. typedef enum ... is even better.

In all cases, files with definitions should have something like:

#ifndef __BISON_PREFIX_H__

#define ...

   or

typedef enum _bison_prefix_enum { ERROR = ...} PREFIX_TOKEN;

#endif

wrapping the code. Where PREFIX is the "name" of the grammar from
the bison command line switch.


if const is used,
#ifndef __BISON_PREFIX_H__
EXTERNDEF const short int ERROR = ...;
...
#endif

and user can supply -DEXTERNDEF=extern as needed. I like using short
int or long instead of plain int for porting reasons. Perl post
processors can remove text easier than figuing out where to add it!

Having a separate file for YYSTYPE or something like: 

#ifndef __BISON_YYSTYPE_PREFIX__
union...
#endif in the token's file makes sense.

Having Bison generate these things removes the edit step. Done
right, nobody knows the difference for simple cases.


The ifdef issues may come into play with C++.

I like the idea of a superclass being used for Bison C++ grammars,
where Bison generates:

class Prefix : virtual protected PrefixSuperClass
{...};

Where used writes PrefixSuperClass. In the PrefixSuperClass the
user hides instance specific temporaries, like the parse tree,
collection of intermediate classes (avoiding classes on Bison stack),
handles flags that something as been seen already, error reporting,
etc. Makes writing the rule bodies easy.

The #includes needed with C++ classes begs the #ifndef's as above.

I really think the %tokens, definitions and union statement should
come from the scanner package, as I like to use one scanner with
many grammars. The scanner does too many things with the union
statement to have the definitions originate anywhere else but
the scanner. We cannot do that yet -- How about coordinating with
the flex folks on this in very long run?

I'm sorry that I cannot spend more time of this but things are
pretty hectic here just now.


I really appreciate Akim asking for input like this.


I will post a C++ example soon.

--Wayne

Wayne Green         InfoSavvy, LLC
address@hidden 







reply via email to

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