help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Fwd: question about error handling]


From: Hans Aberg
Subject: RE: [Fwd: question about error handling]
Date: Wed, 13 Jun 2001 13:19:11 +0200

At 15:02 -0500 2001/06/12, Dave Dutcher wrote:
>Aren't there times when you need to use a union?  I know when all the tokens
>in the file I am parsing are strings, I define YYSTYPE to be std::string or
>something, and that makes handling strings real easy and there are no memory
>leak problems.  Sometimes though I have a grammer that has multiple types,
>like perhaps a '+' operator that can work on numbers and strings.  Then I
>thought I had to use a union?  In your method, do you have a way that a rule
>could work on different types and not use a union?

I think that if you use std::string in your YYSTYPE and want to extend that
with another type, you can't use the Bison %union feature, because the
parser implements it as a C/C++ union type, and that type does not admit
types with user-defined con-/de-structors.

Therefore, the first step, if one still wants to keep the std::string type,
is to define something like:
  class parser_type {
  public:
    std::string text;
    long number;
    parser_type() : number(0) { }
  };

  #define YYSTYPE parser_type

The drawback is that all default constructors, like std::string() will be
called, and one uses up more memory, as "text" and "number" are always
present in the data type.

So the next step is to build that polymorphic type "object". But as for a
start one could make use of a hybrid:
  class parser_type {
  public:
    std::string text;
    long number;
    object data_;
    parser_type() : number(0) { }
  };

The drawback is that one misses Bison's static type checking present when
using the %union option, so one has to be more careful when entering the
action rules so as to not make mistakes. Also, for light-weight types,
unions are not only more memory efficient, but also considerably more time
efficient, as one then avoid dynamic allocation.

But that is all, I think.

  Hans Aberg
                  * Email: Hans Aberg <mailto:address@hidden>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>





reply via email to

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