C++, %glr-parser and non-POD semantic values

[Frans Englich]

Hello,

I'm switching a parser to be GLR in order to simplify the lexer. It's all in 
C++, the parser & tokenizer must be exceptions safe(hence, Bison destructors 
cannot be used to free values, as far as I know), and it must be reentrant.

My current parser does not use the C++ skeleton despite being compiled as C++ 
code, which from my understanding is bad practice(correct?). My semantic 
value is a class with non-POD members; I don't use %union. This functions 
just fine but is something I again suspect is considered bad practice(because 
its ctor and dtor are not invoked?). Nevertheless, it is amazing it works, 
but maybe it explains the leaks valgrind tells me exists in the parser..

Is using a non-POD type as semantic value supported? I have a vague memory of 
Hans discussing this.

When I simply added the %glr-parser directive, I ran into problems. Notably, 
this code was generated:

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;
};

which naturally gave compiler warnings like "member 
‘yyGLRState::<MyNonPOD>::yysval’ with constructor not allowed in union" since 
YYSTYPE is not a POD. However, do note that the parser worked with the LR 
parser.

What direction do you recommend me to take?

I like the C skeleton because it's simple and it doesn't have dependencies on 
the STL, which is a no go for me, unfortunately. So, I simply need a 
parser(GLR, or non GLR, if necessary) that can have non-POD semantic values, 
in a safe manner.


Cheers,

                Frans