Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!tut.cis.ohio-state.edu!rutgers!bellcore!texbell!sw1e!uucibg From: uucibg@sw1e.UUCP (3929]) Newsgroups: comp.lang.c++ Subject: Re: objective C Message-ID: <1546@sw1e.UUCP> Date: 1 May 89 13:31:11 GMT References: <2614@ssc-vax.UUCP> <3180@stpstn.UUCP> <15327@gryphon.COM> Reply-To: uucibg@sw1e.UUCP (Brian Gilstrap [5-3929]) Organization: Southwestern Bell Telephone Co Lines: 68 In article <15327@gryphon.COM> sarima@gryphon.COM (Stan Friesen) writes: >In article <3180@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: >>Of course, none of this answered your real question...why highly >>reusable software (Software-ICs is a trademark...it applies STRICTLY to >>Objective-C, by law) is harder in C++ (never impossible...remember I >>used to do this stuff in raw C too). The short answer is that C++ >>relies on static binding and strong type-checking, while reusing code >>involves binding a supplier's code with a consumer's code long after >>the supplier's code has been compiled (and therefore bound to whatever >>types the supplier knew about at the time...which fails to include the >>consumers'). For the longer answer, read the book >>again...closely...and try working the examples in C++. > > This seems to be a common mistake of less intensive C++ programmers. >C++ does not *rely* on static binding, it *permits*, or perhaps *encourages* >it, but definitely not rely! Dynamic binding in trivially available, it is >called "virtual functions". Of course since all "functions/messages" are >"virtual" in ObjC, attempting to code any ObjC class that relies on library >classes in C++ would require writing the associated library using virtual >functions. But I do not see any other problem that would prevent the >example from being done in C++. Admittedly, ObjC is more advanced in its >standard library of predefined classes, but that is its only real advantage >over C++. >-- >Sarima Cardolandion sarima@gryphon.CTS.COM >aka Stanley Friesen rutgers!marque!gryphon!sarima > Sherman Oaks, CA This gives me an opportunity to clear up a question I've had for quite a while. Is it possible to do the following: Joe writes a class called Window and compiles it for a particular workstation/ OS release. The implementation of Window is of arbitrary complexity (e.g. it may involve virtual functions or any other construct allowed by C++). He then sends the compiled file plus a '.h' to Fred. Fred uses the .h to write a class derived from Window, compiles it, and links it together with the object file for Window (along with other stuff) to produce a working program. Will this work? If so, good deal. If not, then I see a major drawback in C++'s reusability. Needless to say, no software house is going to want to have to send out sources. Now, I'm not claiming that this is a killing blow to C++, just that it damages one of the supposed advantages of object-oriented programming: reuse of code. I realize that there are some talented people out there working on C++ classes that they plan to put into the public domain (or copyleft or whatever). However, that's a very catch-as-catch-can sort of thing. If someone writes a class that you need, you're in luck, but otherwise.... If C++ currently provides separate compilation, then we might, just might, someday be able to produce 'off the shelf' software classes at a significantly greater granularity, thus allowing us to leverage the work of other people in the software world to a much greater degree. Will this ever happen? I don't know. But it *can't* happen until OO languages support separate compilation. I hope C++ handles this (or that it soon will). By the way, I suspect that the answer to the question is no, at least in the general case. For example, how to you handle inline functions of a class? Is there a switch to tell the compiler to generate a standard function for such an inline and treat it as non-inline if only the '.o' is about? Please clear up my confusion and comment (non-flameingly). Thanks, Brian R. Gilstrap Southwestern Bell Telephone One Bell Center Rm 17-G-4 ...!ames!killer!texbell!sw1e!uucibg St. Louis, MO 63101 ...!bellcore!texbell!sw1e!uucibg (314) 235-3929 ...!uunet!swbatl!sw1e!uucibg #include