From: jazz@netcom.com (David C. Navas)
Subject: Re:  Obj-C vs. C++
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Wed, 14 Oct 1992 00:35:13 GMT

[I'd prefer this to be followed up in email....]

In article <Bw261I.Drw@well.sf.ca.us> comeau@csanta.attmail.com (Greg Comeau) writes:
>I've gone through the love/hate of type-checking or not.
>For real stuff I prefer it.  For other stuff I may not.

What is "other" than "real"?  ;)

>The solution domain is big enough that *both* accomodate it, for
>this I am clear.

Yes, I agree with this.

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

Sigh, yes, I have the source to an Objective-C compiler someplace on my
harddrive.  Well, parts of one anyway.  And I have some source and compiled
code which tests a friend's implementation of Objective-C wrt its method
lookups.  They were too slow to believe, so I'm still waiting for some
better numbers to show up.

I guess my basic claim is that, while it's possible to do STRUCTURE sorts
of macros in assembler, it's not exactly natural, and while it's possible
to do ->() sorts of methods in C[++], it's also not exactly natural.
-FOR ME-

Now, I've used assemblers that support structures more directly -- the
question I ask is "is this still assembler" or is this "A C-wannabe
assembler".  For me it's still assembler.  Which is why I say that Obj-C
has a "similar" syntax with C (ie: it's still C in my book) even though
it's more like a Smalltalk-wannabe C.

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

Yes.  It seems more natural for me to express OO like Smalltalk.  This is a
personal taste issue, though, so no one should get steamed up because there
happens to be disagreements....

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

I have heard that O-C's have static-bound options -- is this what you are
referring to?

>>At the same time, I don't understand how you can possibly claim that an
>>[OO] 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're right, not all methods in C++ are.
They are by default, though.

The exact semantics of the argument we are having is being thrashed over in
comp.object, as you probably know.

>you can possibly claim that C++ does not support polymorphism when you
>don't know the details of some of its capabilities.

I never claimed that C++ did not support polymorphism.
I may have implied it, and I apologize for that.  Sometimes when I edit my
text down I get a bad overlap....

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

Yes, and that is a rumour I got wrong.  Taligent has -NOT- dropped C++.  It
is Apple that has a new OO language, and not Taligent.  My apologies for
passing along an incorrect rumour.

BTW, I went to a Taligent talk this past week, and while Taligent is still
using C++, there was a definite love-hate relationship evident in the speaker
:).  The audience, on the other hand, had a hate-hate relationship with C++,
so there was significantly more grumbling from the audience than from the
speaker.  I did not leave with the impression that the speaker had
couched his words just to appeal to the audience, though.

My point, I guess, is that Stefan is right insofar as Obj-C seems to fit in
better with BOOPSI than C++.  On the other hand, my partner in programming
uses C++ all the time to build BOOPSI stuff.  IE:  "it seems to me" that this
is so, but it doesn't make ANY language non-useful just because I said so....

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

I did bring up the speed issue, no?  As you've asked, the Obj-C implementation
I have here gets a dismal 6.6k methods/second.  Although I don't have a C++
compiler handy, certainly static-b methods are going to be equivalent to their
function counterparts, which run more like 250k/sec (or something like that).

The difference is significant.  On the otherhand, my methods under SHADOW,
which are arguably accomplishing more than their objective-C counterparts,
are much faster than this Obj-C, so I'm waiting for real figures....

>>Depends.  Again, remember that there are competing design goals.  C++ produces
>>code that is -essentially- not object-oriented, but it is created in an
>>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'.

"Depends" was in reference to a "wild" claim of "performance sucking".
I would definitely say that Objective-C has a higher overhead, but whether
that overhead is significant depends on what the method ends up doing.

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

The first I agree with, the second one is still out in the jury box as far as
I'm concerned.

>>centralized method dispatcher would win, considering things like "caches"....

>Would?  More like could.

Oh jeesh, okay "could".

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

Sorry, seems to me, though, that a dispatch table -can- run worst case as
fast as a switch.  C switch tables are often implemented with jump tables....
Perhaps I have the wrong meaning for "dispatch table"?

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

Because it is better to have both possibilities rather than only one.
I thought that that was a given in this discussion.

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

A factor of 2 for what?

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

Yes.  Pick the one that is most appropriate to the job.

-- 
David Navas                                   	jazz@netcom.com
Co-author of: Web Data Acq. and Anal.		dnavas@oracle.com
Upcoming products: Shadow V, Jazzbench 2.0.