Newsgroups: comp.sys.amiga.programmer
From: dnavas@oracle.uucp (David Navas)
Subject: Obj-C vs. C++  [was Re: Comeau C++]
Organization: Oracle Corporation, Redwood Shores CA
Date: Mon, 28 Sep 1992 17:50:32 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <1713@lysator.liu.se> boberg@lysator.liu.se (Stefan Boberg) writes:
>comeau@csanta.attmail.com (Greg Comeau) writes:
>>In article <1683@lysator.liu.se> boberg@lysator.liu.se (Stefan Boberg) writes:
>>>  Why C++ anyway? It's such a pig, loaded with useless fluff. Why not

I wouldn't have gone quite that far :)  Not in csa.programmer anyway....
But then I once did have a rather nasty thing to say about type-checking
languages....  Ah, to be young again.  :)

>But seriously, C++ is certainly NOT more of a pig than OC or any of that.

Very true.  If by pig we mean something like "takes more memory to run" or
"runs slower".  C++ is static-bound, Obj-C is runtime-bound, which
should tell you something right there....

>  I guess I didn't put that very well. I didn't mean to present it as a
>fact. It's just an opinion of  mine (and it is shared by many, judging 
>from the EMail I've received), and I still think that Objective-C fits 
>better in the Amiga OS because the Intuition BOOPSI system uses a very 
>similar (Smalltalk-ish) message-passing approach (only more effective 

>  I didn't mean to sound harsh. As you say, C++ has its uses, although I
>still think that C++ has too many "neat features" to be elegant. Objective-C
>somehow seems "cleaner" to me. But as I said before, I don't really have
>any experience in OOP to talk about (I'm only 20 yet :-), I've just been
>playing around a bit with BOOPSI and when I looked at Objective-C the first
>thing that struck me was - "this would be perfect for BOOPSI programming!".

Well, after designing my own object-oriented-on-top-of-C thing, perhaps I
can offer a (few) thoughts that are a tad more defined.

C++, it seems to me, was designed to provide an object-oriented >interface<
to C, where Obj-C was designed as an object-oriented language with similar
syntax as C.

I'm not sure how stringent Obj-C type-checking is, but it's worth noting that
if your methods are bound at run-time, it'd be rather difficult to type-check
them at compile time....

At the same time, I don't understand how you can possibly claim that an
object-oriented language is polymorphic when methods are bound at compile-time.
In reality, the message's "name" [in SHADOW I call this a selector to avoid
confusion with Exec messages] is a combination of the method and the class of
the object.  The fact that this is how many C++ (pre)compilers implement
C++-in-C is probably not surprising....  At anyrate, it is no longer the
"message" (selector) that is "polymorphic" but, rather, the interface wrapper
around the "message", essentially, the "->method_name()" -- it is this
"method_name()" that is "polymorphic".  At anyrate, it seems like a bit of a
stretch to me.  To wrap this up with my first statement -- C++'s -interface-
is object-oriented, its underlying constructs are much less so, just ask
Taligent :) :).

This is a good thing if you're after speed, it is bad if what you're trying to
do is write system-software that offers subclassing of system classes to
provide user-definable behaviour on system-handled objects.

>than the string-passing that goes on in Objective-C, which to me seems 
>like a real performance killer).

Depends.  Again, remember that there are competing design goals.  C++ produces
code that is -essentially- not object-oriented, but it is created in an
environment that is  [God, I feel the flames already, why do I make such wild
generalizations?].  Obj-C provides code that -is- object-oriented.  [This
assumes you bought the leap from static/runtime bound to "true object-
orientedness" which is by no means certain!]
Objective-C is -already- a performance killer.  Remember, methods are bound
at run-time.  Even if you have an extraordinarily fast message lookup code
(like the NeXT does, btw), there is still more overhead.

BOOPSI, you recall, requires a method dispatcher for each class definition.
Function calls and switch statements cost quite a bit extra as well!  A
centralized method dispatcher would win, considering things like "caches"....

SHADOW uses strings for it's selectors as well.  SHADOW methods have -quite-
a bit more overhead than straight function calls (I'm still waiting
for someone to get back to me with Obj-C method overhead figures...).  However,
you get the ability to do all kinds of neat things -- runtime method patching,
methods run in separate processes or even separate process classes, automatic
process invocation upon method invocation, etc.  There is one single
dispatcher, although you can add your own dispatcher on a class-by-class
basis, if that's where you get off.

There are several things you can do to speedup method dispatching.  SHADOW
buffers its selector/method lookups, which eliminates BOTH the string
lookup and the class hierarchy searching.  Typical performance increase
is ~300% (with SHADOW).  Strings themselves reside in a 1024 entry hash
table with collisions held on a binary tree.  The selector can then be
looked up once, and the address can be used to find the correct method.
The centralized design, however, requires the use of semaphores -- Exec
semaphores are used, though something else might be more efficient in this
case.  If I remember correctly I get something like 20,000 ~24byte string
lookups per second on an 030.  Obviously, the biggest overhead here are the
semaphores.  I might consider Forbid()/Permit() at some time point in the
future....

The dispatcher itself sends out methods (the INVOKE_CALL kind, as opposed
to the interprocess INVOKE_SYNC/INVOKE_ASYNC kind) at the rate of ~43k/sec
when buffered, and ~15k/sec when not buffered.  This is opposed to ~230k/sec
for function calls.  Quite a difference, but then it's rather hard to patch
function calls, ain't it?  [Course, it's hard to patch library calls too,
not so with SHADOW methods....]  :)

All these figures are measured on a function that does essentially nothing.
It is obvious that you would not want to write a recursive raytracer in
SHADOW -- but an OS or some kind of program server might not be a bad idea.

Different design goals, different tools, different tradeoffs.

>(Just in case someone don't know it, BOOPSI means "Basic Object Oriented 
>Programming System for Intuition").

Thanks, already had to answer that a couple of times.... :)

David C. Navas						dnavas@oracle.com
Working for, but not speaking on behalf of, Oracle Corp.