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.