kdmoen@watcgl.UUCP (09/19/87)
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 - >any versions available? Strange... My understanding is that C++ is the better language. I've used C++, but not Objective-C. I have talked to someone who spent a significant amount of time using Objective-C, and who warned me against it. Here are my impressions: Objective-C is apparently C with Smalltalk code embedded using escape sequences. The problem is that when you program in Objective-C, you have to deal with two universes: the C universe, and the Smalltalk universe. The two universes obey very different laws; code and data exist in either one universe or the other. Of course, there are various interfaces between the C and Smalltalk parts (eg, Smalltalk object pointers can be stored in C variables), but it's a lot messier than programming in a single unified language. For example, if you want to manipulate character strings, you can use either Smalltalk strings or C strings; the two kinds of strings obey different rules, and you might occasionally have to worry about converting between the two string formats. C++, on the other hand, is a single unified language. Classes are a straightforward extension of structures. This means you can take an existing C structure definition, and simply add methods to it, without invalidating existing code that uses the structure. In Objective C, you would presumably have to translate the structure definition into Smalltalk, and change all the code that used the structure into Smalltalk code. I'd be interesting in seeing the opinions of people who have had non-trivial amounts of experience with both languages. -- Doug Moen University of Waterloo Computer Graphics Lab UUCP: {ihnp4,watmath}!watcgl!kdmoen INTERNET: kdmoen@cgl.waterloo.edu
donahue@artecon.artecon.UUCP (Brian D. Donahue) (09/21/87)
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 - >>any versions available? > >Strange... My understanding is that C++ is the better language. > >I've used C++, but not Objective-C. I have talked to someone who >spent a significant amount of time using Objective-C, and who warned >me against it. Here are my impressions: > >Objective-C is apparently C with Smalltalk code embedded using escape >sequences. The problem is that when you program in Objective-C, you >have to deal with two universes: the C universe, and the Smalltalk universe. whoa! what universe did your friend come from? Objective-C is a preprocessor that outputs straight C code. It has nothing to do with Smalltalk at all (except for object oriented concepts of course). > [...] > >in a single unified language. For example, if you want to >manipulate character strings, you can use either Smalltalk strings or >C strings; the two kinds of strings obey different rules, and you might >occasionally have to worry about converting between the two string formats. > >C++, on the other hand, is a single unified language. Umm, I dont think so. (I think) what youre talking about is the ability to use Objective-C's string OBJECT vs. a C "string" character pointer. Yes, they "obey different rules", and yes, you have to worry about which type you're working with (an id vs. a char * ), but there is nothing different in C++ to "unify" the language. You can still declare a char * in C++, and you can still have a string class of objects in C++, and you therefore still have the same problems as with Objective-C. I dont really have an opinion about which is better C++ or Objective-C, Smalltalk seems to be alot cleaner than both of them, although I've never used it :-} bd --- Brian Donahue {seismo, sdcsvax}!esosun!artecon!donahue
tomm@tekig5.TEK.COM (Tom Milligan) (09/21/87)
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 - >>any versions available? > >Strange... My understanding is that C++ is the better language. > >I've used C++, but not Objective-C. I have talked to someone who >spent a significant amount of time using Objective-C, and who warned >me against it. Here are my impressions: > >Objective-C is apparently C with Smalltalk code embedded using escape >sequences. The problem is that when you program in Objective-C, you >have to deal with two universes: the C universe, and the Smalltalk universe. >The two universes obey very different laws; code and data exist >in either one universe or the other. Of course, there are various >interfaces between the C and Smalltalk parts (eg, Smalltalk object pointers >can be stored in C variables), but it's a lot messier than programming >in a single unified language. Both Objective-C and C++ are C language Preprocessors. Thus the capablility exists in both to write "standard" C code. And both produce as their output, "standard" C code. Both provide extenstions to the C language to support the Object-Oriented constructs required for a language to be called Object-Oriented. The C++ extensions appear to be syntactically something of an offshoot of Simula. The Objective-C extensions follow Smalltalk syntactic notations. This is syntax only though. Beneath all of it, though, BOTH ARE C not "C and Simula", or "C and Smalltalk". The notion that in Objective-C you have to deal with "Smalltalk objects" and/or "C objects" and that this makes things un-unified is bogus. There are only C structures in both C++ and Objective-C. >For example, if you want to >manipulate character strings, you can use either Smalltalk strings or >C strings; the two kinds of strings obey different rules, and you might >occasionally have to worry about converting between the two string formats. > This also is bogus. I quote from the Objective-C reference manual: Strings are used to hold a null-terminated array of ASCII characters (ie. by conventional C usage, " a string". There is a structure more complex than just a "char *" that defines strings, but this is true in both C++ and Objective-C. See pages 184-185 in the Stroustrup C++ book for an example of this. To create a string object initialized to "Object-Oriented Programming" in C++ or Objective-C the syntax is as follows: C++ myString = string("Object-Oriented Programming") Objective-C myString = [ String str:"Object-Oriented Programming" ]; One nice thing that Objective-C does not have that C++ does is operator overloading. Thus in C++, "[]" can be defined as a operator on string objects that is defined to behave in a reasonable way for strings (ie. used to index into the string). Thus, assuming that "[]" has been defined as an operator on C++ Strings, then to run through a string looking for the letter "X" the following code fragment would do it. C++ boolean found; for (i=0; i < myString.length; i++) { if (myString[i] == "X") { found = TRUE; break; } } Objective-C boolean found; for (i=0; i < [ myString size ]; i++) { if ([ myString charAt:i ] == "X" { found = TRUE; break; } } There are internal implementation factors that I believe make C++ the more efficient language in this particular example, but what the heck, CPU cycles are cheap :-) >C++, on the other hand, is a single unified language. >Classes are a straightforward extension of structures. This means >you can take an existing C structure definition, and simply add >methods to it, without invalidating existing code that uses the structure. >In Objective C, you would presumably have to translate the structure >definition into Smalltalk, and change all the code that used the structure >into Smalltalk code. > Once again, bogus. One of the primary principles of Object-Oriented languages is this expanability. If you have an existing class that you know to work like you want it to, you create a subclass of that class and add the methods or variables that differentiate it from the parent. If you don't want to create a new subclass, but indeed want to modify the parent class directly, it is the same in both languages: add the methods and/or instance variables that you want to add, and then recompile and link. If you want to hack directly with the structure that the language maintains to represent an object, then things get more complex and you lose portability and encapsulability (sic) in both languages. There is no translation between Smalltalk objects and Objective-C objects, and no requirement to change "all the code that used that structure". In summary, both languages have what it takes to be an object-oriented language. Objective-C uses a Smalltalk-based syntax and C++ uses something akin to Simula syntax. As with all programming languages, what is do-able in Objective-C is do-able in C++, or even C for that matter. As for which language is better, well, I let others more knowlegable than myself hash that one out. I will mention though, that Objective-C has a source-level debugger for it, called Vici. Tom Milligan
rickers@drexel.UUCP (Rick Wargo) (09/22/87)
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 - > >any versions available? > > 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. > Objective-C is apparently C with Smalltalk code embedded using escape > sequences. The problem is that when you program in Objective-C, you > have to deal with two universes: the C universe, and the Smalltalk universe. > ... > C++, on the other hand, is a single unified language. It all depends on your needs. You are correct in stating that C++ is a "unified" language, in respect that it is much more "C-like" than as is Objective-C. And yes, the syntax of Objective-C is very similar to that of Smalltalk, but, like C++, the language is a pre-processor, producing C code. If you do not feel like learning all of the ins and outs of object-oriented programming, but would like some more power from a C-like language, C++ is for you. C++ gives much more functionality per time NOT spent learning it than does Objective-C. C++ give the nice-ities of inheritance, without really understanding inheritance too well. In fact, one does not need to know many of the concepts of object-oriented programming to get a lot from C++. Just the strong type checking and inline code expansion are valuable additions to the C language. Like C++, Objective-C has its strengths (and weaknesses) in different areas. Objective-C is a wonderful language for learning object-oriented programming. It has those four qualities of OOPLS - 1. information hiding 2. data abstraction 3. dynamic binding 4. inheritance 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++. There are so many other similarities and dis-similaities of the two languages, both of the languages should be investigated to find which one suits your needs to the fullest. Summary: If you wish to gain some of the nice-ities of object-oriented programming without going overboard, then time invested using C++ is well spent. But if you are interested in real object-oriented programming then check out Objective-C. > I'd be interesting in seeing the opinions of people who have had > non-trivial amounts of experience with both languages. I have had lots of experience in the past with both languages, but due to current projects, have not kept up-to-fate with either. It's been two years this month that I had tried (unsuccessfully, I might add) to port Objective-C to the Macintosh for PPI. Supposedly they have someone who is to continue the port. I also taught a "for-fun" class about object-oriented programming, using both C++ and Objective-C as the main languages on which the course was based, though I took concepts of object-oriented programming from many different object- oriented languages and languages with o-o extensions. I also have some (do nothing :-) code which tries to do the same thing in both languages, utilizing a variety of different o-o concepts which I can make available quite easily (i think). > Doug Moen > University of Waterloo Computer Graphics Lab Rickers ..!drexel!rickers
tombre@crin.crin.fr (Karl Tombre) (09/22/87)
I don't think it's so easy to say which language is "better". Neither do I think that one is more "unified" than the other. What was said about Objective-C (dealing with 2 universes) may be true, but 1) it depends on the way you program. If it is important for you to use strings as objects, use the Smalltalk-80 like class for strings. If you occasionnaly want to printf() something, use a C string. In fact, you can consider it as two layers. You are not compelled to use the C constructs, but they may be useful for efficiency. 2) the same can be said of C++. It is not more "unified" than Objective-C. You also retain full compatibility with C, you can use structs instead of classes, the privacy mechanism is sometimes a bit confusing because of the C layer, ... In fact, C++ and Objective-C are good examples for two main directions in Object-Oriented Programming : the "norwegian" school and the Smalltalk school. C++ is in the "norwegian" family, that is a successor of Simula-67, the first object-oriented language. As Simula, it has static typing and restricted dynamic binding by ways of virtual functions. As Bjarne Stroustrup points out in a paper (What is Object-Oriented Programming), a C++ (or Simula-67) class is an exact specification, whereas a Smalltalk class is a minimal specification. C++ adds some new features to Simula-67 : private data, friend functions (which are not necessary in Simula-67 where the data are not private), operator overloading, constructors and destructors... But basically it remains in the same family. Among other things, the main entity is the class, not the object. Inside a class, there is no privacy : two instances of the same class have access two each other's private fields. Objective-C is a child of Smalltalk-80. It implements dynamic typing and binding by means of run-time message transmission. The individual object is completely private : you are only allowed to access it's fields through access methods, and hence a message. There are clear analogies between the factory methods and the metaclass methods in Smalltalk. At run-time, the factory is a special object which implements the class in a way. But you can also use at any moment the C layer, for instance when writing a method for a class. Thus, you have direct access to the private data of the current object, and hence you can write efficient methods. My feeling : it is interesting to compare the two languages, but difficult to say which is "better", as both of them implement well the principles of one of the OOP "schools". The comparison is more between those schools than between the 2 languages. --- Karl Tombre @ CRIN (Centre de Recherche en Informatique de Nancy) EMAIL : tombre@crin.crin.fr -- tombre@crin.UUCP POST : Karl Tombre, CRIN, B.P. 239, 54506 VANDOEUVRE CEDEX, France PHONE : +33 83e the ce t
keith@nih-csl.UUCP (keith gorlen) (09/22/87)
> >For example, if you want to > >manipulate character strings, you can use either Smalltalk strings or > >C strings; the two kinds of strings obey different rules, and you might > >occasionally have to worry about converting between the two string formats. > > > > This also is bogus. I quote from the Objective-C reference manual: > > Strings are used to hold a null-terminated array of ASCII characters > (ie. by conventional C usage, " a string". > > There is a structure more complex than just a "char *" that defines strings, > but this is true in both C++ and Objective-C. See pages 184-185 in the > Stroustrup C++ book for an example of this. > > To create a string object initialized to "Object-Oriented Programming" in C++ > or Objective-C the syntax is as follows: > > C++ > myString = string("Object-Oriented Programming") > > Objective-C > myString = [ String str:"Object-Oriented Programming" ]; > > In C++ you can define a class String to implement dynamic character strings. The data structure chosen can be much more complex than a char*. If properly done, you can create an initialized String as follows: String myString = "Object-Oriented Programming"; But here's the part you can't do in Objective-C -- you can define implicit type conversions for class String; in particular, you can define the constructor: String::String(const char*); Which the compiler will call automatically to convert char*s to Strings, and you can define the member function: String::operator const char*(); which the compiler will call automatically to convert Strings to char*s. Thus, if you have a function foo(String), you can write foo("Hello, world") -- C++ recognizes that foo() needs a String as its argument and calls your constructor to make one from the char* "Hello, world". Similarly, you can use your Strings in place of char*s: if (strcmp(myString,"hello") == 0) [Actually, a C++ programmer would overload ==, !=, >, and so on to do String comparisons; e.g., you would write: if (myString == "hello")] This feature lets a programmer blend the data structures used for his own objects with those needed by the environment. Another important point is what you HAVE to do in Objective-C that you often don't in C++: free the string when your'e done with it: Objective-C: foo() { id myString; myString = [ String str:"Object-Oriented Programming" ]; // code that uses myString [myString free]; // free the String } C++: foo() { String myString = "Object-Oriented Programming"; // code that uses myString } C++ understands that myString is an auto, and frees it automatically when it goes out of scope. > In summary, both languages have what it takes to be an object-oriented > language. Objective-C uses a Smalltalk-based syntax and C++ uses something > akin to Simula syntax. As with all programming languages, what is do-able in > Objective-C is do-able in C++, or even C for that matter. Talking about what is do-able is pointless -- any language with the power of a Turing machine can do anything, theoretically. The question is what things does a language make it easy and pleasant to do. C++ features such as strong type checking and references make it a better C for those not doing O-OP. Features such as classes, function and operator overloading, user-controlled implicit type conversion, and guaranteed initialization/finalization make it far better for programming with abstract data types than Objective-C or Modula-2, for example. And derived classes and virtual functions make C++ as good or better than Objective-C for O-OP. > I will mention though, that Objective-C has a source-level debugger > for it, called Vici. What C++ currently lacks are the symbolic debugger and the extensive, mature, supported class library that Objective-C has. But these are just a matter of time. -- Keith Gorlen phone: (301) 496-5363 Building 12A, Room 2017 uucp: uunet!mimsy!elsie!nih-csl!keith National Institutes of Health Bethesda, MD 20892
jss@hector.UUCP (Jerry Schwarz) (09/22/87)
In article <1971@tekig5.TEK.COM> tomm@tekig5.UUCP (Tom Milligan) writes: >kdmoen@watcgl.waterloo.edu (Doug Moen) writes: > >Both Objective-C and C++ are C language Preprocessors. Thus the capablility >exists in both to write "standard" C code. And both produce as their output, >"standard" C code. I can't say with respect to Objective-C, but with regards to C++ this is not the case. C++ is a language that is (mostly but not 100%) an extension of C. The commonly available compiler does use C as an intermediate language, but it is not a preprocessor. The pragmatic justification for this assertion is that if the C compiler ever produces an error message while compiling the intermediate code produced by the C++ front-end it is a bug or limitation in the C compiler or the C++ front-end. I can assert this without looking at the source code being compiled. Jerry Schwarz Bell Labs Murray Hill
ark@alice.UUCP (09/22/87)
In article <1971@tekig5.TEK.COM>, tomm@tekig5.UUCP writes: > Beneath all of it, > though, BOTH ARE C not "C and Simula", or "C and Smalltalk". The notion that > in Objective-C you have to deal with "Smalltalk objects" and/or "C objects" > and that this makes things un-unified is bogus. There are only C structures > in both C++ and Objective-C. This statement is both literally true and uninteresting. After all, since C compiles into machine language, there are only machine language structures in C.
landauer%morocco@Sun.COM (Doug Landauer) (09/23/87)
>> == Doug Moen > == Tom Milligan >>Objective-C is apparently C with Smalltalk code embedded using escape >>sequences. The problem is that when you program in Objective-C, you >>have to deal with two universes: the C universe, and the Smalltalk universe. To be more fair, the embedded Smalltalk-like code in Objective-C is embedded within C by using statements surrounded by brackets; new classes and methods by statements beginning with +, -, or =. And you can cross between the universes -- so it's more like two offices, down the hall from one another, than two universes. > ... This is syntax only though. Beneath all of it, >though, BOTH ARE C not "C and Simula", or "C and Smalltalk". The notion that >in Objective-C you have to deal with "Smalltalk objects" and/or "C objects" >and that this makes things un-unified is bogus. There are only C structures >in both C++ and Objective-C. By the same token, there are *no* C structures, only collections of bits; and assembly language is just as powerful as both C++ and Objective-C, and they're all just as powerful as a Turing machine. Now that *is* bogus. (True, in a way, but bogus nonetheless.) Just because most current implementations of both of these languages are compiled into C doesn't make them equivalent to C from the programmer's point of view. What makes this "syntax only" difference important to me is that the additional features of C++ (over C) are invoked using syntax that looks like the rest of C, while the object-oriented parts of Objective-C look like they were grafted on. >>C++, on the other hand, is a single unified language. >>Classes are a straightforward extension of structures. This means >>you can take an existing C structure definition, and simply add >>methods to it, without invalidating existing code that uses the structure. >>In Objective C, you would presumably have to translate the structure >>definition into Smalltalk, and change all the code that used the structure >>into Smalltalk code. > >Once again, bogus. No, this is not bogus; in fact, it is one of the primary differences between the two languages: C++ "looks like C", and Objective-C looks like "C with embedded Smalltalk statements". Objective-C requires a different incantation to perform an object-oriented message-send than to call a function. C++ doesn't. >In summary, both languages have what it takes to be an object-oriented >language. Objective-C uses a Smalltalk-based syntax and C++ uses something >akin to Simula syntax. Well, something derived from the Simula syntax, but which actually looks more like C than it looks like Simula. >As for which language is better, well, I let others more knowlegable than >myself hash that one out. Neither language is "better" for everyone. Some prefer C++, some prefer Objective-C. Hell, some people still prefer Forth, APL, COBOL & FORTRAN! -- Doug Landauer Sun Microsystems, Inc. ARPA Internet: landauer@sun.com Software Products Division UUCP: {amdahl, decwrl, hplabs, seismo, ...}!sun!landauer
gaynor@topaz.rutgers.edu (Silver) (09/23/87)
ark@alice.UUCP writes: > After all, since C compiles into machine language, there are only > machine language structures in C. This statement is misleading, reflecting ignorance of the difference between data types and data structures. It would have been correct and more informative to say: The data types of (native) C were chosen because they are efficiently mapped onto those of almost every machine language. This applies to Pascal, Algol, and almost all languages termed Fourth Generation. However, the data types of, say, Lisp and Prolog, often do not map as easily onto those of machine languages. Heresay: C++ is generally superior to Objective-C except supportive software-development software. Silver. LOOKING FOR ENTRY-LEVELISH C/LISP PROGRAMMING, SOFTWARE ENGINEERING Andy Gaynor 201-545-0458 81 Hassart St, New Brunswick, NJ 08901 gaynor@topaz.rutgers.edu ...!rutgers!topaz.rutgers.edu!gaynor "There is no Editor but Emacs, and Lisp is its Prophet."
ken@pdn.UUCP (09/23/87)
In article <270@nih-csl.UUCP>, keith@nih-csl.UUCP (keith gorlen) writes: > Talking about what is do-able is pointless -- any language with the > power of a Turing machine can do anything, theoretically. The > question is what things does a language make it easy and pleasant to > do. C++ features such as strong type checking and references make it > a better C for those not doing O-OP... True, but why use either if you are not going to be using O-OP? > ...Features such as classes, > function and operator overloading, user-controlled implicit type > conversion, and guaranteed initialization/finalization make it far > better for programming with abstract data types than Objective-C or > Modula-2, for example. And derived classes and virtual functions make > C++ as good or better than Objective-C for O-OP. I believe I detect a bit of bias in this statement. Let's face it, Smalltalk is the "model of an OO language". (Please let's not start a discussion about how good/bad you think Smalltalk is). What PPI has tried to do is to allow you to use most of the advantages of Smalltalk while allowing you to speed up the final result (compiler vs. interpreter). To name just one feature that is missing from C++, Objective-C has the concept of "class methods" (i.e. Classes are treated like objects). Without getting picayune, Objective-C gives you a compiled version of Smalltalk (please, no flames from Smalltalkers -- I wouldn't trade Smalltalk for either, I'm just trying to make a point) -- C++ does not. I'm not saying that Objective-C is better than C++ (or vice versa), but I am saying that which is better can be greatly swayed by your frame of reference. > > I will mention though, that Objective-C has a source-level debugger > > for it, called Vici. > > What C++ currently lacks are the symbolic debugger and the extensive, > mature, supported class library that Objective-C has. But these are > just a matter of time. So does that mean I should use C++ now because some day I'll have a debugger and a healthy library to draw upon? It's just a matter of time until my thought patterns can be turned into words, and then programs -- does this mean I should stop typing!?! Anyone who knows anything about OOP knows that one of the great attractions of it is its idea of (as PPI calls it) "software ICs" which can be used over and over and be built upon. Anyone who has ever programmed knows the value of a debugger. I don't know about you, but most of the work I do has to be done in the present and not in the future. I choose to use the best tools that are available to me. I don't believe anybody (with the possible exception of a person in a university environment) can truly evaluate any language without evaluating what tools are available with the language. A language is just a vehicle to produce some product. The goal is the product, not the language. Therefore if the language (along with its tools) get that product completed earlier (and, might I add, with less frustration) than another, the language is superior. Once again, I'm not saying one is better than the other. The point is that one can not throw out certain features (tools) of the language in evaluating that language. One last point (take it or leave it) is that if/when C++ has the "symbolic debugger and the extensive, mature, supported class library that Objective-C has" now, what additional features might Objective-C have. -------------------------------------------------------------------------- Ken Auer Paradyne Corporation {gatech,codas,ucf-cs}!usfvax2!pdn!ken Mail stop LF-207 Phone: (813) 530-8307 P.O. Box 2826 Largo, FL 34649-9981 "The views expressed above do not necessarily reflect the views of my employer, which by no means makes them incorrect."
ken@pdn.UUCP (09/23/87)
In article <28774@sun.uucp>, landauer%morocco@Sun.COM (Doug Landauer) writes: > point of view. What makes this "syntax only" difference important to > me is that the additional features of C++ (over C) are invoked using > syntax that looks like the rest of C, while the object-oriented parts of ^^^^^^^^^^^^^^^^^^^^^^^^ > Objective-C look like they were grafted on. "Looks like" are the key words here. var1 << var2; *looks like* C code which means "logically shift var1 left var2 bits". However in C++ it COULD mean "put var2 onto outputStream var1". C++ also uses ampersands (&) for more purposes than standard C does, and more than I thought possible by any language, which can become very confusing. The list of these types of confusing uses of symbols can go on. The point is that some of the extensions to C by C++ can be extremely confusing until you carefully examine the context of some of these symbols. At least I know, at a glance, when a "message-send" (i.e. an "object-oriented part") is occuring in the "grafted on" extensions of Objective-C. I can't say the same for the "shoved in" extensions of C++. Both C++ and Objective-C basically add object-oriented features to a procedure oriented language. Both allow the two approaches to be intermixed. Objective-C allows the user to see the difference, while C++ forces the user to figure it out. -------------------------------------------------------------------------- Ken Auer Paradyne Corporation {gatech,codas,ucf-cs}!usfvax2!pdn!ken Mail stop LF-207 Phone: (813) 530-8307 P.O. Box 2826 Largo, FL 34649-9981 "The views expressed above do not necessarily reflect the views of my employer, which by no means makes them incorrect."
kim@geovision.UUCP (Kim Fillmore) (09/24/87)
In article <604@artecon.artecon.UUCP> donahue@artecon.UUCP (Brian D. Donahue) writes: >In article <1811@watcgl.waterloo.edu> kdmoen@watcgl.waterloo.edu (Doug Moen) writes: >> >>Objective-C is apparently C with Smalltalk code embedded using escape >>sequences. The problem is that when you program in Objective-C, you >>have to deal with two universes: the C universe, and the Smalltalk universe. > >whoa! what universe did your friend come from? Objective-C is a >preprocessor that outputs straight C code. It has nothing to do with >Smalltalk at all (except for object oriented concepts of course). > >bd > >--- >Brian Donahue {seismo, sdcsvax}!esosun!artecon!donahue Yes, after you have run the preprocessor, the code it puts out is straight C, which you then run through your favourite C compiler. The code that comes out can contain structures like case statements with 400 cases, and lines that are hundreds of characters long, which is why it doesn't work well on small systems; their C compiler isn't up to it. BUT, when the programmer *writes* the Objective-C code, he embeds Smalltalk commands, enclosed in [], in the C code. As I understand it, the syntax of the embedded commands is pure Smalltalk. In C++, there is only one syntax, and, as stated before, a unified language. Also, no preprocessing step to *translate* to C. Another dubious feature of Objective-C is that allows you to define the Smalltalk special object *self* and then lets the C code stomp on it and change its value (kind of destroys the credibility of the self object :-). Also, it will allow access to internal fields of an object by coercing the pointer (ie. I know if I add x to my pointer it will give me y, and so what if I've just introduced a hard to trace bug if y's definition is changed). I recognize that people can get around almost any safeguards if they try hard enough (which they always do :-). I was at a talk on Objective-C, given by Kurt Schmuker of PPI, and I thought there were some serious problems with it, although I've never worked with it. The big drawback was that it was Smalltalk pasted on top of C. C++, on the other hand, is a new, extended (improved? :-) C. I've never *used* Objective-C, although I have used C++ and Smalltalk. I too would be interested in hearing from someone who has used both C++ and Objective-C. All the usual disclaimers. ---Kim -- Kimberly Fillmore (613) 722-9518 | Duct tape is like the Force - it has GeoVision Corp, 350-1600 Carling Ave | a light side and a dark side, and Ottawa Canada K1Z 8R7 | holds the universe together. UUCP: ...!utzoo!dciem!nrcaer!cognos!geovision!kim
keith@nih-csl.UUCP (09/24/87)
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
rcopm@koel.rmit.oz (Paul Menon) (09/25/87)
The argument about which is better between C++ and Objective-C so far has been a matter of how "powerful" each language is. Since both are "successors" to C, each inherit the same property of being very writable, but very unreadable. Anything either does to improve the situation, has to be an advantage. This is where, in my opinion (and that's all it is) Objective-C is streets ahead of C++. C++ further confuses the issue with overloading, etc. The Object-Oriented features of Objective-C stand out like a sore thumb to any Smalltalk reader. The added features of C++ do not. One can migrate to an almost non-C like language in Objective-C, which gets rid of it's unreadability. To be productive doesn't mean to write compact code, that's what the gurus would have you believe. It is being able to understand a program/package quickly, and use high level, easy to understand tools to build on or create. C++ does not do this. Objective-C does. Paul Menon. Dept of Communication & Electronic Engineering, Royal Melbourne Institute of Technology, 124 Latrobe St, Melbourne, 3000, Australia ACSnet: rcopm@koel UUCP: ...!seismo!munnari!koel.rmit.oz!rcopm CSNET: rcopm@koel.rmit.oz ARPA: rcopm%koel.rmit.oz@seismo BITNET: rcopm%koel.rmit.oz@CSNET-RELAY PHONE: +61 3 660 2619.
johnson@uiucdcsp.cs.uiuc.edu (09/25/87)
While I spent a number of years as a C programmer, I have spent the last several using Smalltalk and enjoying every minute of it. Recently I have had the opportunity to learn and use C++. It was not at all hard for me to learn, and I have not had the slightest problem with & or any other symbol. My problems have been the usual C problems with null pointers and the like. My opinion is that C++ is a good compromise between the Unix environment and object-oriented programming. I don't understand the recent complaints about it. The major problem with C++ is the lack of a class library. AT&T is shooting themselves in the foot by not providing one. OOP (or is it OOPS?) is a start, but AT&T did not create it. The major advantage of o-o programming is software reuse, but reusable software is ten times as hard to write as software than merely works, so it is entirely unreasonable to expect local programmers to produce it. An object-oriented language needs an extensive class library to be successful.
alastair@geovision.UUCP (Alastair Mayer) (09/25/87)
In article <1971@tekig5.TEK.COM> tomm@tekig5.UUCP (Tom Milligan) writes: > >Both Objective-C and C++ are C language Preprocessors. Thus the capablility Sorry, no. Objective-C is indeed a preprocessor, but C++ is a C superset and the C++ 'program' is actually a *compiler* for the language C++. It is C++ (specifically the 'cfront' pass) that does the syntactic and semantic analysis. >exists in both to write "standard" C code. And both produce as their output, >"standard" C code. Both provide extenstions to the C language to support the The release version of C++ does happen to use your existing C compiler as a code-generator. However, the output from C++ is a C-language version of the internal parse tree, ie new code, not the old code with the C++ extensions translated. I understand that the C++ compiler used internally at Bell Labs bypasses this step. >and that this makes things un-unified is bogus. There are only C structures >in both C++ and Objective-C. Maybe in terms of the structures, perhaps. But in terms of what a program in the language *looks* like, C++ is far more unified. I think Objective-C does far more violence to the syntax of C than does C++. -- Alastair JW Mayer BIX: al UUCP: ...!utzoo!dciem!nrcaer!cognos!geovision!alastair "What we really need is a good 5-cent/gram launch vehicle."
keith@nih-csl.UUCP (keith gorlen) (09/26/87)
In article <1414@pdn.UUCP>, ken@pdn.UUCP (Ken Auer) writes: >Both C++ and Objective-C basically add object-oriented features to a >procedure oriented language. Yes, and C++ goes further by fixing some things that are bad about C (by adding stronger type checking, call-by-reference, inline functions, constant types), and has better support for data abstraction (operator and function overloading, guaranteed initialization/finalization) -- features valuable to those that have need for programming paradigms other than O-OP. Objective-C doesn't do much for someone who needs complex numbers or matrices, for example. C++ does. >Both allow the two approaches to be intermixed. But C++ with its programmer-defined implicit type conversion does a better job, as I demonstrated in the String example. >Objective-C allows the user to see the difference, while C++ forces >the user to figure it out. I would say that Objective-C forces the user to see the difference, while C++ has features that permit a competent programmer to hide the difference from users of his/her software. A bad C++ programmer can do some awful things, but that is true of most other programming languages, including C. That hasn't preventing C from becoming a highly successful language. -- Keith Gorlen phone: (301) 496-5363 Building 12A, Room 2017 uucp: uunet!mimsy!elsie!nih-csl!keith National Institutes of Health Bethesda, MD 20892
keith@nih-csl.UUCP (keith gorlen) (09/26/87)
In article <1406@pdn.UUCP>, ken@pdn.UUCP (Ken Auer) writes: > In article <270@nih-csl.UUCP>, keith@nih-csl.UUCP (keith gorlen) writes: > > C++ features such as strong type checking and references make it > > a better C for those not doing O-OP... > > True, but why use either if you are not going to be using O-OP? You would use C++ if you don't need O-OP because it is an improved C. > > ...Features such as classes, > > function and operator overloading, user-controlled implicit type > > conversion, and guaranteed initialization/finalization make it far > > better for programming with abstract data types than Objective-C or > > Modula-2, for example. And derived classes and virtual functions make > > C++ as good or better than Objective-C for O-OP. > I believe I detect a bit of bias in this statement. Absolutely! In 1985 I set about looking for a language to do O-OP in C. I evaluated C/Flavors, Objective-C, and C++. I went to one of PPI's seminars (which I recommend), purchased a set of Objective-C reference manuals, and read Cox's book (which I also recommend, but the info on C++ is not correct). My choice was to go with C++ because it was the best designed language and I felt that it would win out in the long run. > To name just one feature that is missing from C++, Objective-C has the concept > of "class methods" (i.e. Classes are treated like objects). C++ also doesn't have I/O because "you can program that yourself" with the features the language does have. I wrote a fundamental Smalltalk-80 -like class library for C++ that is very similar to what the Objective-C class library was like circa 1985. It has a class Class, derived from class Object so that class descriptions can be manipulated like objects. It's not quite as good as Objective-C's, but good enough for most practical purposes and probably more efficient. > I don't know about you, but most of the work I do has to be done in the > present and not in the future. You are right. I happen to have the luxury of time to plan for the (not so distant) future. > One last point (take it or leave it) is that if/when C++ has the "symbolic > debugger and the extensive, mature, supported class library that Objective-C > has" now, what additional features might Objective-C have. Objective-C might have multiple inheritance, dynamic linking and garbage collection some day, but I doubt that it will ever have the non-O-OP features of C++. Speaking of extensive class libraries, I just read that IBM is placing C-MU's Base Environment 2 (BE2) class library in the public domain, to be distributed with the December release of X Windows. BE2 is the most impressive class library I've seen in action. It is written in Class, yet another C preprocessor that adds O-OP support to C. From the sketchy preliminary documentation I've read, it appears to do a cleaner job than Objective-C, though not as good as C++. One powerful feature it has is dynamic linking. Maybe someone who knows something about Class can jump in the fray. I'd love to be able to use the BE2 class library from C++ -- talk about HEAVEN! -- Keith Gorlen phone: (301) 496-5363 Building 12A, Room 2017 uucp: uunet!mimsy!elsie!nih-csl!keith National Institutes of Health Bethesda, MD 20892
keith@nih-csl.UUCP (keith gorlen) (09/26/87)
In article <338@crin.crin.fr>, tombre@crin.crin.fr (Karl Tombre) writes: > 2) the same can be said of C++. It is not more "unified" than Objective-C. Yes, it is. A C++ programmer can write functions to convert instances of his own classes into fundamental C types and vice-versa. The C++ compiler, since C++ is strongly typed, can arrange to call these type conversion functions automatically. Thus, it is possible to implement your own class String, and use instances of String interchangeably with char*, for example. -- Keith Gorlen phone: (301) 496-5363 Building 12A, Room 2017 uucp: uunet!mimsy!elsie!nih-csl!keith National Institutes of Health Bethesda, MD 20892
berger@datacube.UUCP (09/27/87)
There is one major criteria that is swaying me twards selecting C++ as the choice for our experimentation with OOPs and that is price. The second major influence in my decision is that C++ is multiple sourced now and looks more like an emerging defacto standard than Objective-C. PPI's marketing of Objective-C seems quite short sighted..... They could have seeded the world with it a year ago and made it a standard. Now if ATT just bundled C++ with Unix....
windley@iris.ucdavis.edu (Phil Windley) (09/29/87)
In article <275@nih-csl.UUCP> keith@nih-csl.UUCP (keith gorlen) writes: > since C++ is strongly typed, Can C++ (or any of the others in this contest) be weakly typed as well as strongly typed? Does the programmer have any control over this? Any advantages to letting the programmer have a choice? Just curious. Phil Windley Robotics Research Lab University of California, Davis
bart@speedy.UUCP (09/29/87)
We have a system to do dynamic linking in C++. For more info see the upcoming OOPSLA Conf proceedings. (we have also built RPC into cfront while only very mildly munging with the language) --bart miller uw-madison cs dept bart@asiago.wisc.edu ...!uwvax!bart
tombre@crin.UUCP (09/30/87)
In article <305@ucdavis.ucdavis.edu> windley@iris.ucdavis.edu (Phil Windley) writes: >In article <275@nih-csl.UUCP> keith@nih-csl.UUCP (keith gorlen) writes: >> since C++ is strongly typed, > >Can C++ (or any of the others in this contest) be weakly typed as well >as strongly typed? Does the programmer have any control over this? >Any advantages to letting the programmer have a choice? Just curious. > Isn't the difference more between static and dynamic typing than between weak and strong typing ? Admitted, C is not very strongly typed. But when you compare Objective-C and C++, the difference is elsewhere. In C++, the typing is static, that is you check the validity of your expressions at compilation time, and if necessary the compiler does automatic type casting (C++ is VERY good at that!!). In Objective-C, at least in the "object environment", the typing is completely dynamic : at compile time you only translate a message [object message] into a call to the _msg() function, which at run time searches for the right method in the class tables. This provides dynamic binding in Objective-C. In C++, you have to declare a function as virtual to get a limited dynamic binding. What is better? It depends what you do. Objective-C will give you a less rigid environment, but you lose strictness and a bit efficiency. In addition, if your concern is to write reliable code (in the sofware engineering sense), you might want to have most problems detected at compile time; then C++ is for you. If you want to write a prototype without knowing exactly all the aspects of the final product, but with more efficiency than Smalltalk, go for Objective-C. The debate is one between two philosophies in object-oriented programming: the Smalltalk approach and the Simula (or C++) approach. To put it schematically, and not very strictly (please do not flame me on this, I'm just having a little fun generalizing), we can say that: In Smalltalk or Objective-C everything which is not explicitely prohibited is allowed. In Simula-67 or C++ everything which is not explicitely authorized (or let us say planned in advance) is prohibited. Any comments? --- Karl Tombre @ CRIN (Centre de Recherche en Informatique de Nancy) EMAIL : tombre@crin.crin.fr -- tombre@crin.UUCP POST : Karl Tombre, CRIN, B.P. 239, 54506 VANDOEUVRE CEDEX, France PHONE : +33 83.91.21.25
djones@megatest.UUCP (Dave Jones) (10/02/87)
In article <604@artecon.artecon.UUCP> donahue@artecon.UUCP (Brian D. Donahue) 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 - >>>any versions available? >> >>Strange... My understanding is that C++ is the better language. >> >>I've used C++, but not Objective-C. I have talked to someone who >>spent a significant amount of time using Objective-C, and who warned >>me against it. Here are my impressions: >> >>Objective-C is apparently C with Smalltalk code embedded using escape >>sequences. The problem is that when you program in Objective-C, you >>have to deal with two universes: the C universe, and the Smalltalk universe. > >whoa! what universe did your friend come from? Objective-C is a >preprocessor that outputs straight C code. It has nothing to do with >Smalltalk at all (except for object oriented concepts of course). > >> [...] >> [...] >Brian Donahue {seismo, sdcsvax}!esosun!artecon!donahue The allusion to Smalltalk probably refers to the fact that Objective-C has fascilities for the binding of methods at runtime. C++ is (I think) mostly just a preprocessor, while Objective-C brings some runtime features to the party. It even has an interpretter that can be embedded in an application. The Objective-C book is quite good reading. But the product itself may be too expensive to try on speculation.
bob@pdn.UUCP (Bob Hickle) (10/15/87)
In article <185@geovision.UUCP>, alastair@geovision.UUCP(Alastair Mayer) writes: > In article <1971@tekig5.TEK.COM> tomm@tekig5.UUCP (Tom Milligan) writes: > > > >Both Objective-C and C++ are C language Preprocessors. Thus the capablility > > Sorry, no. Objective-C is indeed a preprocessor, but C++ is a C superset > and the C++ 'program' is actually a *compiler* for the language C++. It > is C++ (specifically the 'cfront' pass) that does the syntactic and semantic > analysis. Wait a minute here! The Objective-C COMPILER is just as much a compiler as the C++ compiler. The Objective-C compiler does parsing, syntactic and semantic analysis of the Objective-C language. It builds parse trees, etc just like other compilers do. > The release version of C++ does happen to use your existing C compiler > as a code-generator. However, the output from C++ is a C-language version > of the internal parse tree, ie new code, not the old code with the C++ > extensions translated. I understand that the C++ compiler used internally > at Bell Labs bypasses this step. > Well heck, the output of ANY (working) compiler is some concrete representation of the internal parse tree. Anyway, I believe (but may be wrong here) that the Objective-C compiler also compiles the ordinary C code in an Objective-C program. It just happens to produce output which is the same C code. That does not mean that it has not been compiled (ie. parsed, syntax checked, etc). I see that PPI (the vendor of Objective-C) is now on the net. Any comments from them? ------------------------------------------------------------------- Bob Hickle Paradyne Corporation {gatech,codas,ucf-cs}!usfvax2!pdn!bob Mail stop LF-207 Phone: (813) 530-2664 8550 Ulmerton Road, PO Box 2826 Largo, FL 34641
bob@pdn.UUCP (Bob Hickle) (10/19/87)
In article <1549@pdn.UUCP>, bob@pdn.UUCP (me) writes: > representation of the internal parse tree. Anyway, I believe (but may > be wrong here) that the Objective-C compiler also compiles the ordinary > C code in an Objective-C program. It just happens to produce output > which is the same C code. That does not mean that it has not been > compiled (ie. parsed, syntax checked, etc). Well, I was right in that I may be wrong. Jonathan Shopiro (AT&T Bell Labs) suggested that I try to compile the following program with the Objective-C compiler and figure out where the error message comes from. ------------------------------- int f(); main() { int i = f; } ------------------------------- I tried it and determined that the Objective-C compiler has nothing bad to say about this program. It appears to pass it through (and prepends some header stuff on the front). The C compiler of course complains about the assignment statement. So my previous statement that the Objective-C compiler 'compiles' ordinary C code in an Objective-C program was wrong. Thats what I get for making claims without fully verifying them first. ------------------------------------------------------------------------ Bob Hickle Paradyne Corporation {gatech,codas,ucf-cs}!usfvax2!pdn!bob Mail stop LF-207 Phone: (813) 530-2664 8550 Ulmerton Road, PO Box 2826 Largo, FL 34641
alan@pdn.UUCP (Alan Lovejoy) (10/19/87)
In article <1579@pdn.UUCP> bob@pdn.UUCP (Bob Hickle) writes: /In article <1549@pdn.UUCP>, bob@pdn.UUCP (me) writes: /> representation of the internal parse tree. Anyway, I believe (but may /> be wrong here) that the Objective-C compiler also compiles the ordinary /> C code in an Objective-C program. It just happens to produce output /> which is the same C code. That does not mean that it has not been /> compiled (ie. parsed, syntax checked, etc). / /Well, I was right in that I may be wrong. / /Jonathan Shopiro (AT&T Bell Labs) suggested that I try to compile the /following program with the Objective-C compiler and figure out where /the error message comes from. / /------------------------------- /int f(); / /main() /{ / int i = f; /} /------------------------------- / /I tried it and determined that the Objective-C compiler has nothing bad /to say about this program. It appears to pass it through (and prepends /some header stuff on the front). The C compiler of course complains /about the assignment statement. / /So my previous statement that the Objective-C compiler 'compiles' /ordinary C code in an Objective-C program was wrong. Thats what I /get for making claims without fully verifying them first. /------------------------------------------------------------------------ /Bob Hickle Paradyne Corporation /{gatech,codas,ucf-cs}!usfvax2!pdn!bob Mail stop LF-207 /Phone: (813) 530-2664 8550 Ulmerton Road, PO Box 2826 / Largo, FL 34641 / Not so fast, Bob. You should ask me first before rushing off to proclaim your imperfections on linguistic matters. It is not necessarily true that Objective-C is not "compiling" the program fragment in your example. What your example does prove is that semantic analysis (which usually amounts to type-checking) is not being performed. Semantic analysis is not a requirement for a compiler (the Smalltalk compiler doesn't do it, for example). --alan@pdn
cox@ppi.UUCP (Brad Cox) (10/20/87)
In article <1549@pdn.UUCP>, bob@pdn.UUCP (Bob Hickle) writes: > In article <185@geovision.UUCP>, alastair@geovision.UUCP(Alastair Mayer) writes: > > Sorry, no. Objective-C is indeed a preprocessor, but C++ is a C > > superset and the C++ 'program' is actually a *compiler* for the language > > C++. It is C++ (specifically the 'cfront' pass) that does the syntactic > > and semantic analysis. > > Wait a minute here! The Objective-C COMPILER is just as much a compiler > as the C++ compiler. The Objective-C compiler does parsing, syntactic and > semantic analysis of the Objective-C language. It builds parse trees, etc > just like other compilers do. > > > The release version of C++ does happen to use your existing C compiler > > as a code-generator. However, the output from C++ is a C-language version > > of the internal parse tree, ie new code, not the old code with the C++ > > extensions translated. I understand that the C++ compiler used internally > > at Bell Labs bypasses this step. > > > Well heck, the output of ANY (working) compiler is some concrete > representation of the internal parse tree. Anyway, I believe (but may > be wrong here) that the Objective-C compiler also compiles the ordinary > C code in an Objective-C program. It just happens to produce output > which is the same C code. That does not mean that it has not been > compiled (ie. parsed, syntax checked, etc). > > I see that PPI (the vendor of Objective-C) is now on the net. > Any comments from them? The distinction between a compiler and a preprocessor is not crisp enough to argue about. For one thing, the debate is not about the two LANGUAGES, but techniques for IMPLEMENTING the two languages. Both languages have more than one implementation, and many of these do not involve a backend C compiler at all. Before tackling your question, a proviso about the debate itself. I find language debates relatively uninteresting. Each time a new language has appeared over the years (assembler language, Fortran, Pascal, C, Ada), there was a lot of excitement initially, and certainly some improvement in programmer productivity. But the improvement has always turned out to be arithmetic in impact. The geometric improvements needed to bring our productivity in line with that of hardware engineers will not result from better programming languages, but by focusing our attention outside the language. For example, by learning to program by producing and reusing components from large libraries of pre-tested Software-ICs. Yes, these libraries are hard to build, and expensive. But each well-tested, well-documented library component provides a geometrical improvement to the productivity of each of its users, and the improvement is open-ended, unlike the productivity enhancement of features that are hardwired into a new programming language. Accordingly, there is little to be excited by in the new syntactic features of Objective-C, the language. The excitement is entirely in the Software-IC concept itself that the extensions enable, and in the large Software-IC libraries where most of PPI's effort has been focused. Objective-C, the LANGUAGE, is merely C, the LANGUAGE, plus several extensions to provide object-oriented programming techniques to the C programmer's toolkit needed for suppliers and consumers of Software-ICs to collaborate in a loosely coupled fashion. The extensions are parimarily an additional type-name, 'id', analogous to the old C type-names like `char' or `int', and an additional kind of expression, the `message expression', analogous to old C expressions like the addition expression, <expression>+<expression>, or the function-call expression, <expression>(<expression>, ...). Several other extensions provide syntax for defining new classes (Software-ICs) and their methods. The extensions are syntactically minimal, but uncompromising in their support for loosely-coupled development. The philosophical differences between C++ and Objective-C revolve around how strong the coupling should be between suppliers and consumers of code. C++ provides better support for strongly-coupled development than C, (better static binding, strong type checking, etc), while Objective-C retains C's support for strongly-coupled development tasks. Its extensions are entirely to provide tools for supporting loosely-coupled development. Regarding the original topic of the debate, Objective-C language can be, and has been, implemented in many ways. For example, our Objective-C interpreter implements Objective-C language in a fully interactive fashion, without invoking any part of the traditional C tools chain (preprocessor, compiler, assembler, linker, loader, etc), by using traditional language implementation techniques (lexical analysis, parsing, code generation, etc) to perform all of these steps itself. The advantage of this implementation is rapid edit-debug turnaround, and the cost is slower execution speed. By contrast, our Objective-C compiler implements Objective-C language by relying on a backend C compiler for code generation. The frontend performs all of the traditional tasks of any compiler (e.g. lexical analysis, parsing, expression tree building, symbol table management, typing, etc), but it generates a portable representation of the code by generating C source code rather than some non-portable representation like assembly language or machine code. The advantages of generating C code is nearly automatic portability across different machine environments (we don't need to reimplement a machine-dependent code generation pass for every target environment). The advantage of the compiler over the interpreter is execution speed, while the cost is the slow edit-debug turnaround time of traditional C development tools. Luckily, the compiler and interpreter compliment each other. When my code is young and unstable, I process it exclusively with the interpreter to minimize turnaround time. As it begins to mature and stabilize, it pays to process it with the compiler and link the compiled code into the interpreter to make it run faster while serving as substrate for other parts of my system that might still be under development (e.g. as interpreted code). When my system stabilizes and is ready to ship, I merely remove the interpeter and ship only the compiled code. Or if my system is a linkable library of components instead of a fully linked application, I might even chose to provide a demo version of the library as compiled code linked into the interpreter so that our customers can learn the components by trying them out online. Brad Cox Vice President Productivity Products International 75 Glen Road Sandy Hook, CT 06482 (203) 426-1875
franka@mmintl.UUCP (Frank Adams) (10/29/87)
Can we drop comp.lang.misc and comp.lang.smalltalk from the distribution list for this discussion? It really only needs to be in one place, and comp.lang.c++ would seem to be it. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Haead "arences: <ri
franka@mmintl.UUCP (Frank Adams) (11/16/87)
In article <1662@ppi.UUCP> cox@ppi.UUCP (Brad Cox) writes: >For example, >consider the different kinds of problems in building an automobile. >In designing the AutomobileEngine it is appropriate and useful to >state as early as design time that each EngineCylinder can contain >only instances of class Piston, and to have this desicion strictly >enforced (strict type-checking) during the implementation phase. Static >binding is the right tool for this job. By contrast, in designing the >AutomobileTrunk, it is not desirable to make these kinds of decisions >any earlier than when the automobile is put into service. ... >So much for the contribution of dynamic binding. How about dynamic binding >as provided by C++ as opposed to Objective-C? The main problem with Objective-C, in my opinion, is that while it supports both of these extremes, there is in fact a whole spectrum in between; and it provides no support for the intermediate cases. To continue the analogy above, consider the seats of the automobile. One may have bucket seats, bench seats, or something new some designer comes up with tomorrow. So dynamic binding is useful and natural here. However, the seats had better be some kind of seat -- it won't do to put in radios or air conditioners instead. C++ provides exactly the machinery to let you define this. Objective-C forces you to give up type checking entirely for cases where you want any dynamic binding. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
hawley@mas1.UUCP (Ken Hawley) (11/20/87)
>In article <1662@ppi.UUCP> cox@ppi.UUCP (Brad Cox) writes: >>For example, >>consider the different kinds of problems in building an automobile. >> . . . To which Mr. Adams of Multimate International says, in part: > . . . Objective-C >forces you to give up type checking entirely for cases where you want any >dynamic binding. This comment is relevant only if you choose to build you system in a way that makes dynamic binding important, i.e. using extensive sub-classing. If you are building an end user system, you can sub-class to your heart's content. However, if you are building a GENERIC PRODUCT, then there are serious shortcomings to the extensive use of sub-classing. The alternative is to use a small number of generic objects together with (what Cox has called) property lists to configure or "parameterize" those objects for a particular application. Voila! Dynamic binding without the binding! You don't get type checking either, but you have gained something much more valuable: a generic application. To go back to Cox's example: consider the automobile assembly. You could have a wheel object, a vehicle object, an engine object, a trunk object, etc. Or you could have one, "assembly" object which takes on the properties of a wheel, a vehicle, an engine, or a trunk depending upon how it's configured. In the first case, if you change the engine, you must change the class. In the second case, you merely change the property list. Remember why we use object techniques: (1)data hiding, (2)reusability, (3)explicit modelling of physical systems, (4)distributability, (5)scalability. Inheritance is a MEANS, actually only one means, to achieve these objectives in an object environment. It is not an END in itself. -- Kenneth J. Hawley (hawley@mas1) Measurex Automation Systems {...}pyramid!voder!mas1!hawley Cupertino, CA / Detroit, MI {...}codas!mas1!hawley (408)973-1800 (313)271-0333
franka@mmintl.UUCP (Frank Adams) (11/26/87)
In article <980@mas1.UUCP> hawley@mas1.UUCP (Ken Hawley) writes: |If you are building an end user system, you can sub-class to your heart's |content. However, if you are building a GENERIC PRODUCT, then there are |serious shortcomings to the extensive use of sub-classing. I'm afraid I don't see them. Please elucidate. |The alternative is to use a small number of generic objects together with |(what Cox has called) property lists to configure or "parameterize" those |objects for a particular application. Voila! Dynamic binding without the |binding! You don't get type checking either, but you have gained something |much more valuable: a generic application. I don't see what advantage this has over inheritance. It strikes me as a recipe for confusion and disaster. Now, I've been known to be wrong before, but I quite literally do not see any advantages to this approach. |To go back to Cox's example: consider the automobile assembly. You could |have a wheel object, a vehicle object, an engine object, a trunk object, etc. |Or you could have one, "assembly" object which takes on the properties of a |wheel, a vehicle, an engine, or a trunk depending upon how it's configured. |In the first case, if you change the engine, you must change the class. In |the second case, you merely change the property list. I can as easily say: in the first case, you merely change the class. In the second, you must change the property list. Changing the class is not a difficult operation! And I still want type checking. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
roper@chinet.UUCP (Bill Roper-) (12/04/87)
I just found out that we're looking at object-oriented programming languages here at work (specifically Objective-C and C++). Unfortunately, I wasn't reading this newsgroup, and most everything on the topic has expired. Could someone who was reading regularly (and, if I'm real lucky, archived the postings) send me a summary of what's been said? Heck, I'd even take a reference to a good published article. :-) Thanks... -- Bill Roper, ihnp4!chinet!roper
cp@daimi.UUCP (Claus Pedersen) (02/09/88)
We are going to develop a large system in either C++ or Objective-C. We would therefore be thankfull if you are able to help us by answering the following questions. 1) What kind of programming enviroments has been developed for the two languages? We are especially interested in enviroments that supports development of large programs. 2) How are the performance of the two languages when it comes to large programs? Which of them has the best performance? 3) Which libraries has been developed for the languages (does any graphical tools exist)? Please e-mail to: Claus H. Pedersen / cp@daimi.dk (..uunet!mcvax!diku!daimi!cp) Computer Science Department, Aarhus University Ny Munkegade 116, DK-8000 Aarhus C, DENMARK phone: +45 6 12 71 88 / telefax: +45 6 13 99 19 / telex: 64767 aausci dk
dmg@ssc-vax.UUCP (David Geary) (01/18/89)
I'm about to embark on a rather large development effort, along 4 other developers. All of us know C well (I teach it off-hours), and we are interested in using either C++ or Objective-C. I've read "Object-oriented Programming: An Evolutionary Approach" by Brad Cox. The book is mostly about Objective C, so I have a fairly good handle on the capabilities of Objective C. I know next to zip about C++, I'd like to know the differences between C++ and Objective-C. I'd also like some subjective input from someone who has worked with both languages as to their preferences and why. I'm also a little confused about whether C++ is a proper superset of C. From Cox's book: "C++ is particularly interesting given this book's emphasis on Objective-C, because it contrasts what can be accomplished by redefining the programming language itself as opposed to adding object-oriented capabilities to an immutable base language." This implies that C is not a subset of C++, and that C++ is a new language. Later on in the book: "C++ is very nearly a proper superset of C language, with a few modest incompatibilities." What are the few modest imcompatibilities? Any help is greatly appreciated. Thanx... -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ David Geary, Boeing Aerospace, ~ ~ #define Seattle RAIN ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tvillan@hpccc.HP.COM (Tim Villanueva) (01/24/89)
> > I'd like to know the differences between C++ and Objective-C. >I'd also like some subjective input from someone who has worked with both >languages as to their preferences and why. > Please POST any responses to this, or CC them to me. I am in a similar situation, and am very interested in these 2 languages. Tim Villanueva tvillan%hpccc@hplabs
sandra@bear.digital.co.jp (Sandra Ishida) (04/10/90)
Does anyone out there have data regarding the relative merits of C++ vs Objective-C? Speed/ease of development, execution overhead, reliability and maintainability are my main concerns. I'm sorry if the topic's already been discussed, I'm new to the network. Any data would be appreciated. Thanks.
rthomps@utkux1.utk.edu (020R4BMH) (08/03/90)
This subject may have been approached in this group before. However, I am at a Y-Intersection here, I cannot afford to invest in both compilers right now, so I would appreciate anyones input on this subject. MY NEED: To choose an OOP (hybird) for development in Windows and OS/2 related applications. I already know Actor, Smalltalk, and have been reading up on Object/1. I have programmed for about 8-months in the Windows SDK in 'C' and I do not intend to continue to use a procedural approach. I NEED to choose a hybird approach to widen my scope of programming, especially the need for an efficient approach for areas like Numerical Techniques (Matrices, etc...). MY BELIEFS: I believe that C++ might be the better approach because it is a superset of C. Is Objective-C a superset of C? I believe that Objective-C would be more natural to me becuase of my OOPS background. MY QUESTION: Are there any distinct advantages between the two? Specifically, is C++ better in the shorterm becuase it is both widely accepted and it is a superset of C? What are peoples experience using StepStone's compiler with the Windows classes versus Zortech's compiler? I believe that CNS C++/Views is available for both; does anyone have a comparison? Thanks in advance - all interested please reply soon! - Robert D. Thompson