From: comeau@csanta.attmail.com (Greg Comeau)
Subject: Re:  Obj-C vs. C++
Originator: comeau@well.sf.ca.us
Reply-To: comeau@csanta.attmail.com (Greg Comeau)
Organization: Comeau Computing
Date: Tue, 13 Oct 1992 11:46:30 GMT

In article <1992Sep28.175032.26533@oracle.us.oracle.com> dnavas@oracle.uucp (David Navas) writes:
>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.  :)

I've gone through the love/hate of type-checking or not.
For real stuff I prefer it.  For other stuff I may not.
The solution domain is big enough that *both* accomodate it, for
this I am clear.

>>  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 don't understand this as the O- part of O-C does NOT have a similar syntax
with C, whereas C++ does.  Have you even seen O-C code?

Recent O-C do have a better integration than earlier ones, but even still with
O-C we are talking about two different languages threaded within each other.

>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....

O-C's have the option to allow you the type checking if you choose
and for the call the be more effeciently handled as well.

>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.

All methods in C++ and not bound at compile-time.  I don't understand how
you can possibly claim that C++ does not support polymorphism when you
don't know the details of some of its capabilities.

>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 :) :).

You ask Taligent.  C++ is a part of what they are doing.  Ditto goes for
the parent companies (Apple, IBM, HP).  What's your point?

Your comment above is bringing in issues of implementation, which although
important is some cases, the deal is that you are not rather'ing it to
programmer functionality in the language.  That there are different
implementation details does not in itself discard OO'ness.  That's like
saying O-C isn't OO either because it can be compiled to object code
(just like C++) at some point in the game.  And?

>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.

I don't understand why.   Also, to be fair, why not bring up the issues where
the O-C scheme is bad?

>>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.

It is indeed competing design goals, but *that* doesn't result in 'depends'.
An O-C app will typically get hit up with some performance considerations.
Period.  And again: the implementation details of the code generated does not
in itself discard the OOL'ness of a language.

>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"....

Would?  More like could.  Of course with C++'s type checking, a virtual
function call is on average no more of a penalty than the C switch and on
some machine can actually be faster.  With the dispatch table, you run certain
risks even with caches.

Why do you think O-C now also has C++ style method invocation capability
in part?

>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...)

I've seen such figures but they escape me at the moment.  I do know that
it is at least a factor of 2 though in the most optimal case.

>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.

Each language gives you the ability to do all kinds of neat things.

>Different design goals, different tools, different tradeoffs.

Always!

- Greg
-- 
         Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418
                   Producers of Comeau C++ 3.0 With Templates
          Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421
	    Voice:718-945-0009 / Fax:718-441-2310 / Prodigy: tshp50a
Xref: sparky comp.sys.amiga.programmer:14341 comp.sys.amiga.hardware:16888