Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hp-pcd!hplsla!jima From: jima@hplsla.HP.COM ( Jim Adcock) Newsgroups: comp.lang.c++ Subject: Re: method selectors Message-ID: <6590022@hplsla.HP.COM> Date: 3 Mar 88 22:46:22 GMT References: <369@trigraph.UUCP> Organization: HP Lake Stevens, WA Lines: 30 |The problem is largely one of binding time. In c++ lexical binding |occurs very early, in objective-c and even more so in smalltalk, |the lexical binding is postponed until runtime. | |I like c++ quite a lot, but I can't help feeling that more flexibility |in choosing the binding time would be very nice. In general Objective-C binds at the same time a C -- at compile/link time. However, since Objective-C includes a string representation of the names of Objective-C methods [equivalent to C++ messages], the Objective-C programmer can, with some additional programming, arrange to have the method selected be completely determined at run time -- at the cost of doing some additional string searching and hashing. The equivalent C++ technique would be to use a string representation of a virtual function name to find the correct virtual function address in a hash table. Not much harder to do, and has the advantage that you don't have to keep a string representation of EVERY virtual function name. Also the Objective-C concept of an "Object" is equivalent to a C++ concept of a pointer to an "Object", so if you don't want to determine which object a C++ variable refers to until run time, you'll need to make that C++ variable a pointer or a reference. In summary, I have found very little difference between C++ and Objective-C in practical terms on these issues. The most common difficulties in rewriting Objective-C programs in C++ is in Objective-C programmers's occasional use of a C-string as a method selector, and Objective-C's general lack of type checking. Otherwise most Objective-C programming has a one-to-one correspondence with C++ programming techniques, and vice versa.