Re: Token types with constructor

[Hans Aberg]

At 09:55 +0200 2004/08/30, Martin Trautmann wrote:
>> This is an easy fix. But a problem is that you are using the C-stack, and
>> that does not invoke the C++ copy constructors when reallocating. So funny
>> things will probably start to happen then.
>>
>But if you name the generated parser file parser.cc and compile it with
>g++ it makes no problem for me.
>The C++ Compiler should support all C features in the rest of the parser
>as well.
>
>I attached my simple parser that uses my solution. And from time to time
>this parser compiled fine with the official bison versions. Of course
>this simple parser wouldn't really need that constructor stuff. But I
>have also a much more complex parser whose token defines pointers to all
>possible types in a union (to save memory) but access functions allow an
>access as easy as this would be with a struct.

The C parser may well compile under C++, but it will not invoke the C++
copy constructors when reallocating its parser stack, so your C++ code may
break then. If your YYSTYPE is POD, then you are safe though, because then
it will behave as under C.

So if you use:
  struct Token
  {
    std::string string;
    union{
      double scalar;
      bool boolean;
      Expression *exp;
    }u;
  };
and your parser stack reallocates, you may get funny strings or a memory
error (segmentation fault).

I use:
class semantic_type {
public:
  long number_;
  std::string text_;
  object object_;

  semantic_type() : number_(0) {}
};

#define YYSTYPE semantic_type

And here, the class object maintains a reference count to a polymorphic C++
class hierarchy. But then I use, for parser stack, a standard C++
sequential container. If you are going to use std::string in your type,
then you can just as well do this, too: There is no particular gain in
using an pointer xpe, as you do then, if you already have a non-POD data
type in your YYSTYPE.

  Hans Aberg