Re: Type-checking in bison, C++

Tim Converse <converse@cs.uchicago.edu> 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.


--
Mike Zraly
mzraly@world.std.com
[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 comp.compilers page.
Search the comp.compilers archives again.