[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.

reply via email to

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