Xref: utzoo comp.lang.c++:11952 comp.object:2633 comp.lang.objective-c:183 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!wuarchive!emory!wrdis01!mips!daver!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.lang.c++,comp.object,comp.lang.objective-c Subject: Re: Static typing, OOP efficiency, and programmer error Message-ID: <27CE9C05.4F64@tct.uucp> Date: 1 Mar 91 18:23:01 GMT References: <27C523A2.2155@tct.uucp> Organization: Teltronics/TCT, Sarasota, FL Lines: 63 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 ,