Re: Making yyGLRStackItem know its type

[Paul Hilfinger]

> 
> Le 10 nov. 05 =E0 22:41, Paul Eggert a =E9crit :
> 
> > 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 :( 

Hmm.  On reflection, it appears that Paul E. is right.  Re-organizing
the types as Akim suggested does increase the size of a stack item
slightly (4 bytes or 10% on a typical 32-bit architecture).  This is
because the embedded union is 32-bit aligned, leaving 3 bytes of
padding after yyisState.  Come to think of it, I suspect this is why I
organized things this way in the first place.

Paul H.

> 
> 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 =20
> 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.=