chip@tct.uucp (Chip Salzenberg) (03/02/91)
According to pcg@cs.aber.ac.uk (Piercarlo Grandi): pcg> 1) Objective C does allow you to declare explicitly the type of objects, pcg> via a cast like notation. chip> Allow, yes, but not require. pcg> Just like C++, in the opposite direction. C++ requires _some_ type information before any member functions (either virtual or non-virtual) can be called. As I understand it, Objective C does not require any type information whatever to send a message. Reasonable people can disagree on the correct alternative between these two. For my part, I prefer the C++ solution. I believe it to be a natural consequence of forest-vs-tree inheritance, which I also prefer. chip> Besides, as far as I know, there is no guarantee that the message chip> set supported by a given class will not expand after the users of chip> that class have already been compiled. pcg> The idea in Objective C is that you resolve statically what you can, and pcg> turn to dynamic overloading for what you cannot. But the Objective C compiler never knows when you have made an error by sending a message that the recipient cannot understand. That error is impossible in a C++ program. pcg> ... [in Objective C, a message] just gets resolved dynamically instead of pcg> statically. In C++ you simply don't have this option in the general case. True. I consider this omission a feature, personally; it keeps me from discovering at run-time that I have requested an impossible operation -- an error the compiler could have detected. (Issues of efficiency of virtual vs. non-virtual C++ member functions have been deleted from the quoted article. If you can't stand the cost of one add and one indirection during function call, you should be writing assembler. ;-)) pcg> Objective C has to use hash tables or caching, hinting, and the like. pcg> [3] Does it make a large difference to the overall runtime? pcg> [3] For most applications, a quite small difference. I can believe it. The cost doesn't bother me that much. After all, were I a real speed freak, I'd still be hacking assember code. pcg> Efficiency advantages that are important for systems programming, but pcg> not for most applications, are C++ support for inline functions and pcg> objects. These are IMNHO far more important than the relative speed of pcg> relatively infrequent dynamic overload resolution. Agreed, though my applications programs just might be noticably slower if inline functions for key objects such as Buffer and String were not available. pcg> I am not very current on Objective C ... Hopefully the new Objective C pcg> book will come out eventually. Neither am I, and I look forward to the same book. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
gwu@nujoizey.tcs.com (George Wu) (03/08/91)
In article <27CE9C05.4F64@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: |> According to pcg@cs.aber.ac.uk (Piercarlo Grandi): |> chip> Besides, as far as I know, there is no guarantee that the message |> chip> set supported by a given class will not expand after the users of |> chip> that class have already been compiled. |> |> pcg> The idea in Objective C is that you resolve statically what you can, and |> pcg> turn to dynamic overloading for what you cannot. |> |> But the Objective C compiler never knows when you have made an error |> by sending a message that the recipient cannot understand. That error |> is impossible in a C++ program. |> |> pcg> ... [in Objective C, a message] just gets resolved dynamically instead of |> pcg> statically. In C++ you simply don't have this option in the general case. |> |> True. I consider this omission a feature, personally; it keeps me |> from discovering at run-time that I have requested an impossible |> operation -- an error the compiler could have detected. I would consider this sort of run-time error checking inadvisable for commercial products, to say nothing of mission critical applications, although I'm sure there are people out there using Objective C and Smalltalk for commercial systems. It simply isn't a good idea for a sold product in customer hands to crash with an error. (Yeah, I've seen commercial systems core dump, too. :-) It's just easier to have high confidence in software which does as much error checking as possible at compile time. Of course, if one just performed exhaustive testing before releasing a product . . . . George ---- George J Wu, Software Engineer | gwu@tcs.com or uunet!tcs!gwu Teknekron Communications Systems, Inc.| (415) 649-3752 2121 Allston Way, Berkeley, CA, 94704 | Quit reading news. Get back to work.
gwu@nujoizey.tcs.com (George Wu) (03/09/91)
-
Please forgive me if this message appears twice. My machine croaked at
precisely the wrong time. I'll ignore the hint, if you don't mind. :-)
In article <27CE9C05.4F64@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes:
|> According to pcg@cs.aber.ac.uk (Piercarlo Grandi):
|>
|> chip> Besides, as far as I know, there is no guarantee that the message
|> chip> set supported by a given class will not expand after the users of
|> chip> that class have already been compiled.
|>
|> pcg> The idea in Objective C is that you resolve statically what you
can, and
|> pcg> turn to dynamic overloading for what you cannot.
|>
|> But the Objective C compiler never knows when you have made an error
|> by sending a message that the recipient cannot understand. That error
|> is impossible in a C++ program.
|>
|> pcg> ... [in Objective C, a message] just gets resolved dynamically
instead of
|> pcg> statically. In C++ you simply don't have this option in the
general case.
|>
|> True. I consider this omission a feature, personally; it keeps me
|> from discovering at run-time that I have requested an impossible
|> operation -- an error the compiler could have detected.
For commercial systems, to say nothing of mission critical
applications, run-time error generation is a drawback. I'm sure there are
poeple out there using Objective-C, Smalltalk, and Lisp to develop
commercial systems, and what's a core dump but a run-time error, but it is
always better to get as much error checking done at the compile stage. The
mere potential for run-time errors implies more testing and less overall
confidence in the stability of an application, to be avoided where possible
for commercially delivered applications.
George
----
George J Wu, Software Engineer | gwu@tcs.com or uunet!tcs!gwu
Teknekron Communications Systems, Inc.| (415) 649-3752
2121 Allston Way, Berkeley, CA, 94704 | Quit reading news. Get back to work.chip@tct.uucp (Chip Salzenberg) (03/16/91)
According to carroll@cis.udel.edu (Mark Carroll): >Most of the time, Objective-C is used in a way which could be trivially >translated into a fully static language like C++. In those cases, Objective-C >COULD catch any of the errors which C++ could catch. The key difference, as I understand it, is that the Objective-C language does not require the programmer to make available to the compiler that information that would make possible a complete check of message vs. object type. >... by using dataflow analysis to bind statically whenever possible, >any of the errors that could be caught statically in C++ could be caught >statically in Objective-C. I think that the above statement is incorrect. The C++ language is incapable of compiling a program that results in an object receiving a message it can't handle. Objective-C, on the other hand, is. Whether a given Objective-C compiler can sometimes, or even usually, notice that error is beside the point. In Objective-C the error is possible; in C++ it isn't. > Static versus dynamic binding is a matter of personal taste. That's an important issue, and one that doesn't get a lot of air time. But it's a significant factor in the early success or failure of any language. >I think that my programs are much more elegant written in a dynamic style ... I am not willing to sacrifice type safety for elegance. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Most of my code is written by myself. That is why so little gets done." -- Herman "HLLs will never fly" Rubin
chip@tct.uucp (Chip Salzenberg) (03/16/91)
According to cox@stpstn.UUCP (Brad Cox): >I'll have the dynamic binding on my ski boots welded to remove any >possibility of run-time errors. ... A fine example of an analogy run amok. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Most of my code is written by myself. That is why so little gets done." -- Herman "HLLs will never fly" Rubin
rkitts@netcom.COM (Rick Kitts) (03/20/91)
There seems to be some lack of "real world" in this conversation. The contention that Objective-C allows for errors at run time is obviously correct, however if someone can point out a language which prevents run time errors I would be very interested to know of it :-). Before you say, "But C++ can't get an error because it can't find a method!", please consider that Objective-C can't get an error because it inserted a copy constructor under your nose which has an incorrect behavior. The point being that each language (perhaps *every* language, but I don't want to generalize) has its own domain of problem areas. You can't look at Objective-C and say it is deficient compared to C++ because of this potential for error. Because if you do, you have to turn right around and say that C++ is deficient compared to (just about every other language in the world) Objective-C because it has the potential to generate an incorrect copy constructor. ---Rick
connolly@livy.cs.umass.edu (Christopher Connolly) (03/20/91)
In article <27E17FD1.7241@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to carroll@cis.udel.edu (Mark Carroll): >>... by using dataflow analysis to bind statically whenever possible, >>any of the errors that could be caught statically in C++ could be caught >>statically in Objective-C. > >I think that the above statement is incorrect. The C++ language is >incapable of compiling a program that results in an object receiving a >message it can't handle. I don't know much about Objective-C, so I can't say anything about Mark Carroll's statement. On the other hand, the AT&T version 2.1 C++ translator will successfully compile this program: ///////////////////////////////////////////////////////////////////// #include <stream.h> struct junk { int foo; virtual int barf() { cout << "Bandaged Knuckles.\n" << flush; return(foo); } }; struct eat_me { int foo; }; main() { junk* fool_me_once; eat_me* fool_me_twice; void* bar; cout << "Let the festivities begin.\n"; fool_me_once = new junk; fool_me_once->foo = 1; fool_me_once->barf(); fool_me_twice = new eat_me; fool_me_twice->foo = 2; bar = (void*) fool_me_twice; fool_me_once = (junk*) bar; fool_me_once->barf(); } ///////////////////////////////////////////////////////////////////// The resulting executable (a.out) prints this: sunbeam% a.out Let the festivities begin. Bandaged Knuckles. Segmentation fault (core dumped) sunbeam% This is a case where an object is "receiving a message it can't handle", the result being a segmentation fault. Nicht wahr? >I am not willing to sacrifice type safety for elegance. I'd like both, with an order of magnitude to go, please. -C. Connolly
carroll@cis.udel.edu (Mark Carroll) (03/21/91)
In article <27E17FD1.7241@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to carroll@cis.udel.edu (Mark Carroll): >>Most of the time, Objective-C is used in a way which could be trivially >>translated into a fully static language like C++. In those cases, Objective-C >>COULD catch any of the errors which C++ could catch. > >The key difference, as I understand it, is that the Objective-C >language does not require the programmer to make available to the >compiler that information that would make possible a complete check of >message vs. object type. > You're not listening to what I said: "Most of the time, Objective-C is used in a way which could be trivially translated... IN THOSE CASES, Obj-C COULD catch any of the errors. If Objective-C is used to do things in the same way in which they would be done in C++, the necessary information to perform error checking is available. It's not explicitly available as in C++ - but a good compiler, by using dataflow, could gather the same information that the C++ compiler has, and could catch any error that the C++ compiler could catch. But note the condition: "If Obj-C is used to do things the same as C++"! >>... by using dataflow analysis to bind statically whenever possible, >>any of the errors that could be caught statically in C++ could be caught >>statically in Objective-C. > >I think that the above statement is incorrect. The C++ language is >incapable of compiling a program that results in an object receiving a >message it can't handle. Objective-C, on the other hand, is. Whether >a given Objective-C compiler can sometimes, or even usually, notice >that error is beside the point. In Objective-C the error is possible; >in C++ it isn't. > The question isn't: is the error possible. Certainly, it's possible to write erroneous code in ANY language. The question is, when is the error going to be caught, and how is it going to be handled? C++ specifies that most errors be caught at compile time. Objective-C doesn't specify when they are caught. Is that a reason to believe that C++ is a "better" language than Objective-C? No. Is that a reason to believe that C++ is a "safer model" that Objective-C? Again, no. Because there is not any safety check possible in the C++ model that could not be performed in the Objective-C model. >> Static versus dynamic binding is a matter of personal taste. > >That's an important issue, and one that doesn't get a lot of air time. >But it's a significant factor in the early success or failure of any >language. > >>I think that my programs are much more elegant written in a dynamic style ... > >I am not willing to sacrifice type safety for elegance. But is that really what's going on? Or are you really just saying that you're willing to sacrifice elegance for compiler simplicity? >Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> <MC> -- ---------------------- Mark Craig Carroll: <MC> ------------------------ ------ U of Del. Grad Student in CIS ------ EE/CIS LabStaff Hacker ------ -- Resident Wierdo @ 105 E Cleveland Ave, Newark DE - carroll@udel.edu -- ---------------------- Shalom Achshav - Peace NOW! ----------------------
chip@tct.uucp (Chip Salzenberg) (03/22/91)
According to rkitts@netcom.COM (Rick Kitts): >Before you say, "But C++ can't get an error because it can't find a method!", >please consider that Objective-C can't get an error because it inserted >a copy constructor under your nose which has an incorrect behavior. That each language has flaws is not contested by anyone here. To say, "So what if my language has problem X? Yours has problem Y!" is poor form at best, unless problems X and Y are somehow connected. Method lookup and copy constructors have nothing to do with each other. Let's concentrate on the subject at hand, shall we? -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre