Re: Making yyGLRStackItem know its type

[Akim Demaille]

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.