bison-patches
[Top][All Lists]
Advanced

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

Re: %union foo bar baz and others { ... }


From: Akim Demaille
Subject: Re: %union foo bar baz and others { ... }
Date: Tue, 21 Jan 2003 13:58:23 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)

| Akim Demaille <address@hidden> writes:
| > Hm, I thought I had already made clear that C++ wants the tag and the
| > type to be equal.
| 
| Sorry, what does that mean?  (I don't know C++ well enough.)

Forget it.  While looking for documentation on the web and in the
standards, I found nothing.  G++ happily accepts the code I expected
it to reject, so you can forget all these comments.  I still don't
know about ObjC or ObjC++.

| By default, Bison 1.875 uses the following pattern:
| 
|   typedef union YYSTYPE { ... } YYSTYPE;
| 
| This declares YYSTYPE twice, once as a union tag and once as a
| typedef, but in C these are distinct namespaces so it's OK.  Is this
| also valid C++, or is it invalid because it attempts to declare
| YYSTYPE twice in the same namespace?  

It's valid.  tags and typedefs are in the same name space, so in C++,
typing

typedef union YYSTYPE { ... } YYSTYPE;

is strictly equivalent to

union YYSTYPE { ... };


| This pattern is new to Bison 1.875.

I'm fine with this, it remains good C++.  What I'm fighting against is
the possibility to have actual content between %union and {.


| The change to `typedef ... YYSTYPE' was for POSIX conformance.  The
| change to `union YYSTYPE' was my own idea, because I thought it would
| help pacify users that wanted a union tag for some reason, and my
| vague understanding from David Durham's "quick Bison Q" emails is that
| C++ users sometimes fall into this camp because they want the union to
| be a friend of a C++ class.

This is a good thing, definitely.

But there is some miscommunication here: I am struggling against
anything between %union and {, I am *not* referring to what Bison puts
between union and {.  I ask for the removal of the code that adds this
feature.




reply via email to

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