Related articles |
---|
OOP Parse tree generation? nojeda@my-deja.com (Nicolas) (2000-03-11) |
Re: OOP Parse tree generation? qjackson@wave.home.com (Quinn Tyler Jackson) (2000-03-21) |
Re: OOP Parse tree generation? floris@vangog.net (Floris 'Tamama' van Gog) (2000-03-23) |
Re: OOP Parse tree generation? thp@roam-thp2.cs.ucr.edu (Tom Payne) (2000-03-23) |
Re: OOP Parse tree generation? lojedaortiz@interlink.com.ar (Nicolas Ojeda Bar) (2000-03-23) |
Re: OOP Parse tree generation? dara_gallagher@my-deja.com (2000-03-23) |
Re: OOP Parse tree generation? nelan@home.com (George Nelan) (2000-03-23) |
Re: OOP Parse tree generation? danwang+news@cs.princeton.edu (Daniel C. Wang) (2000-03-25) |
Re: OOP Parse tree generation? cfc@world.std.com (Chris F Clark) (2000-04-03) |
Re: OOP Parse tree generation? cfc@world.std.com (Chris F Clark) (2000-04-03) |
From: | "Nicolas Ojeda Bar" <lojedaortiz@interlink.com.ar> |
Newsgroups: | comp.compilers |
Date: | 23 Mar 2000 03:35:28 -0500 |
Organization: | Compilers Central |
Keywords: | parse, OOP |
Hi,
Like Quinn, I also end up with a base class with an union that carried
info for all the posibilities (ie: for stmt, while stmt, assignment
stmt, etc), but I added subclases for the commodity of having
constructors to fill in the proper union members, and destructors to
allocate the proper union members. This left me with a good - sized
base class, and lots (LOTS) of minimal classes with only constructors
and destructors, with represented each posibility of the union. This
of course does not avoid the class explosion.
After studying a while ctool, though, I am changing my design a bit:
the base class will NOT have a union, and instead each union member
will be contained in the subclass. This leaves exactly the same class
hierarchy, but more "balanced". I still get my constructor /
destructor advantage, but if I want to access to the particular data
of a particular subclass, I have to typecast.
Any comments ?
Regards,
Nicolas
--
On Sat, 11 Mar 2000 20:18:46 Quinn Tyler Jackson wrote:
>Another approach might be to reduce your class hierarchy to the major contenders, such
>that iteration would be reduced to one class, but the "while" and "for" information would
>be retained, so that the "iteration" class would be a union of "while/for", with some of
>the wasted overhead that unions carry with them. This is a compromise, but is at least
>not lossy. This is the final design model I used for LPM's clauses -- all of the numerous
>clause types are represented in a single union object CLpmClause. It's as ugly (and
>spatially inefficient) as sin -- but it kept the class explosion manageable, and kept the
>speed reasonable.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.