Re: [Fwd: question about error handling]

[Hans Aberg]

At 10:52 -0500 2001/06/11, David Durham wrote:
>As far as cleaning up memory upon parse errors... Here's what I did..
>I'm using C++, but I'm sure something like this could be done with C if
>you try really really hard ;)
>
>Anyway, all my parse tree nodes are C++ classes and they are all derived
>from a base class.  This base class's constructor adds the this pointer
>to a static data-member list of parse tree node pointers.  And the
>virtual destructor of this base class removes itself from the list.
>Then if I have an error, then I just delete all the pointers in this
>list.

I am curious, if you use C++ , why do you have to do all that; are you
using the "%union" option?

I use definitions of the type:

  class parser_type {
    // Automatic data
  };

  #define YYSTYPE parser_type

It is not then possible to use the %union option if the automatic data
contains classes with user defined constructors ("non-POD's"), as Bison
uses a C/C++ union for that implementation, and only POD's are (currently)
allowed in such unions.

But if one does not like definitions like
  class parser_type {
    std::string name;
    float number;
  };
which duplicates data, and thus is memory inefficient, in addition to the
default constructors, then one can define a generic class
  class object;

  class object_root { ... };

  class object {
    object_root* data_;
  public:
    object(object_root* x = 0) : data_(x) { }
    ...
  };
with say a ref count in object_root in order to avoid unneeded copying.

Other data classes are derived from object_root:
  class A : public virtual object_root { ... };
The class object becomes a polymorphic data class for all available data.
And then one defines:
  class parser_type {
    object value_;
  };

The disadvantage is that one gets dynamic allocations, but not so much if a
ref count is used. And I cannot use the "%union" option. But on the other
hand, I do not have to worry about resource management.

I guess that this style is not for heavily optimized code. So the style to
choose depends on what application one has at hand, I figure.

  Hans Aberg