Re: C Compiler in C++

On 13 May 2002 01:09:33 -0400, Lex Spoon <lex@cc.gatech.edu> wrote:
>journeyman@compilerguru.com (journeyman) writes:
[snip]
>> encapsulation) for each tree walking pass. Either way, it can get
>> pretty ugly quickly if you're not careful.
>
>Isn't this the situation whenever you use inheritance? Is it more
>often the case with parse tree nodes, that you want to know their
>specific subclass?


I don't know about more often. It would really depend on the problem
domain. I found working on a particular OO design that it cropped up
with undesirable frequency. In hindsight, there are a number of
things I should have done differently or would do differently next
time, but the biggest problems with that project boil down to
unrealistic expectations.


One major issue that affected the project was the dynamic tension
between getting something out sooner or spending more time to get
it right. I've never heard of anything like that ever happening in
the software industry. :-)


I've worked on several research and production compilers. They all
used a more classical structured approach. While they weren't
necessarily elegant, they were roll-up-your-sleeves-get-your-hands-dirty
maintainable.


I can't really say the OO-design I co-wrote would eventually have had
that property, but it's a lot easier to design it in up front than to
try to retrofit it. Ultimately, the project was killed just as things
were starting to gel for reasons that had little to do with the
technical merits of the project. And I've never heard of anything
like that ever happening in the software industry either. :-)




>The party line in OO design is that whenever you need to know the
>precise class, you should instead send a message to the object and let
>the object do something appropriate. Because different classes will
>respond with different methods, the message lookup itself will do the
>check for you. In the extreme, if you want to "frob" every if
>statement, you can even make a message like frobIfYouAreAnIf() and
>send it to the object; in the base class it does nothing, but in PTNIf
>it does "this.frob()".


Sure. But you have to put a {frob}IfYouAre{Interesting}() into the
base class for multiple values of {frob} and {Interesting} and the
base class winds up with a lot of information about the derived
classes. It tends to balloon.


When you do your tree walkers, there's no single place to look at
to debug it. You wind up making changes to multiple source files,
or making very large source files, or distributing your class
implementation across source files, or...


You also wind up having functions where you have a base pointer and
you know it must be an instance of a derived class. You put a stub
into the base class that calls a run-time error, and you have just
replaced compile-time type-checking with home-grown run-time typing.
Even if you stick with an OO design, are static-typed language like
Java & C++ the best OO languages for the job?


I'm not saying it can't be done. Just that that you want to be
careful doing it. IMO, it's exceedingly difficult to get the
design right on the first shot, and you have to be prepared to
refactor the program.


Morris

Return to the comp.compilers page.
Search the comp.compilers archives again.