Re: C Compiler in C++ (journeyman)
17 May 2002 00:23:43 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: C Compiler in C++ (2002-05-12)
Re: C Compiler in C++ (2002-05-12)
Re: C Compiler in C++ (Rodney M. Bates) (2002-05-13)
Re: C Compiler in C++ (Lex Spoon) (2002-05-13)
Re: C Compiler in C++ (2002-05-17)
Re: C Compiler in C++ (2002-05-17)
Re: C Compiler in C++ (2002-05-17)
Re: C Compiler in C++ (2002-05-17)
Re: C Compiler in C++ (Joachim Durchholz) (2002-05-23)
Re: C Compiler in C++ (Lars Duening) (2002-06-07)
| List of all articles for this month |

From: (journeyman)
Newsgroups: comp.compilers
Date: 17 May 2002 00:23:43 -0400
Organization: Giganews.Com - Premium News Outsourcing
References: 02-05-039 02-05-055 02-05-073
Keywords: C, OOP
Posted-Date: 17 May 2002 00:23:43 EDT

On 13 May 2002 01:09:33 -0400, Lex Spoon <> wrote:
> (journeyman) writes:
>> 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

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.


Post a followup to this message

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