NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/mac/system/10214

Text File | 1992-07-21 | 3.6 KB | 72 lines

Newsgroups: comp.sys.mac.system
Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!sunb10.cs.uiuc.edu!sparc1.cs.uiuc.edu!pjl
From: [e-mail] (Paul Lucas)
Subject: Re: Windows NT (Not a flame.) and C++ comments
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: University of Illinois at Urbana-Champaign
References: <[e-mail]> <[e-mail]>
Distribution: usa
Date: Tue, 21 Jul 1992 23:44:17 GMT
Lines: 59

In <[e-mail]> [e-mail] (Brent) writes:

>[e-mail] (Maynard J. Handley) writes:
>| We hear about how great object-orientation is (and I
>|agree completely- I now shudder at the thought of coding in anything but
>|C++) but what does object-orientation for OS get you, that a decent C++ API
>|to a traditional OS does not?

>You are right, OOP is a good thing, but its features certainly can't be
>used for everything.  I'd personally shudder at writing a UNIX C compiler
>in C++.  What would the objects be?  Would they be function definitions?
          ^^^^^^^^^^^^^^^^^^^^^^^^^

*****>    If you don't know, I'd respectfully suggest that you think some
    more about it and perhaps avail yourself of information about
    object-oriented design.

    Ignoring the language part of the compiler, even just doing the
    bookkeeping of symbol-table management is really slick if you
    have a nice SymbolTable class where the Symbol's are
    user-definable via inheritance.

>Could they feasibly be individual statements where compound statement objects
>would have other statement objects?  Yes, you could write it in C++ without
>using all the object stuff, but the basic compilation process is too
>algorithmically intensive to bother with objects.  The ++ overhead would
>slow down numerous method calls (the way C++ objects are implemented).

*****>    And wading through mongo switch() statements is so much faster?
    Member-function calls are _only_ slower when the virtual
    mechanism is used, but even then, it's only a couple of extra
    memory references.  The alternative is switch() statements.  If
    you change something, you have to go find all the places in
    every switch statement that require a change.  Can you say
    "bugs?"  The point is that even if virtual member functions are
    a tad slower (and it's not humanly-perceptablly slower), I think
    the benefit far outways the liability.

>The almost-classic example of an OOP application is the object
>drawing program.  This type of application lends itself greatly
>to OOP.  (A program like MacDraw).

>These above questions are exactly what I asked a fellow classmate in my
>compiler design class.  We had to write a Pascal compiler using whichever
>system we wanted.  I did it straightforwardly in C, and he talked about doing
>it in C++.  He didn't turn in a working project.  This has two interpretations:
>either the C++ realm was not fit for the project, or his programming skills
>weren't fit for the project.  I personally think it was a combination of
>the two; he had heard how great C++ is for everything and that he was trying
>to make it work, but couldn't get it going.  I think this is more the case
>because of what I know about him.  However, I'll never know for sure.

*****>    Well, I wrote a Pascal compiler in C++ and turned in the various
    phases early.  I'm writing yet another compiler for a language
    of my own in C++ and it makes life a lot easier.
--
    - Paul J. Lucas                University of Illinois
      AT&T Bell Laboratories        at Urbana-Champaign
      Naperville, IL            [e-mail]