|Type-checking in bison, C++ firstname.lastname@example.org (Tim Converse) (1998-06-11)|
|Re: Type-checking in bison, C++ email@example.com (1998-06-18)|
|Re: Type-checking in bison, C++ firstname.lastname@example.org (1998-06-18)|
|From:||email@example.com (Michael S. Zraly)|
|Date:||18 Jun 1998 11:04:18 -0400|
|Organization:||The World Public Access UNIX, Brookline, MA|
|Keywords:||yacc, C++, types, comment|
Tim Converse <firstname.lastname@example.org> wrote:
>I'm new to flex and bison, and am using them to generate code that will
>be compiled as C++. The forms I will be parsing correspond to instances
>of a complex C++ class, and the ideal thing for me would be to use all
>the bison machinery to build up a parse tree where some of the
>non-terminals correspond to constructed data members of the class.
>However, I doubt that a simple %union declaration,
>with some of the alternative types being my C++ classes,
>will let me compose classes using the bison type machinery.
Yes, there are problems with %union and C++:
C++ doesn't allow unions to have members that are classes with
constructors. No doubt this is at least partially because there is no
way to guarantee proper construction and destruction of the members
during assignment without introducing a fair amount of overhead to the
whole union concept.
Of course you could hack the bison output (perhaps by using a different
skeleton file, or through the preprocessor) to use a struct instead of
a union. There are two problems with this approach, though neither is
at all fatal:
1. You now have extra memory overhead for the semantic stack. Maybe
this is OK, maybe not.
2. You can still leak memory during error recovery, when bison pops
states from the semantic stack.
You can handle #2 with a weak form of garbage collection as follows:
1. Replace pointers with handle classes that overload the assignment
operator that deletes its pointer before overwriting it only if
the resource the old pointer referenced is not in use.
2. When you determine in a production you need to keep the resource,
mark it as in use.
3. When parsing is complete, sweep the semantic stack and free any
resource not marked as in use.
This has gone a bit outside the realm of comp.compilers, and I need to
get back to work, so I'll shut up. But that's one approach you can try.
E-mail me if you want to discuss this further.
[Compile time storage management is an entirely legitimate topic for
comp.compilers, particularly considering how painful it is with yacc and
its relatives. -John]
Return to the
Search the comp.compilers archives again.