Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!hao!oddjob!mimsy!umd5!cvl!elsie!nih-csl!keith From: keith@nih-csl.UUCP Newsgroups: comp.lang.misc,comp.lang.smalltalk,comp.lang.c++ Subject: Re: C++ vs Objective-C Message-ID: <271@nih-csl.UUCP> Date: Thu, 24-Sep-87 10:37:16 EDT Article-I.D.: nih-csl.271 Posted: Thu Sep 24 10:37:16 1987 Date-Received: Sat, 26-Sep-87 16:21:10 EDT References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <509@drexel.UUCP> Organization: NIH-CSL, Bethesda, MD Lines: 94 Xref: utgpu comp.lang.misc:662 comp.lang.smalltalk:315 comp.lang.c++:409 Summary: The REAL difference between C++ and Objective-C in the area of support for O-OP is the C++ is statically typed In article <509@drexel.UUCP>, rickers@drexel.UUCP (Rick Wargo) writes: > In article <1811@watcgl.waterloo.edu>, kdmoen@watcgl.waterloo.edu (Doug Moen) writes: > > csrdi@its63b.ed.ac.uk (Rick Innis, CS4) writes: > > >... I'd also like C++, and may well end up porting > > >that myself, but I've been told that Objective-C is a better language - > > > > Strange... My understanding is that C++ is the better language. > > As usual - which is the "better" language? All things are created to serve > some purpose and both of the aforementioned languages fulfill certain needs. > In general, I agree with Doug's comparison of Objective-C and C++, except for the following: > The dynamic binding is what seperates Objective-C from C++. It is just > a wonderful and powerful feature. It gives an object the freedom of > not having to recognize all types of messages at compile time, instead > it can be done at run-time (yes, at a cost of speed - but Objective-C > uses a quick routine to send messages to objects, using a internal hash > table). And okay, before I get flamed, C++ does have those virtual > functions, but they are not as easy to use as Objective-C's messages > (my own opinion!). Try building and utilizing a hetergeneous list > in both languages. I found the Objective-C code to be more logical and > easier to read and smaller in source code size) than a similar routine > written in C++. The reason that it might appear difficult at first to do polymorphic data structures in C++ is that C++ as it comes out of the box doesn't include any of the necessary scaffolding that Objective-C comes with, nor are there any complete examples to use as a guide. I spent months figuring out how to write fundamental Smalltalk-80/Objective-C -like classes in C++ and, like standing an egg on its end, once you see how it's done, it's easy (and elegant, I might add). I won't get into details here -- my code, the OOPS class library, is in the public domain. The big difference between the way C++ and Objective-C support O-OP is that C++ is statically typed while Objective-C, like Smalltalk-80, is dynamically typed. But if C++ is statically typed, how can it have dynamic binding? Let me explain the difference with an example. Suppose we have a base class called Object and two derived classes (subclasses) String and Rectangle. We want to be able to print Objects, Strings, and Rectangles, and we want to be able to calculate the area of a Rectangle. Note that print is a general function, one that makes sense for any class (at least for debugging purposes), while area only makes sense for Rectangles. In Objective-C, we could define print() as a method for classes String and Rectangle, and we could define area() as a method for only class Rectangle. Even if print() and area() were not defined for class Object, we could write a program that attempted to print an Object and calculate its area, and we would not get any complaint from the preprocessor. If at run time the Object was in fact a String, we would be able to print it, but area() would fail with a "method not found" error. In C++, we could define print() as a member function for classes String and Rectangle, and we could define area() as a member function for only class Rectangle. However, we would also need to declare (not implement) print() as a virtual member function of class Object; otherwise, the C++ preprocessor would complain if we wrote a program that attempted to print an Object. Once this is done, C++ behaves the same as Objective-C when we try to print an Object -- both Strings and Rectangles print as we have defined that operation for their specific class. Note that since area() is not declared as a member function of class Object, we would get a diagnostic from the C++ preprocessor rather than a run-time error if our program attempted to invoke area() on an Object. In C++, if we had an Object that might be a Rectangle at run time that we wished to find the area of, we would first need to verify the class of the object by calling a function like isKindOf(Rectangle), and if it was, we would type cast it to class Rectangle and call area(). In many circumstances, the explicit run-time type check can be eliminated because we can arrange to have C++'s compile-time type checking guarantee that a type cast is safe. In my opinion, C++ -style static typing is better because (1) it is more efficient. In effect, Objective-C always does a run-time type check in its method lookup, whereas in C++ we can often eliminate it, and (2) C++ programs are easier to comprehend because variable types are usually explicit in the code. In Objective-C all objects are declared as type id, and the type of the object that the programmer expects to be working with (i.e., the methods he expects the object to implement) must be deduced from the code or documentation. -- Keith Gorlen phone: (301) 496-5363 Building 12A, Room 2017 uucp: uunet!mimsy!elsie!nih-csl!keith National Institutes of Health Bethesda, MD 20892