[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making yyGLRStackItem know its type
From: |
Akim Demaille |
Subject: |
Re: Making yyGLRStackItem know its type |
Date: |
Fri, 11 Nov 2005 10:06:19 +0100 |
Le 10 nov. 05 à 22:41, Paul Eggert a écrit :
Akim Demaille <address@hidden> writes:
with both cases starting by a Boolean was a bit troublesome. I do
understand that this allows shorter and simpler names, simple
assignments, but it is a bit unusual (to my eyes). Could it be also
to optimize in some way to size of the union?
In general, yes, because it removes the need for the C compiler to
align the first non-bool member to the strictest alignment of all the
later members. Hence the resulting union might be smaller.
I can understand the "might", but I was hoping for a more clear cut
answer :( The structures are
struct yyGLRState {
/** Type tag: always true. */
yybool yyisState;
/** Type tag for yysemantics. If true, yysval applies, otherwise
* yyfirstVal applies. */
yybool yyresolved;
/** Number of corresponding LALR(1) machine state. */
yyStateNum yylrState;
/** Preceding state in this stack */
yyGLRState* yypred;
/** Source position of the first token produced by my symbol */
size_t yyposn;
union {
/** First in a chain of alternative reductions producing the
* non-terminal corresponding to this state, threaded through
* yynext. */
yySemanticOption* yyfirstVal;
/** Semantic value for this state. */
YYSTYPE yysval;
} yysemantics;
/** Source location for this state. */
YYLTYPE yyloc;
};
struct yySemanticOption {
/** Type tag: always false. */
yybool yyisState;
/** Rule number for this reduction */
yyRuleNum yyrule;
/** The last RHS state in the list of states to be reduced. */
yyGLRState* yystate;
/** Next sibling in chain of options. To facilitate merging,
* options are chained in decreasing order by address. */
yySemanticOption* yynext;
};
It's common usage and it conforms to the C Standard. Also, if memory
serves (I'm not a C++ expert), C++ caters to this usage as well. If
it's merely a style issue, I'd leave things be.
C++ indeed, has no problem with this, that was not my point. C++ does
have problems with union containing objects (from classes with
contructors).
That's a problem for the location type here, and it's in the process of
trying to understand better what's going on with GLRStackItems that I
stumbled on this.
One final note: I find it particularly difficult to separate
both cases of GLRStackItems, so my guess is that the result
will significantly improve readability.