From: Bob Hathaway <objsys@netcom.com>
Subject: Re: C++ binding vs. Obj-C binding
Date: Sun, 12 Apr 92 22:51:50 GMT
Organization: Object Systems
Keywords: C++, Obj-C, OOP

In article <1992Apr9.230243.8837@pencom.com> sam@pencom.com writes:
>In his posting, Eric Smith askes about a previous posting concerning C++ and X  
>windows:
>
>>In article <1992Apr8.060832.9260@sfc.sony.com> berger@sfc.sony.com (Bob  
>>Berger) writes:
>>>The dynamic-binding of the Objective C extensions to the NeXTstep C++
>>>compiler seem to be a key to allowing for the easy sharing, reuse and
>>>incremental development process. The fact that the NeXTstep compiler
>>>(and gcc-2.x) allows for the mixing of Objective C and C++ (and of
>>>course C) in one program now allows the PROGRAMMER (as opposed to the
>>>language designer!) to choose the level of binding (static or dynamic)
>>>as appropriate for the application.
>>
>>What do you mean?  C++ has always had dynamic binding.  It's the single
>>most important feature of the language.
>
>
>I think what he is alluding to is that the dynamic binding in C++ is somewhat  
>limited.  For example, in C++, you can't dynamically load a class into the  
>class hierarchy at runtime, which is how IB loads in new interface objects.

Thats an extreme example.  C++ (as a paragon of statically-typed OO
languages) can't create and send messages at run-time and all polymorphism
must take place with overridden virtual functions, so bases must have
virtual declarations for all common member functions of all derived
classes.  This is clearly an efficiency trick, but a good one *when* such
a derived-base binding isn't considered a problem.  Obviously dynamically
loaded objects couldn't be accessed without dynamic typing (without IMHO
gross processes), even by definition.

>
>In C++ you can't do that without screwing with the v-tables -- this is not  
>recommended, even though it is described in the book "Advanced C++".
>
>These differences are all related to the fact that C++ tries to do most of it's  
>binding at compile time, whereas Obj-C does almost everything at runtime.  It  
>would be very easy to get into a very long discussion of the merits of both  
>approaches, but I'll just say that the C++ method is more aimed at giving you  
>execution speed and somewhat less flexability, whereas the Obj-C method is  
>aimed at more flexibility and somewhat lower execution speed.

Good analysis.  I'd just like to point out that there is a middle ground,
where all the static typing of C++ (including virtuals) is available
and where dynamic typing is available if necessary, but without any real
cost to the static facilities.  I believe this is the right way to go,
supporting the best of both instead of forcing users to choose between
fast enough vs. powerful enough, which is a choice I've never considered
acceptable.  *PLUG*  I've designed and am now implementing such a scheme
(now implemented in a superset of C++, it also supports the dynamic classes
mentioned above plus much more) and hope it will be out by next year.  I
call it "Direct Compilation". *END PLUG*

bob
objsys@netcom.com

P.S.  Some might call Direct Compilation a kind of dynamic compilation.