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
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.
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."
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
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 <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
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
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