In this forum, Scott Ribe recently wrote "...but just as you can't
"rewrite Cocoa in C++" as we've seen demanded by people who don't
really understand Objective-C..."
I claim that a relatively dynamic language is necessary to effectively
use Cocoa. I also claim to have very deep and thorough understanding
of Objective-C and several variations of its run-time.
As with all Turing Complete languages, it is certainly possible to
create a message dispatching system similar to Objective-C's
objc_msgSend() using C++. In fact, objc_msgSend() and related
functions are C functions that compile without modification as C++.
Obviously, there is nothing that can be done in C++ that can't be done
in C. There is nothing that can be done in C++ that can't be done in
Objective-C. There is nothing that can be done in either Objective-C
or C that can't be done in C++. Should we declare the languages all
equally suited to solving any particular problem? I don't think so.
Direct language support for various programming paradigms is usually
an advantage over cobbled together solutions or hacks - at least when
those paradigms are germane.
I write a lot of high performance numerical code for high performance
computing systems. Among other things, I write real-time emulators
for super-computers so that scientific applications can be easily
migrated to new hardware, and sometimes a few nanoseconds matter.
Most of my numerical code is written in "old style" C++ and primarily
a C subset of C++. As far as I know, there is still no compiler in
the world that completely implements the ANSI/ISO C++ standard which
was ratified in 1998. If the standard hasn't been implemented in a
decade, something is amiss. This is in spite of the fact that the
standard has holes in it large enough to drive trucks through, but I
digress.
All that aside, "modern" C++ can be highly optimized by modern
compilers. Templates and non-virtual function calls can be in-lined
in many cases. Just in-lining removes function call overhead and is
sometimes a major optimization. Then, once the code is in-lined, the
compiler may detect additional opportunities for common code
simplification, loop unrolling, and/or auto-vectorization. However,
remember that templates are in most respects type-safe replacements
for C macros. There is no magic happening.
Both Objective-C message sending and C++ virtual function calls
commonly prevent in-lining because the _compiler_ can not determine
which code will actually be called. If you use Objective-C message
sending or C++ virtual member functions, you forego most low level
optimizations at the call sites. Of course, the implementations of
the methods and member functions (respectively) can still be optimized.
All possible C++ virtual member function implementations must be
determined at link time to enable generation of code at call sites and/
or vtables. Determination of the code that will ultimately be
executed as the result of Objective-C messages sends is postponed
until run time. Postponing determination until run time is one of the
key aspects of dynamism that enable Cocoa as we know it. Postponing
until link time just doesn't postpone the decision long enough.
Therefore, I take issue with Scott Ribe because I don't think Cocoa
can be implemented as we know it in C++.
COM, SOM, IDL, and other mechanisms have been added to C and C++ to
selectively implement a solution that postpones determination of the
"receiver" of a call until run time. Why were those mechanisms
created ? Answer: someone perceived a need for them. I claim that
using COM, SOM, IDL, etc. to retrofit dynamism into C++ is a poor
solution to the problem. I would not want to use a Cocoa that was
implemented using COM for all messaging. Would you ?
In summary, I am a C++ guru who writes real live high performance
numerical code, and I limit myself to a small subset of "old style" C+
+ as a conscious decision. I write almost everything else in
"dynamic" languages including Objective-C. Modern "template meta-
programming" surely has utility or it wouldn't have been invented.
However, it doesn't provide the kind of dynamism needed to implement
Cocoa as we know it, and it isn't necessary for high performance
computation.
As another aside, I concede that _my decisions_ relegate "modern" C++
to a vanishingly small subset of all programming problems _I_ solve.
Others will have different circumstances and experiences. I do
perceive a similar phenomenon in the larger world: "Modern" C++ is
being squeezed between C and languages like Python, Java, and C#. My
perceptions may not reflect reality.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
