fellman@celece.ucsd.edu (Ronald Fellman) (01/02/90)
C'mon. We don't need a g++ vs. Obj.-C war here. After extensive experience with both, I feel that there are perfectly valid reasons for wanting BOTH. Each has its own strengths and infact can complement each other. g++ has operator overloading, looks more like C, and has less overhead. For the same reason that the efficiency is higher, its object-oriented features are less extensive. I would use g++ for writing a low-level behavioral or logic simulator but would use Obj.-C for NeXT gui programs. -ron fellman (rfellman@ucsd.edu)
bates@wingra.stat.wisc.edu (Douglas Bates) (01/02/90)
In article <7647@sdcsvax.UCSD.Edu> fellman@celece.ucsd.edu (Ronald Fellman) writes:
Date: 1 Jan 90 17:29:16 GMT
Organization: UCSD Dept. of ECE
C'mon. We don't need a g++ vs. Obj.-C war here.
After extensive experience with both, I feel that there are perfectly
valid reasons for wanting BOTH. Each has its own strengths and infact
can complement each other.
g++ has operator overloading, looks more like C, and has less overhead.
For the same reason that the efficiency is higher, its object-oriented
features are less extensive. I would use g++ for writing a low-level
behavioral or logic simulator but would use Obj.-C for NeXT gui
programs.
-ron fellman (rfellman@ucsd.edu)
I don't want to see a C++ vs. Obj-C war either - especially after the
recent Mac vs NeXT episode. There are some questions about the
capabilities of C++ and Objective-C that I would appreciate seeing
discussed, though.
I've had limited experience with programming in both languages. In
C++ I find operator overloading and inlined functions useful. I don't
see equivalent capabilities in Obj-C and that would give me problems
if I had a C++ program that I wanted to translate into Obj-C. (If the
capabilites are in Obj-C, please tell me.)
What capabilities in Obj-C would give me troubles if I was translating
the other way?
I see a lot of people learning C++ and many C++ products being
offered. I don't see similar interest in Objective-C outside of the
NeXT user community. I fear that C++ will become the "standard"
object-oriented extension to C and Objective-C will become an oddity
that is only used for writing for NextStep. What aspects of Obj-C do
I play up to convince people that they should write in Obj-C rather
than C++?phd_ivo@gsbacd.uchicago.edu (01/03/90)
C++ allows not only operator overloading, but also some approximation to garbage collection. This makes it very suitable for implementing e.g. programs in linear algebra and statistic, where a matrix language- extension comes in helpful. /ivo welch ivo@next.agsm.ucla.edu
dandb@k.gp.cs.cmu.edu (Dean Rubine) (01/15/90)
In article <BATES.90Jan1140714@wingra.stat.wisc.edu> bates@wingra.stat.wisc.edu (Douglas Bates) writes: >I don't want to see a C++ vs. Obj-C war either - especially after the >recent Mac vs NeXT episode. Agreed. I will comment on some useful features of Objective-C which I believe to be impossible or very difficult to emulate in C++. I don't mean these comments to imply that I believe Objective-C is better in general, but rather that there are certain tasks for which Objective-C is better suited. >What aspects of Obj-C do >I play up to convince people that they should write in Obj-C rather >than C++? [Warning: I mainly use an old version of Obj-C on a microvax, though I have done a little NeXT Obj-C hacking, too. What I have to say here may not be exactly right for the NeXT Obj-C, but it's likely to be close.] The main difference between Obj-C and C++, IMHO, is that Obj-C is really a Smalltalk interpreter imbedded in C, while C++ is truly a compiler. This accounts for many of the advantages of C++, e.g. more efficient message passing, and stronger typing (though I understand the latter has been addressed in the recent NeXT Obj-C release). In Obj-C, all binding of selectors (message names) to methods is done at run time. This accounts for the increased time overhead of Obj-C messages, reputed to equal two C procedure calls, since a search is (conceptually) done on every message send. (There is a cache to speed things up). However, some interesting advantages result from this late binding, advantages that I have found useful in implementing graphical direct-manipulation user interfaces. (I do research in computer gesture recognition, BTW.) In Obj-C, selectors are first class values, of type SEL, which can be easily manipulated in C. Let me illustrate. (Sorry about the old style function arguments...it's what I'm used to.) id apply(o, sel) id o; SEL sel; { return [o perform:sel]; } ... id x = [Someclass new]; apply(x, @selector(print)); /* equivalent to [x print] */ Here I passed an object and a selector (print) to the function apply. Apply simply sends the message indicated by the selector (in this case 'print') to the passed object. Thus, selectors are somewhat analogous to pointers to functions in C. As fas as I know, there's no way to do anything like this in C++ (in other words, I can't manipulate message names in C++). Another advantage of selectors as first class objects is that I can ask an object if it responds to a selector before I try to send that selector to the object. I use this for implementing semantic feedback in my GUI. (An example of semantic feedback is the Macintosh finder, where dragging a file over a folder causes the folder to highlight, dragging a file over the trash causes the trash to highlight, but dragging a file over another file doesn't make anything highlight, because unlike the first two cases, there's no action which happens when I drop a file on another file). My semantic feedback code looks something like this (a serious oversimplification, but it should illustrate the point): id draggedview; /* view being dragged around */ id underview; /* view draggedview is being dragged over */ ... if( [underview respondsTo:[draggedview action]] ) [underview highlight]; And if draggedview is actually dropped on underview: if( [underview respondsTo:[draggedview action]] ) [underview perform:[draggedview action]]; The above code implements semantic feedback in a general way, making almost no assumptions about the draggedview and the underview. I believe nothing of the sort is possible in C++. Yet another advantage of selectors as first class types is that it's possible to convert a C string into a selector. Thus, in my GUI I can prompt for the user to type a selector name, and make a view which the user can drag around whose action is this selector. For example, if the user typed "delete", he gets a little box with the word "delete" in it which he can drag around, and if he drops it on an object which responds to the delete message, that object will be deleted. (He'll know if the object responds to delete by the semantic feedback mechanism discussed above.) Obj-C also knows the structure of objects at runtime, enabling you to write any object (which may reference other objects) to a file at runtime, and read it back, say, the next time the program is invoked. If you've every had to spend time writing code to dump a data structure to a file and read it back in later, you can appreciate what a good feature this is. I don't believe C++ has anything like this. I wrote a graphical Obj-C intepreter, which lets me graphically specify messages (names, selectors, and arguments) at runtime which can then be evaluated immediately. (No way to define new classes at runtime, though.) Pretty slick, and the intepreter itself requires almost no code, since I can simply call the Obj-C interpreter to do the message passing for me. >What capabilities in Obj-C would give me troubles if I was translating >the other way? I think that any use of the kind of stuff I've mentioned would basically be impossible to do in C++, without first writing a C++ interpreter in C++, which is not a undertaking to be taken lightly. As for translating C++ to Obj-C, the things you mentioned (inline functions and operator overloading) are really just syntactic sugar and don't present any great conceptual difficulty to the translator. That's not to imply that it won't be a big pain in the butt to do the translation. -- ARPA: Dean.Rubine@CS.CMU.EDU PHONE: 412-268-2613 [ Free if you call from work ] US MAIL: Computer Science Dept / Carnegie Mellon U / Pittsburgh PA 15213 DISCLAIMER: My employer wishes I would stop posting and do some work.