grogers@m.cs.uiuc.edu (04/06/89)
Can someone please tell me the name and phone number for the company
that sells Objective-C. I know I've seen an advertisement for this,
but, like always, I can't find it when I need it.
I'm also interested in comparisons of Obj-C and C++. If you know of
any, I'd like a reference. I not asking for yet another religious debate
in the notesfile, so please don't start one.
Greg Rogers
UUCP: {pur-ee,convex,inhp4}!uiucdcs!grogers
ARPA: grogers@a.cs.uiuc.edu
CSNET: grogers%uiuc@csnet-relaywiener@stout.UCAR.EDU (Gerry Wiener) (04/07/89)
Stepstone is the name of the company that makes objective c. Phone number is (203)426-1875. Brad Cox has written a book on object oriented programming which contains information on objective c but is not really a complete introduction to the language (I believe the title is Object Oriented Programming or something like that). There are three books available on c++ that I know of. One is by Stroustrup (The c++ programming language), another by John Berry (The waite group's c++ programming) and a third by Richard Wiener and some other author (I forget the title). The one by John Berry is an easy introduction c++ which makes the language approachable. I know of no references that do a comprehensive comparison of the languages although they are both discussed in the book by Cox and in a book on Eiffel by Bertrand Meyer. I don't have a lot of experience in c++ or objective c but I have been playing around with both languages for a while. It seems that the syntax of c++ is quite a bit closer to c than that of objective c and I'm finding it more natural to understand. ----- Gerry Wiener Email:gerry@toadwar.ucar.edu
jima@hplsla.HP.COM (Jim Adcock) (04/14/89)
Never one to resist flogging a dead horse -- I couldn't help but notice [a different] Wiener wrote a Nov JOOP article on the "latest and greatest" "Stepstone" ObjC 4.0 compiler. So I couldn't help comparing the published numbers to a simple "Integer" class I wrote in C++: [Time to perform 400000 "Int Class" assignment loops] Richard Wiener / Sun 3 workstation / ObjC 4.0 dynamic binding elapsed time for static Ints: 8.340 seconds elapsed time for dynamic Ints: 11.820 seconds Richard Wiener / Sun 3 workstation / ObjC 4.0 static binding elapsed time for static Ints: 4.140 seconds elapsed time for dynamic Ints: 11.820 seconds Jim Adcock / HP 320 workstation / ATT C++ with Gnu CC backend elapsed time for static Ints: 0.552 seconds elapsed time for dynamic Ints: 0.564 seconds -- While I don't know the relative speeds of a Sun 3 workstation and an HP 320, I believe they are quite similar. It still seems safe to say that C++ remains many, many times faster than ObjC 4.0. [In C++ most of the assignment/loop time is taken by the loop increment and test, and not by the actual Int class assignment]
jmd@swbatl.UUCP (03) (04/14/89)
In article <6590095@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: > >Never one to resist flogging a dead horse -- I couldn't >help but notice [a different] Wiener wrote a Nov JOOP article >on the "latest and greatest" "Stepstone" ObjC 4.0 compiler. >So I couldn't help comparing the published numbers to >a simple "Integer" class I wrote in C++: It escapes me how people love to compare apples and oranges. Besides the fact that the comparisons are on two different hardware platforms, the greatly increased throughput might be attributed to the use to the GNU 'C' compiler vs. the Sun 'C' compiler. REALLY don't you think a more logical approach should be taken to these political statements based on emotion. > >[Time to perform 400000 "Int Class" assignment loops] > >Richard Wiener / Sun 3 workstation / ObjC 4.0 dynamic binding > >elapsed time for static Ints: 8.340 seconds >elapsed time for dynamic Ints: 11.820 seconds > >Richard Wiener / Sun 3 workstation / ObjC 4.0 static binding > >elapsed time for static Ints: 4.140 seconds >elapsed time for dynamic Ints: 11.820 seconds > >Jim Adcock / HP 320 workstation / ATT C++ with Gnu CC backend > >elapsed time for static Ints: 0.552 seconds >elapsed time for dynamic Ints: 0.564 seconds > >-- While I don't know the relative speeds of a Sun 3 workstation >and an HP 320, I believe they are quite similar. > >It still seems safe to say that C++ remains many, many times >faster than ObjC 4.0. > >[In C++ most of the assignment/loop time is taken by the loop >increment and test, and not by the actual Int class assignment] -- James M Doherty - SWBT - Advanced Technology Planning One Bell Center Room 11-Y-03 St. Louis, Mo. 63101 UUCP: { pyramid, ihnp4, bellcore }...!swbatl!jmd PHON: 314-235-0804 FAX: 314-235-0727
loo@mister-curious.sw.mcc.com (Joel Loo) (04/14/89)
In article <6590095@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >So I couldn't help comparing the published numbers to >a simple "Integer" class I wrote in C++: > > [ ... comparison of C++ and Obj-C ... ] > >It still seems safe to say that C++ remains many, many times >faster than ObjC 4.0. This is not a fair comparison. You might as well compare C with Lisp and publish similar figures. Programs in C++ are compiled into runnable codes similar to compiled codes of other compiler languages, most of its objectiveness is lost after compilation. Objective-C retains its objectiveness even after compilation. This implies more runtime functionalities in Obj-C and thus 'poorer' performance. BTW is there any Obj-C newsgroup or is there anybody interested in Obj-C at all? It scares me to see the whole world going for C++ when I tested both and voted for Obj-C. (I am wandering whether my judgement was wrong.) (No flame please, tell my mistakes gently) ------------------- Joel Peing-Ling Loo Voice: 512-338-3680 _ _ Email: loo@mcc.com MCC (=E) .o|o( v )+-H- o There is a 3500 West Balcones Centre Drive TO|O \ / | U | right and a Austin, TX 78759 % | V ---/ \ wrong you know? [ Disclaimer: The above article/signature reflects only my own opinion; my employer has nothing to do with it. ]
uucibg@sw1e.UUCP (3929]) (04/15/89)
In article <2240@mister-curious.sw.mcc.com> loo@mister-curious.sw.mcc.com (Joel Loo) writes: > >This is not a fair comparison. You might as well compare C with Lisp and >publish similar figures. Programs in C++ are compiled into runnable codes >similar to compiled codes of other compiler languages, most of its >objectiveness is lost after compilation. >Objective-C retains its objectiveness even after compilation. This >implies more runtime functionalities in Obj-C and thus 'poorer' performance. > >BTW is there any Obj-C newsgroup or is there anybody interested in Obj-C >at all? It scares me to see the whole world going for C++ when I tested >both and voted for Obj-C. (I am wandering whether my judgement was wrong.) It scares me too. I'm quite interested in both C++ and Objective-C (as well as several other less well-known languages). I find Objective-C presents some major advantages (to me) over C++ in all but the most speed-demanding of problems. I don't think C++ is a bad language, I just think it addresses a different set of problems than Objective-C (just as Objective-C addresses a different set of problems than Smalltalk, etc.). We can get into religious wars about which class of problems is more important, but I think that issue is really a matter of each individual's interest (or their company's interest :-) By the way, has there been a recent vote on a "comp.lang.oop" ?? If so, oh well. If not, how does one go about a 'call for votes' and then (if things turn out positive) how does one go about getting such a news group set up? >Joel Peing-Ling Loo Voice: 512-338-3680 _ _ Email: loo@mcc.com 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 #include <std_disclaimers.h>
jmd@swbatl.UUCP (03) (04/17/89)
In article <2240@mister-curious.sw.mcc.com> loo@mister-curious.sw.mcc.com (Joel Loo) writes: >In article <6590095@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >>So I couldn't help comparing the published numbers to >>a simple "Integer" class I wrote in C++: >> >> [ ... comparison of C++ and Obj-C ... ] >> >>It still seems safe to say that C++ remains many, many times >>faster than ObjC 4.0. > >This is not a fair comparison. You might as well compare C with Lisp and >publish similar figures. Programs in C++ are compiled into runnable codes >similar to compiled codes of other compiler languages, most of its >objectiveness is lost after compilation. >Objective-C retains its objectiveness even after compilation. This >implies more runtime functionalities in Obj-C and thus 'poorer' performance. > >BTW is there any Obj-C newsgroup or is there anybody interested in Obj-C >at all? It scares me to see the whole world going for C++ when I tested >both and voted for Obj-C. (I am wandering whether my judgement was wrong.) Yes, there are lots of major players in the market place using Objective 'C' including the following. 1. Southwestern Bell Corporation 2. IBM ( signed world wide liscense) 3. NeXT computing (Steve Jobs new box) 4. Erickson Switch (doing real time in Obj 'C') 5. U. S. West Advanced Technology. This list is by no means all inclusive, but does give an example of some of the vendors I am familiar with. BTW I am interested in OBJ 'C' news group. > >(No flame please, tell my mistakes gently) >------------------- >Joel Peing-Ling Loo Voice: 512-338-3680 _ _ Email: loo@mcc.com >MCC (=E) .o|o( v )+-H- o There is a >3500 West Balcones Centre Drive TO|O \ / | U | right and a >Austin, TX 78759 % | V ---/ \ wrong you know? > >[ Disclaimer: The above article/signature reflects only my own opinion; >my employer has nothing to do with it. ] -- James M Doherty - SWBT - Advanced Technology Planning One Bell Center Room 11-Y-03 St. Louis, Mo. 63101 UUCP: { pyramid, ihnp4, bellcore }...!swbatl!jmd PHON: 314-235-0804 FAX: 314-235-0727
jima@hplsla.HP.COM (Jim Adcock) (04/18/89)
I stand by my original posting. This is the best comparison I can give at this time on the relative speed of C++ and Objective-C. I stated the ground rules for my comparison, and I have no affiliation to either language, other than as a user [abuser] of both. I believe this is fair. When you're looking at a 10X speed differential, who cares if the answer is really 7.5X or 15X? I have deep-sixed ObjC after programming it for a couple years in favor of C++. ObjC code commanly came out 10-100X slower than a similar approach in C or C++, and code sizes several times larger. After extensive hacking, destroying the "Objective-ness" of our approach, we could maybe get that down to a 2X-5X range. To me, C++ is object-oriented, and ObjC isn't. You claim the opposite. To you only the slow approach of ObjC is "object oriented." To me only the fast, typed approach of C++ is object oriented. To me "object oriented" is a characteristic of what I, the coder writes, and can afford to write. It is not a characteristic of the machine code a compiler [interpreter?] emits. Sorry if you feel left behind. Maybe it is time for an ObjC notesgroup, if only so C++ users can leave this debate behind them?
selden@hpspkla.HP.COM (Jon L. Selden) (04/18/89)
>Yes, there are lots of major players in the market place using Objective 'C' >including the following. > 1. Southwestern Bell Corporation > 2. IBM ( signed world wide liscense) > 3. NeXT computing (Steve Jobs new box) > 4. Erickson Switch (doing real time in Obj 'C') > 5. U. S. West Advanced Technology. > This list is by no means all inclusive, but does give an example >of some of the vendors I am familiar with. BTW I am interested in OBJ 'C' >news group. > >James M Doherty - SWBT - Advanced Technology Planning ---------- Just for the record... Add Hewlett-Packard to the list. Despite a few rather loud contrary voices, Objective-C is being used very successfully in some areas of the company. One particular group had a bad experience with it when they misapplied it and then blamed the language. Others have learned from these mistakes. It seemed unfair not to at least mention the HP success stories along with the horror stories found in this notestring.
cox@stpstn.UUCP (Brad Cox) (04/23/89)
In article <2614@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes: > I, as I've posted previously, am interested in >comparisons between C++ and other OO languages. Could >you please provide some substance behind the argument >that C++ is OO and ObjC is not? > > I've read a great deal of Brad Cox's book "Object Oriented Programming, >An Evolutionary Approach". In the book, Brad talks at some length >about C++, and how it implements OOP, and he *seems* to imply >that building software IC's is easily done in ObjC, but either >not possible, or difficult to do in C++. Anybody have any light >to shed on this? Brad are you there?? Sorry I'm late in responding to your article. I monitor this network very irregularly these days. Although I'm gratified at the recent surge of interest in OO, I find that I am unable to defend any sharply-defined boundary to this term, apart from the precisely-stated but arbitrarily-chosen ones. OO is a loosely-defined adjective, exactly like other adjectives that all of us use daily ('big' or 'high-level' or 'good'), without obsessive worrying about where gray shades into black or white. I find a number of such such arbitrarily-chosen definitions are useful depending on the situation at hand. For example, In my first book, I used an obsessively narrow one by merely defining terms like 'object' and 'message' directly in terms of a specific programming language, and thereby excluding every other claimant to the OO title, not only Ada and C++, but also even newer implementations of the Objective-C language such as the Objective-C interpreter. However we can also obtain valuable insights by holding our obsession with technical precision in check (just as we do with other adjectives like 'big') and searching for commonalities between EVERY claimant to the term. What does Objective-C and C++ and Ada and MacDraw and MetaphorGraphics and Fabrik and OODesign and OODatabases and OOUserInterfaces and OOWhatEver all share in common? The commonality that I see there is that all of these approaches share in the belief that the software domain, which is really a hybrid between the concrete world of tangible THINGS and the abstract world of intangible IDEAS, can be understood more readily by looking at it first from the perspective of the concrete world of tangible things; i.e. OBJECTS, and then treating the influences from its intangible heritage as second-order perturbations. Notice that this definition brings all kinds of strange creatures inside the boundary (all of Software Engineering', for example, because of their interest in applying engineering principles that apply to tangible things to this hybrid stuff, software). However this broader definition does exclude major branches of our community as well; that segment that prefers to view software primarily as IDEAS and secondarily as THINGS. For example it excludes most of what I think of as computer science; those who conconcentrate on algorithms as opposed to programs, and particularly those (CAR Hoare comes quickly to mind) who prefer to treat software as if it were a mathematical entity first and an engineered object second. So to boil all of this down to brass tacks, I don't feel that it is useful to say any given programming language is OO or not, because any boundary is arbitrary. I used C as an OO language during most of my career, and developed Objective-C to automate things that were too hard to do (and to teach to others) that I'd long done by hand. 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++.
uucibg@sw1e.UUCP (3929]) (04/24/89)
In article <820@ethz.UUCP> marti@ethz.UUCP (Robert Marti) writes: >In article <2240@mister-curious.sw.mcc.com>, loo@mister-curious.sw.mcc.com >(Joel Loo) writes on a comparative benchmark between C++ and Objective-C >presented by Jim Adcock: >> This is not a fair comparison. >Why not? If two programs accomplish the same task, surly this is a >fair comparison?! It all depends on what you're trying to measure. If you want to conclude that language A is better than language B, you'd better be willing to tack on "for the classe of problems meeting criterion: 1) .... 2) ....". Otherwise you're just revealing religious attitudes about languages. >> You might as well compare C with Lisp and publish similar figures. >Indeed. So what? I have compared a Modula-2 with a Lisp implementation >of an application which deals mostly with symbols (in the sense of Lisp) >and found that the Modula-2 implementation was faster than compiled Lisp >by a factor of at least 10. I can certainly believe this. Now, how easy would it be to enhance the Modula-2 version versus the Lisp version? Also, do you really feel that you have an extensive knowledge of the efficiency considerations for both languages? Did you tackle a problem truly well suited to only one of the languages? How much time did it take to write each version (and did you write one version first and therefore have a "leg up" on the second implementation?)? >> Programs in C++ are compiled into runnable codes similar to compiled >> codes of other compiler languages, most of its objectiveness is lost >> after compilation. >Again, so what? Lisp and Smalltalk-80 can be (and often are) compiled >into "codes similar to compiled codes of other compiler languages". >This is an implementation detail. C++ or C might just as well be >interpreted, but that won't make them any more object-oriented. "So what?" depends upon your needs. C++ loses some of the flexibility that Smalltalk-like languages keep (e.g sending an arbitrary message to an arbitrary object; I won't get into advantages/disadvantages here). Similarly, I understand that there Lisp OO implementations that give you runtime multiple inheritance. The question isn't "Which is better?" in my mind, it's "Which is better for the job at hand?", which can be a much more difficult question if you begin to worry about things like: 1) Who's going to use the thing? 2) Who's going to maintain/enhance the thing? (perhaps not everyone will be as skilled a programmer as you. This can be a real shocker when you are suddenly kept in the same job because you become 'indespensible'. If you want to advance in the workplace, you have to write for the least common denominator if you want to be free to go elsewhere within a company. Very bad for code sophistication but... but I digress) 3) How long do they (the powers that be) expect the thing to be needed? 4) How long do you think the thing will *really* hang around :-). 5) How quickly must modifications be available? 6) How soon must it be initially available? Etc.... >(I hope you don't consider this a flame :-) No. But remember that things get very complicated outside of the actual code development. >-- >Robert Marti Phone: +41 1 256 52 36 >Institut fur Informationssysteme >ETH-Zentrum CSNET/ARPA: marti%inf.ethz.ch@relay.cs.net >CH-8092 Zurich, Switzerland UUCP: ...uunet!mcvax!ethz!marti 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 <std_disclaimers.h>
jima@hplsla.HP.COM (Jim Adcock) (04/25/89)
> I don't understand this at all. Why do you > claim that ObjC is not OO? Maybe it's slower than C++, > but that doesn't eliminate it from the realm of object-oriented > languages. To me, a language is still not OO if it "supports" OO but at such a high cost that real world programmers cannot afford to use OOP style "all the time." Examples of the kind of code you see people writing if a language does not support OOP at a reasonable cost include: * Code that regularly violates the encapsulation of objects by accessing its instance variables directly rather than thru access functions. * Code that relies heavily on cpp macros to hack at the underlying implementation of objects. * Code that relies heavily on type coercions, with hopeful expectations of portability across a variety of machines. * The base language is constantly growing, with new fundamental features being added to it, as more and more people discover that they cannot get what they need to get done in a reasonable execution time, based on the prior rev. of the language's feature set. * Foundation classes that make use of all kinds of hacks to try and get reasonable speed out of the language -- if the language is not suitable for the implementors of the language to write in -- then how can it be suitable for other serious users ??? * Division of the users of a language into two camps: 1) we, the full time, professional writers of foundation classes that run fast, but are indecipherable, [and work only in ideal circumstances] and 2) you, the user of these foundation classes who are expected to write half-fast programs based on our fast, hack, foundation classes -- which may or may not work in your actual usage.
uucibg@sw1e.UUCP (3929]) (04/25/89)
In article <6590106@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >> I don't understand this at all. Why do you >> claim that ObjC is not OO? Maybe it's slower than C++, >> but that doesn't eliminate it from the realm of object-oriented >> languages. > >To me, a language is still not OO if it "supports" OO but at >such a high cost that real world programmers cannot afford >to use OOP style "all the time." Real world programmers *DOING WHAT*???? What class of problems are you aiming at? >Examples of the kind of code you see people writing if a language >does not support OOP at a reasonable cost include: >* Code that regularly violates the encapsulation of objects by accessing >its instance variables directly rather than thru access functions. You must mean things like friend functions, eh? :-) >* Code that relies heavily on cpp macros to hack at the underlying >implementation of objects. Like all the current hacks in C++ (like the various parameterized types hacks <*not* the proposed approach Stroustrup described> and such)? >* Code that relies heavily on type coercions, with hopeful expectations >of portability across a variety of machines. Could you please explain a bit more? I'm not sure I see what you're getting at here. >* The base language is constantly growing, with new fundamental features >being added to it, as more and more people discover that they cannot >get what they need to get done in a reasonable execution time, based >on the prior rev. of the language's feature set. Like the current rough and tumble which is occuring in the C++ world? Note that there have been few changes to Objective-C. >* Foundation classes that make use of all kinds of hacks to try and >get reasonable speed out of the language -- if the language is not >suitable for the implementors of the language to write in -- then >how can it be suitable for other serious users ??? I can't speak from experience here. But I've seen the source for the foundation classes in Objective-C and they certainly don't appear to be hacks to me (though one man's hack is another man's elegant solution). >* Division of the users of a language into two camps: 1) we, the >full time, professional writers of foundation classes that run >fast, but are indecipherable, [and work only in ideal circumstances] >and 2) you, the user of these foundation classes who are expected >to write half-fast programs based on our fast, hack, foundation >classes -- which may or may not work in your actual usage. Again, please expand upon this. Show me what you mean, give me examples or at least explanations. I'm still evaluating OOP languages, and haven't passed judgement on any of them yet. However, several of your arguments which I assume are directed against Objective-C seem to incrminate C++ instead. Just a final note: I'm not convinced that Objective-C can't be used "all the time" in object-oriented mode. I'll wait to see some real benchmarks on programs which "seem" like they ought to be equally solvable in either language A or language B (in this case Objective-C and C++, though I'd like to see other benchmarks performed). 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 <std_disclaimers.h>
croot@lynpac.oz (Admin) (04/26/89)
In article <6590099@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: > ... >To me, C++ is object-oriented, and ObjC isn't. > ... From my understanding of Obj-C (from reading Brad Cox's "Object Oriented Programming"), there is no reason you can't add the [] messages to C++, getting Objective-C++. Then you have the best (and worst) of both worlds. [p.s. IMHO Obj-C is more like Smalltalk so "objected-oriented" but that is by-the-by] ... cheers, matt. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "life? don't talk to me about life!" Matt Atterbury. :-) :-( :-) :-( "klaatu barada nikto" Lynwood Pacific, Sydney, Australia. :-( :-) :-( :-) matt@lynpac.oz.au (Europe/Internet) || uunet!munnari!lynpac.oz.au!matt (UUCP)
jmd@swbatl.UUCP (03) (04/26/89)
In article <820@ethz.UUCP> marti@ethz.UUCP (Robert Marti) writes: >(Joel Loo) writes on a comparative benchmark between C++ and Objective-C >presented by Jim Adcock: >> This is not a fair comparison. >Why not? If two programs accomplish the same task, surly this is a >fair comparison?! > >> You might as well compare C with Lisp and publish similar figures. >Indeed. So what? I have compared a Modula-2 with a Lisp implementation >of an application which deals mostly with symbols (in the sense of Lisp) >and found that the Modula-2 implementation was faster than compiled Lisp >by a factor of at least 10. Robert, the two languages in question are both pre-processor's to the 'C' compiler, since Jim used two differant back end compilers and two differant hardware platforms it simply means there are to many unknown factors. I think anyone would be willing to accept a comparison if there were fewer unknowns, Jim's analysis (or posting) is incomplete. Upon a closer look at the two Languages in questions will reveal that just as in all of computing, sometimes in order to obtain certain features there may be a flexability/performance issue, therefor these types of comparisons don't hold much weight unless they are done at the individual application level. I have both products in house, and our research has shown that these type of comparisons are difficult. The idea that fast makes best is true in some applications, but not all. Sometimes ease of Maintenance, portability, knowledge base of existing staff, deadlines, flexabilty, runtime platforms etc... also play a part in the decision making process. This is not a slam to anyone or either language, I thought it apropriate to share some of our experience in this matter. -- James M Doherty - SWBT - Advanced Technology Planning One Bell Center Room 11-Y-03 St. Louis, Mo. 63101 UUCP: { pyramid, ihnp4, bellcore }...!swbatl!jmd PHON: 314-235-0804 FAX: 314-235-0727 -- James M Doherty - SWBT - Advanced Technology Planning One Bell Center Room 11-Y-03 St. Louis, Mo. 63101 UUCP: { pyramid, ihnp4, bellcore }...!swbatl!jmd PHON: 314-235-0804 FAX: 314-235-0727
sarima@gryphon.COM (Stan Friesen) (05/01/89)
In article <3180@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: > >Sorry I'm late in responding to your article. I monitor this network >very irregularly these days. > DITTO >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
uucibg@sw1e.UUCP (3929]) (05/01/89)
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 <std_disclaimers.h>
cox@stpstn.UUCP (Brad Cox) (05/03/89)
In article <15327@gryphon.COM> sarima@gryphon.COM (Stan Friesen) writes: >In article <3180@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: >> >>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++. When I initially designed Objective-C, my first thought was to make its binding mechanism work like C++'s virtual functions; e.g. so that the sending site knows and enforces the type of the receiving site at compile time, but with a dynamic dispatch (ala C++'s virtual function dispatch via the VTBL) to allow the receiving site to have siblings. I rejected this approach in favor of Smalltalk's binding style, in which the compiler does not know or enforce any restriction on the type of the receiving site, for the following reason. At least as type or inheritance is defined in programming languages, and ignoring for now other meanings that might be appropriate in as-yet-uninvented specification languages, the type/inheritance hierarchy is an implementation detail...that is, the business of the supplier who implemented the receiving site. If the sending site is aware of and exploits any information about the receiving site's type, a loss in flexibility results. Example: Programmer A is building a MailBox class, which must be able to mail any kind of office object (whether existing now or in the future). He chooses to have MailBox inherit functionality from Collection, which inherits from Object. Programmer B is building an Envelope class, which like MailBox must be able to contain any number of any kind of office Form. He chooses to have Envelope inherit collection functionality from Collection. Programmer C is building a family of Form classes. For his own good and sufficient reasons, he chooses not to inherit functionality from Collection, but instead defiles an abstract Form class with separate subclasses for Memo, BusinessLetter, etc. Programming languages that expect entities that must exhibit the same external interface, such as the common interface that mailable entities (Envelope and Memo) must provide to the MailBox, have trouble with this. Reusability is so important that I was unwilling to compromise it in any fashion, i.e. by making the binding mechanism aware of how a reusable component was implemented (its type hierarchy). Although we have since added C++-style 'dynamic' binding to Objective-C as an option (in order to provide compile-time type-checking), our documents describe it as 'static' binding to indicate that the compiler is aware of the receiving element's type at compile time, and is therefore making a flexibility tradeoff.
tuck@luther.cs.unc.edu (Russ Tuck) (05/03/89)
In article <1546@sw1e.UUCP> uucibg@sw1e.UUCP (Brian Gilstrap [5-3929]) writes: >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? Of course! C++ is a superset of C, so if C can do it, so can C++. This includes separate compilation. (There are a few minor syntactic differences that make C++ not a precise C superset, but it's rare to need to worry about them.) >... how to you handle inline functions of a class? The source to inline functions is in the .h file. (Since inline functions are only useful if very small, typically one-liners or even a single variable reference, I don't think this will bother vendors of binary-only libraries.) Russ Tuck internet: tuck@cs.unc.edu Computer Science Dept., Sitterson Hall csnet: tuck@unc University of North Carolina uucp: ...!mcnc!unc!tuck Chapel Hill, NC 27599-3175, USA Phone: (919) 962-1755 or 962-1932
mat@mole-end.UUCP (Mark A Terribile) (05/04/89)
> >>... 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') ... Not so. In general, something invoked through a calling sequence doesn't have to know the name of the thing that invokes it. If it is to use some resources that are passed to it, it has to know what they are ... but it can present an interface (a class) to be filled in and passed to it so that the resources are presented on the invokee's own terms. There's really no magic. > >C++ does not *rely* on static binding, it *permits*, [it] ... Dynamic > >binding ... is called "virtual functions". ... > 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 ... Window is of arbitrary > complexity . He then sends the compiled file plus a '.h' to Fred. > Fred uses the .h to write a class derived from Window, and links it ... > with the object file for Window ... to produce a working program. > Will this work? ... no software house is going to want to have to send out > sources. ... I hope C++ handles this (or that it soon will). > By the way, I suspect that the answer to the question is no, ... The answer is most definitely YES. The class declaration contains all that you need to know to compile a ``server'' or ``client.'' (Obviously, you must be using the same version--or a compatible version--of the compiler.) > 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? Limitation--the inline must be visible to all instances which call it, which means that you have to put it in the .h . It's not worth making inline unless it's either very small to begin with or it helps the interface. As an almost canonical example of the latter, consider: class WhizzBang { friend ostream& operator<< ( ostream& o, const Whizzbang& w ) { return w.put( o ); }; . . . private: ostream& put( ostream& ); . . . }; It's unlikely that inlines which look like this would give any great amount away. You are right; it's possible that a few inlines might NOT get written to avoid disclosing source code. On the other hand, look at the C standard IO headers; the getc() and putc() macros give away some details of how the buffering is done. For really critical software, non-inline versions can be provided, with inline-containing headers available under ``we hold your firstborn while you program'' type licenses for people who need the last ounce of speed. -- (This man's opinions are his own.) From mole-end Mark Terribile
archiel@mntgfx.mentor.com (Archie Lachner) (05/05/89)
From article <1546@sw1e.UUCP>, by uucibg@sw1e.UUCP (3929]): > 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. ... Yes, this absolutely works. Stroustrup's book mentions this explicitly, and it definitely works in practice in every version of C++ ever released. Functions declared virtual in the base class Window will be replaced by the corresponding functions in the derived class (assuming they exist). This will be true even for function calls through pointers to Window objects in the precompiled code if these pointers point to objects of the derived class (they are passed to the precompiled code, for example). Those making statements to the contrary are perhaps not well informed about C++. -- Archie Lachner Mentor Graphics Corporation Beaverton, Oregon ...!{decwrl,sequent,tessi}!mntgfx!archiel
archiel@mntgfx.mentor.com (Archie Lachner) (05/05/89)
From article <3197@stpstn.UUCP>, by cox@stpstn.UUCP (Brad Cox): > In article <15327@gryphon.COM> sarima@gryphon.COM (Stan Friesen) writes: >>In article <3180@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: >>> >>>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++. > > When I initially designed Objective-C, my first thought was to make its binding > mechanism work like C++'s virtual functions; e.g. so that the sending site > knows and enforces the type of the receiving site at compile time, but with > a dynamic dispatch (ala C++'s virtual function dispatch via the VTBL) to > allow the receiving site to have siblings. > > I rejected this approach in favor of Smalltalk's binding style, in which the > compiler does not know or enforce any restriction on the type of the receiving > site, for the following reason. ... So C++ does have the ability to reuse code by binding a supplier's code with a consumer's code long after the the suppliers code has been compiled. It just does so in a type-safe manner (all of the consumer's types must be the same as the supplier's or derived from them). The supplier's code can then deal with the consumer's types, and in a constrained but safe manner. Your original posting did not indicate this, but quite the contrary lead some people to believe otherwise. You're right. This is different than Small Talk and Objective C. Whether the Small-Talk approach is "better" is debatable. -- Archie Lachner Mentor Graphics Corporation Beaverton, Oregon ...!{decwrl,sequent,tessi}!mntgfx!archiel
uucibg@sw1e.UUCP (3929]) (05/05/89)
In article <162@mole-end.UUCP> mat@mole-end.UUCP (Mark A Terribile) writes: [ This, by the way, was written by Brad Cox as I recall ] >> >>... 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') ... >Not so. In general, something invoked through a calling sequence doesn't have >to know the name of the thing that invokes it. If it is to use some resources >that are passed to it, it has to know what they are ... but it can present an >interface (a class) to be filled in and passed to it so that the resources are >presented on the invokee's own terms. > >There's really no magic. Ummm, I think you got that backwards. Then again I could be brain-fried (I've been working a lot of long days and programming at home into the wee hours). The terminology used in Brad's description can be rather confusing. Let me try again and see (1) if I can describe it well and (2) just how much I can get flamed by the c++ true-believers :-). Suppose you're provided with class 'sprocket' which someone else wrote. Then class 'sprocket' would be a service supplier to other classes which you write. A class which you write which makes use of 'sprocket' would naturally be a client of 'sprocket'. Now, lets look at where strong typing restricts things and also improve type-checking (you can decide which is more important, since I've been heavily flamed already). If class 'sprocket' takes arguments, then it must decide upon the types of the arguments that it takes. Assume that 'sprocket' takes at least one object as an argument. C++ requires that you provide a type for that argument in the form of a formal parameter in the .h and .c files. This restricts you to a member of that class or one of its sub-classes (nothing new here). But lets look at a pretty generic member function (method) like 'print' or 'display'. You could easily expect to create classes not derived from the same superclass and have them incorporate a 'print' method (or 'display' or whatever). Yet C++ requires you to make a choice when writing the supplier as to what classes are valid objects (at least as far as 'sprocket' is concerned). This means that the person writing the code for the supplier must decide a priori what tasks 'sprocket' might be usefull in solving. But the whole point of writing suppliers it to avoid making decisions about what kinds of problems can be solved with code for 'sprocket' and instead let the client programmer look at available classes and decide what to use. It seems extremely painful to coerce the inheritance tree to try to avoid these kinds of situations. Furthermore, the 'precompiled classes' scenario prevents this option anyway since you can't control the inheritance tree of the precompiled classes you (theoretically) buy from some software vendor. This means (as Brad pointed out above) that I can't pass any instances of my gee-whiz 'super_cog' class to a 'sprocket' even though my 'super_cog' has a 'print' member function (method). This severely limits the reusability of the code for 'sprocket'. I don't have enough experience with multiple-inheritance to comment on its ability to solve this problem (at least I perceive it as a problem). Anyone care to comment? Now, before you get out your flame-throwers, let me reiterate that I realize that there are advantages to OO other than reusability. In particular, encapsulation helps tremendously with debugging, correctness, and I'm sure there are others I've missed. However, *IMHO*, reusability provides the greatest potential benefits in the long run if we can develop techniques to support it. To me, OO should be one of these techniques. However, it seems to me that C++ lops off some (many?) of the possibilites through its strong typing of objects. Okay, maybe the strong typing of objects helps in other ways (I'm not convinced of that yet); maybe multiple-inheritance will help change fix the problem I've described above. I don't know. Again, anyone care to comment? >> This gives me an opportunity to clear up a question I've had for quite a >> while. Is it possible to do the following: [ my silly question here ] > >The answer is most definitely YES. The class declaration contains all that Okay, so I was seriously derranged when I wrote that :-). Sorry I wasted the net bandwidth (seriously, though the resulting discussion has been interesting). Please forgive it as a case of no-sleep-does-strange-things-to- the-brain. >(This man's opinions are his own.) >From mole-end Mark Terribile 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 <std_disclaimers.h>
mat@mole-end.UUCP (Mark A Terribile) (05/08/89)
... The question is Objective-C .vs. C++ -- does the type structure of C++
prevent you from re-using (inheriting from) things for which you don't
have the entire source code (but for which you do have the class
declaration, presumably in .h file)?
... ``No'' was the first answer proposed ...
... ``Yes'' I declared, since all that is necessary to write a class derived
from the given class, and to link that class in, is the stuff in the class
declaration.
> Ummm, I think you got that backwards. ... The terminology used in Brad's
> description can be rather confusing. Let me try again and see (1) if I can
> describe it well and (2) just how much I can get flamed ...
> Suppose you're provided with class 'sprocket' which someone else wrote. ...
> Now, lets look at where strong typing restricts things ...
> If class 'sprocket' takes arguments, then it must decide upon the types of
> the arguments that it takes. Assume that 'sprocket' takes at least one
> object as an argument. C++ requires that you provide a type for that
> argument in the form of a formal parameter in the .h and .c files. This
> restricts you to a member of that class or one of its sub-classes (nothing
> new here). But lets look at a pretty generic member function (method) like
> 'print' or 'display'. You could easily expect to create classes not derived
> from the same superclass and have them incorporate a 'print' method (or
> 'display' or whatever). ...
C++ requires that if ``sprocket'' requests something of an object that has been
passed to it, that object has been declared to have that capability (that
member function must exist for the class of which the object is an instance).
Yes.
> Yet C++ requires you to make a choice when writing the supplier as to what
> classes are valid objects ...
The programmer of ``sprocket'' must declare what he will accept, and the
things that he (or his class) will accept must have a set of capabilities
(member functions) which includes all that will be asked of them.
> ... This means that the person writing the code for the supplier must decide
> a priori what tasks 'sprocket' might be usefull in solving. But the whole
> point of writing suppliers it to avoid making decisions about what kinds of
> problems can be solved with code for 'sprocket' and instead let the client
> programmer look at available classes and decide what to use.
This is getting pretty close to one of the uses of Multiple Inheritance.
If I have a Doojigger which I want processed by a Sprocket, then Doojigger
has to somehow inherit the capabilities that Sprocket will use. If it
doesn't, I'm free (using MI) to quickly wrap a derived class around Doojigger
recasting the operations that are needed into those that are available.
This means I have to do a little work. In return, I am guaranteed that I won't
get a runtime error from the method dispatch system. In code that I am
building into a product, I think the tradeoff is appropriate.
It also means that the Sprocket must get its ``print'' from a visible, if
not standard, set of declarations. The first part is easy; the second is
significantly harder. It's less of a problem in a large project that has
its own standard environment or in a case where you've bought a complete
bunch of goodies from one software author/vendor.
> ... Furthermore, the 'precompiled classes' scenario prevents this option
> anyway since you can't control the inheritance tree of the precompiled
> classes you (theoretically) buy from some software vendor. ... This
> severely limits the reusability of the code for 'sprocket'.
Again, MI does provide a solution.
> Now, before you get out your flame-throwers, let me reiterate that I realize
> that there are advantages to OO other than reusability. In particular,
> encapsulation helps tremendously with debugging, correctness, and I'm sure
> there are others I've missed. ...
You've got the big ones. I think that you are underrating them, however.
It's nice to have a force multiplier for little bits of effort. It's nice
not to have to write even ten lines of (declared as such) interface code
between old and new.
On the other hand, in the real world of large products, ten lines of code is
a drop in the bucket. If with ten lines of code, we can improve the
reliability of the software by even five percent, we've won--big. Reliability
of delivered software is the greatest problem we face, and by far.
Does ``portability'' mean ``runnable unchanged'' or ``relatively easy to get
running, even if a few changes are needed'' ? I contend that the latter
definition is valuable, *IF* we can identify the changes reliably. The same
can be said of ``reusability.''
I'm not so worried about software re-use. Most large systems have been
recoded piecemeal dozens of times, each change introducing bugs because there
were never definite guidelines to use in creating the original structure or
in making changes that might or might not violate whatever conceptual structure
the program had. We are already paying costs far greater than that of coding
a simple type at need.
I've seen managers who wouldn't know good programming style if it chained
them to a desk and did a striptease scream ``no goto's'' because that's
accepted good practice. OOP has the potential for the same, usually
beneficent effects. (The existance of certain brain-damage in LINT provides a
counter-example.)
There are also two ways to view OOP. One is to view it as a way to build
programs from existing pieces; the other is to view it as a way to organize
the structure of a problem so that a well-structured program may be written.
Objective-C stresses the first. Re-usability because it's there stresses
the first. C++ stresses the latter. The low overhead of member functions
and the ability to write operators make *expression* of the problem more
rewarding than parts-bin assembly.
Both approaches have their place, but on the large scale, I think that the
latter is the way to get programs for which the efforts of ``testers''
(whether they be provers, reviewers, walk-through teams, or old-fashioned
``bang-on-it-until-it-breaks'' boredom specialists) will more rapidly
converge on a program which for which liability can be risked when it is
placed in the hands of thousands of customers.
> However, *IMHO*, reusability provides the greatest potential benefits in
> the long run if we can develop techniques to support it.
As I said before, I place reliability first. If we can make it reliable
cheaply, we can make it more cheaply than if we make it and then spend money
making it reliable.
> ... Okay, maybe the strong typing of objects helps in other ways (I'm not
> convinced of that yet); ...
I am. Getting it right in concept and reliable in fact are more important to
me. A program that is not reliable is a legal, ethical, and moral liability;
if it's so unrealiable that it has to be tweaked over hundreds of times because
it was put together from the parts that were there, rather than built from
parts whose correct relationship to each other was established, it's a
financial liability as well. Those finances finance our paychecks.
It's accepted that every stage of development through which a problem persists
increases the cost of fixing the problem by at least an order of magnitude.
Thinking out how to string together parts that need an Adapt-O-Kit costs
more than getting the parts right; finding a problem in a review or walk-
through costs more than finding it in code on the programmer's desk; finding it
in testing costs still more; finding it in initial field testing costs even
more. Depending on the nature of the product, one of the later steps in
delivery may be worth two orders of magnitude in cost.
> ... maybe multiple-inheritance will help change fix the problem I've
> described above. I don't know. Again, anyone care to comment?
It can. There will be some execution cost. In a quick-and-dirty slaptogether
it probably doesn't matter. In a program where it does matter, getting the
pieces right should be counted part of the cost of getting the thing right
altogether.
Oh, and if the C++ templates can be implemented (3.0 ?) they will probably
improve the situation still further.
> Brian R. Gilstrap Southwestern Bell Telephone
> #include <std_disclaimers.h>
--
(This man's opinions are his own.)
From mole-end Mark Terribiledld@F.GP.CS.CMU.EDU (David Detlefs) (05/08/89)
In the ongoing Obj-C vs C++ discussion, Brian Gilstrap writes: >Suppose you're provided with class 'sprocket' which someone else wrote. Then >class 'sprocket' would be a service supplier to other classes which you write. >A class which you write which makes use of 'sprocket' would naturally be a >client of 'sprocket'. Now, lets look at where strong typing restricts things >and also improve type-checking (you can decide which is more important, since >I've been heavily flamed already). >If class 'sprocket' takes arguments, then it must decide upon the types of >the arguments that it takes. Assume that 'sprocket' takes at least one >object as an argument. [I'll interpret this as meaning that at least one of sprocket's member functions takes an argument of a class type.] >C++ requires that you provide a type for that argument >in the form of a formal parameter in the .h and .c files. This restricts you >to a member of that class or one of its sub-classes (nothing new > here). But >lets look at a pretty generic member function (method) like 'print' or >'display'. You could easily expect to create classes not derived from the >same superclass and have them incorporate a 'print' method (or 'display' or >whatever). Yet C++ requires you to make a choice when writing the supplier >as to what classes are valid objects (at least as far as 'sprocket' is >concerned). [I don't exactly understand the last sentence, myself.] I don't want to get into the depths of this discussion, but I would like to point out one tool that can bring the two sides closer together: generic classes and functions. If I may paraphrase Brian's example: if 'sprocket' uses a type in a minimal way, say it just prints and displays it and maybe calls == on it, then inheritance is probably not the right mechanism to get type-safety, since we don't want to use multpile inheritance to create a "PrintableDisplayableandComparable" class, from which many others inherit. Instead, we parameterarize 'sprocket' over the type T, and instantiate it to get the actual 'sprocket' types we need. Completely type-safe, no run-time "message not understood" errors. Presently, we would have to do this using big hairy macros (or something like Doug Lea's 'proto' program for libg++), but eventually there will probably be language support (Stroustrup has published a possible design for such a mechanism.) With compiler support, there may not even be much duplicated code for multiple instantiations of the same type. classes, then 'sprocket' can take the parameter parameter. Having used languages providing both, I think if I had to choose one of inheritance and parameterized types, I'd take the latter. But that's a little reactionary. I'd rather have both. Also, Bertrand Meyer's Object-Oriented Software Construction has a good discussion on the proper use of inheritance vs. genericity. Trying to keep an open mind... -- Dave Detlefs Any correlation between my employer's opinion Carnegie-Mellon CS and my own is statistical rather than causal, dld@cs.cmu.edu except in those cases where I have helped to form my employer's opinion. (Null disclaimer.) --
greg@sce.carleton.ca (Greg Franks) (06/15/89)
Greetings.
We have a big application written in Version 3 of Objective C that we
are about to move to Version 4.0. We are interested in learning of
any potential pitfalls that may arrise because of the conversion, and
of any bugs in Version 4 of the compiler which are not found in
Version 3.
Please send email rather than posting.
Thanks
..greg
:-) :-) :-)
Sorry about cluttering up comp.lang.c - I'll let you get back to
discussing the merits of 'case', and using null as a string terminator.
:-) :-) :-)
--
Greg Franks Systems and Computer Engineering,
utzoo!dciem!nrcaer!sce!greg Carleton University, Ottawa, Ontario, Canada.
uunet!mitel!sce!greg greg@sce.carleton.ca
from Ottawa Ont, where life in the fast lane is skating two inners!esumardy@silver.ucs.indiana.edu (eddy sumardy) (02/05/90)
I am not sure if this is the right place to ask my question. But I am sure many of you will be able to help me. Currently I am doing a database project using objective C in Next machine. The only textbook that helps describing the language is by Brad J. Cox, "OO programming, AN Evolutionary Approach". It helps in term of concept. But it lacks example and syntax. Would any body help me by suggesting books or anything that may help me? By the way, the manual provided by Next is not very helpful. Thanks a lot netters! ed Graduate Student Computer Science Dept. Indiana University
cox@stpstn.UUCP (Brad Cox) (02/06/90)
You should be able to obtain what you need by calling Sara Bell at Stepstone; 203 426 1875. Brad Cox