Re: Bug in #include guards

[Alexander Belopolsky]

Akim Demaille writes:
<snip>
 >  After all, proper use of
 > Bison makes this feature absolutely useless.  That was done to please
 > users, not to solve an actual problem.
 > 


Here is an example of real-life use where this feature is essential:
We have a special purpose language which allows users to define new
operators by writing their own classes in C++.  In order to specify
precedence/associativity properties of their operators users have to
define a special static constant in their class to be equal to one of
the terminal symbols of the grammar (such as ADDITIVE, MULTIPLICATIVE,
UNARY, etc.).  These symbols are exported from the grammar file using
--defines mechanism.  It used to be necessary to guard bison-generated
headers separately in each of the user's header file and this feature
has greatly facilitated maintenance.

Getting back to the argument on the proper guard macros, I feel that
your objections are purely aesthetic.  At the same time the danger of
macro name collision is real particularly in large projects where
"proper use of bison" is difficult to control.

--
Alexander Belopolsky | Renaissance Technologies Corp.
600 Route 25A | East Setauket | NY 11733-1249
PH: 631-444-7125 | FAX: 631-444-7009