cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) (08/20/90)
Well, the subject line says it all. What is Objective C? How does it compare with C++? What is the title of a good book? Thanks. -- O-------------------------------------------------------------------------> | Cliff Joslyn, Cybernetician at Large, cjoslyn@bingvaxu.cc.binghamton.edu | Systems Science, SUNY Binghamton, Box 1070, Binghamton NY 13901, USA V All the world is biscuit shaped. . .
patrickd@chinet.chi.il.us (Patrick Deupree) (08/23/90)
In article <3864@bingvaxu.cc.binghamton.edu> cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes: > >Well, the subject line says it all. What is Objective C? How does it >compare with C++? What is the title of a good book? > I believe that Objective C is an actual Object Oriented C compiler whereas C++ is a pre-processor. This basically means that C++ code is translated into C code which is then compiled into a final form. Some would argue that this makes it somewhat a kludge and they don't want to use it. Objective C is sometimes thought of as a more "pure" object oriented solution to C. These issues arose in a heated discussion with one of our R&D folk when I said C++ wasn't bad and he talked of the virtues of Objective C. (It's been a while since I've gone over all this so I may be wrong.) -- "Organized fandom is composed of a bunch of nitpickers with a thing for trivial pursuit." -Harlan Ellison Patrick Deupree -> patrickd@chinet.chi.il.us
strobl@gmdzi.UUCP (Wolfgang Strobl) (08/24/90)
patrickd@chinet.chi.il.us (Patrick Deupree) writes: >I believe that Objective C is an actual Object Oriented C compiler whereas >C++ is a pre-processor. This basically means that C++ code is translated >into C code which is then compiled into a final form. Some would argue that >this makes it somewhat a kludge and they don't want to use it. Objective >C is sometimes thought of as a more "pure" object oriented solution to >C. These issues arose in a heated discussion with one of our R&D folk when >I said C++ wasn't bad and he talked of the virtues of Objective C. C++ is a language, not a pre-processor. The C++ compiler I use (Zortech C++ version 2.1) is a two pass compiler which compiles to the usual object file format, and it is as fast as the usual C compilers. As far as I know, Turbo C++ isn't implemented as a pre-processor, either. I like C++ better than any other OO language dialect, because it implements OO concepts quite similar to SIMULA67, the yet unsurpassed grandfather of all object oriented languages. And, yes, it allows developement for MS Windows. (-: Wolfgang Strobl #include <std.disclaimer.hpp>
sarima@tdatirv.UUCP (Stanley Friesen) (08/24/90)
In article <1990Aug23.151011.12954@chinet.chi.il.us> patrickd@chinet.chi.il.us (Patrick Deupree) writes: >In article <3864@bingvaxu.cc.binghamton.edu> cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes: >> >>Well, the subject line says it all. What is Objective C? How does it >>compare with C++? What is the title of a good book? > >I believe that Objective C is an actual Object Oriented C compiler whereas >C++ is a pre-processor. This basically means that C++ code is translated >into C code which is then compiled into a final form. Some would argue that >this makes it somewhat a kludge and they don't want to use it. This is a compiler implementation issue. Only some C++ compilers use C as the 'assembly' language, others produce direct machine code. [This is just like some C compilers producing assembly output and running it through asm, which some early UNIX C compilers did]. It is certainly not a requirement of C++ that it be compiled into C. > Objective >C is sometimes thought of as a more "pure" object oriented solution to >C. These issues arose in a heated discussion with one of our R&D folk when >I said C++ wasn't bad and he talked of the virtues of Objective C. The main difference is that Objective-C is a Smalltalk based extension to C, while C++ is a Simula based extension to C. The choice depends on whether you prefer the purely dynamic binding, tree search style of method resolution; or a type-safe, fixed search style of method resolution with optional static binding.
burgess@hpspkla.spk.hp.com (David E. Burgess) (08/25/90)
> / hpspkla:comp.object / patrickd@chinet.chi.il.us (Patrick Deupree) / 8:10 am Aug 23, 1990 / > In article <3864@bingvaxu.cc.binghamton.edu> cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes: > > > >Well, the subject line says it all. What is Objective C? How does it > >compare with C++? What is the title of a good book? > > > > I believe that Objective C is an actual Object Oriented C compiler whereas Objective C is a C pre-processor. (At least that what Stepstone sells) It produces ANSI C. The syntax is similar to Small-Talk and is translated into calls to a messager that does any necessary dynamic binding. > C++ is a pre-processor. This basically means that C++ code is translated > into C code which is then compiled into a final form. Some would argue that > this makes it somewhat a kludge and they don't want to use it. Objective > C is sometimes thought of as a more "pure" object oriented solution to > C. These issues arose in a heated discussion with one of our R&D folk when > I said C++ wasn't bad and he talked of the virtues of Objective C. I would talk that up to personal bias. I have been coding in Objective C for a few years and have also been learning C++. Each language has things that are easier to do (in it) than the other language. (personal opinion mode) I think that C++ is becoming the more accepted standard for new/future work. Examine your needs and how well that fits the two languages. I don't think either language is missing any big piece of functionality, they just accomplish the same tasks in different ways. (end opinion mode) > > (It's been a while since I've gone over all this so I may be wrong.) > -- > "Organized fandom is composed of a bunch of nitpickers with a thing for > trivial pursuit." -Harlan Ellison > > Patrick Deupree -> patrickd@chinet.chi.il.us > ---------- That's my $0.02 worth. David E. Burgess (Insert all disclaimers here)
hansen@pegasus.ATT.COM (Tony L. Hansen) (08/25/90)
< I believe that Objective C is an actual Object Oriented C compiler whereas < C++ is a pre-processor. This basically means that C++ code is translated < into C code which is then compiled into a final form. Some would argue < that this makes it somewhat a kludge and they don't want to use it. < Objective C is sometimes thought of as a more "pure" object oriented < solution to C. For Pete's sake! Get your facts straight. Objective C is an object oriented C++ is an object oriented language language and essentially a and essentially a superset of C. superset of C. Compilers for Objective C are Compilers for C++ are available provided by Stepstone, Inc. They from several sources, such as produce object code directly and AT&T's cfront translator, Oregon may possibly even produce C code, Software, Zortech and Borland. for all I know. Those compilers based on cfront produce C as an intermediate assembly language, which is then further compiled into object code. Those compilers provided by the other companies produce object code directly. All of these compilers, even cfront, are full compilers; they just use different forms of assembly language as their outputs. Some people think that the syntax The syntax of C++'s objects look of Objective C's objects look more more like C's structures. Message similar to Smalltalk objects. passing may or may not be Message passing is almost always polymorphic. polymorphic. Objective C has a number of class C++ has a number of class libraries available from libraries available from a variety Stepstone. of sources. If you define an "object oriented solution to C" as "most like Smalltalk", then Objective C undoubtedly wins the appellation. Most people I know do NOT use such a definition. The C, C++ and Objective C preprocessor is that part of the compilation system which deals with #include statements and their kin. < These issues arose in a heated discussion with one of our R&D folk when I < said C++ wasn't bad and he talked of the virtues of Objective C. (It's < been a while since I've gone over all this so I may be wrong.) I suggest that you and your R&D person learn a bit more about both languages. I've leave the rest of the conclusion drawing to others. I'll admit to being somewhat biased. :-) Tony Hansen att!pegasus!hansen, attmail!tony hansen@pegasus.att.com P.S. Where does the expression "For Pete's sake" come from?
ark@alice.UUCP (Andrew Koenig) (08/25/90)
I would like to add one thing to Tony Hansen's remarks. Cfront is a compiler that works roughly like this: 1. Read and parse a C++ program into an internal representation. 2. Walk through the internal representation translating the parts of C++ that aren't in C into the corresponding C code. 3. Print out C source code corresponding to the internal representation. Now, (3) is a very small part of cfront -- somewhere around 5 percent of the total code. The reason it's there, of course, is that it wouldn't be very useful if all you got was internal representation! In other words, as you get it from AT&T, cfront is a C++ compiler front end coupled with a straightforward C-generating back end. Now, why do we do this? There are two reasons: 1. Our primary customers are companies that bundle cfront together with whatever other compilation technology they may be selling. If we were to generate machine code for their particular machines, they would probably want eventually to rip out our code generator and substitute theirs anyway. 2. We want to make it as easy as we can to get C++ running on a new machine. Reason (1) implies that it is possible for our customers to remove the C code generator from cfront and substitute their own machine-code generator. And indeed one of our customers has done exactly that: if you buy their C++ system for their machines, you get cfront + their code generator in a package that only generates machine language. I don't think it's even possible to get C out. Other companies have done similar things. For example, there's one other that instead of generating C in ASCII form, generates it as a stream of tokens that is then fed directly into the syntax analysis phase of their C compiler. Others do it the straightforward way -- just generate C and be done with it. -- --Andrew Koenig ark@europa.att.com
kitchel@iuvax.cs.indiana.edu (Sid Kitchel) (08/25/90)
strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >I like C++ better than any other OO language dialect, because it >implements OO concepts quite similar to SIMULA67, the yet unsurpassed >grandfather of all object oriented languages. Yes it is clear that many share your like of C++ as both a close relative of Simula and C, our favorite easy-to-get-yourself-in- trouble language. Others, like myself, prefer languages with a greater degree of object orientation within their design. I personally think that having objects and messaging as an integral part of the language is cleaner and more useful than being tacked on the side. But, of course, that will not deter C++ becoming even more popular. I guess I'm just a spoiled sport purist. --Sid -- Sid Kitchel...............WARNING: allergic to smileys and hearts.... Computer Science Dept. kitchel@cs.indiana.edu Indiana University kitchel@iubacs.BITNET Bloomington, Indiana 47405-4101........................(812)855-9226
carroll@udel.edu (Mark Carroll <MC>) (08/26/90)
In article <2700002@hpspkla.spk.hp.com> burgess@hpspkla.spk.hp.com (David E. Burgess) writes: >> / hpspkla:comp.object / patrickd@chinet.chi.il.us (Patrick Deupree) / 8:10 am Aug 23, 1990 / >> In article <3864@bingvaxu.cc.binghamton.edu> cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes: >> > >> >Well, the subject line says it all. What is Objective C? How does it >> >compare with C++? What is the title of a good book? >> > >> >> I believe that Objective C is an actual Object Oriented C compiler whereas > >Objective C is a C pre-processor. (At least that what Stepstone sells) >It produces ANSI C. The syntax is similar to Small-Talk and is translated >into calls to a messager that does any necessary dynamic binding. > >> C++ is a pre-processor. This basically means that C++ code is translated >> into C code which is then compiled into a final form. ... I just felt like it was time to pop in here. Quite often lately, I've seen people claiming that "language X is really just a preprocessor, whereas language Y is a compiler." The supposed distinction between the two is very slight, if it does indeed exist at all. C++ and Objective-C can both be implemented in ways where the output code is C. Many people are calling this "preprocessing". The only distinction between a "true" compiler, and a "preprocessor" is that the preprocessor is using a familiar HLL as its intermediate representation. This doesn't imply anything negative about the compiler, the language, or the implementation. The compiler is STILL a compiler; the language is still a language. >> Patrick Deupree -> patrickd@chinet.chi.il.us >David E. Burgess <MC> -- |Mark Craig Carroll: <MC> |"We the people want it straight for a change; |Soon-to-be Grad Student at| cos we the people are getting tired of your games; |University of Delaware | If you insult us with cheap propaganda; |carroll@udel.edu | We'll elect a precedent to a state of mind" -Fish
ark@alice.UUCP (Andrew Koenig) (08/26/90)
In article <28470@nigel.ee.udel.edu>, carroll@udel.edu (Mark Carroll <MC>) writes: > The only distinction between a "true" compiler, and a "preprocessor" > is that the preprocessor is using a familiar HLL as its intermediate > representation. That depends on your definition, I suppose. To me, the word `preprocessor' usually carries the connotation of a program whose output will mostly be the same as its input, except for specific chunks of the input that the program transforms. By this definition, the C preprocessor is surely a preprocessor. So is m4 and sed. I'm not aware of any C++ implementation that meets this definition of preprocessor, and doubt it's possible: implementing C++ requires a complete analysis of the input. -- --Andrew Koenig ark@europa.att.com
nkraft@crash.cts.com (Norman Kraft) (08/26/90)
>Well, the subject line says it all. What is Objective C? How does it >compare with C++? What is the title of a good book? Having been absent from the net for a while, I may have missed the answers to this question. Forgive me, all, if this answer has already been posted: A pretty good book on Objective C and object oriented programming overall is _Object_Oriented_Programming_, "An Evolutionary Approach", by Brad J. Cox. (Addison Wesley, 1987). It's a book we used in a graduate OOPS course here in the math department at San Diego State. -------------------------------------------------------------------------- Norman R. Kraft "Things should be as Director, Software Development simple as possible, Postal Buddy Corp., San Diego, CA but not simpler." INET nkraft@crash.cts.com - Albert Einstein UUCP {hplabs!hp-sdd ucsd nosc}!crash!nkraft --------------------------------------------------------------------------
nick@abblund.se (08/27/90)
In article <1990Aug23.151011.12954@chinet.chi.il.us> patrickd@chinet.chi.il.us (Patrick Deupree) writes: > >I believe that Objective C is an actual Object Oriented C compiler whereas >C++ is a pre-processor. This basically means that C++ code is translated >into C code which is then compiled into a final form. Wrong! There are several C++ implementations available. Some are pre-processors, some are compilers. To my knowledge Objective-C is so far only available as a pre-processor, but there is nothing to stop anyone from making a compiler. >Patrick Deupree -> patrickd@chinet.chi.il.us -- Nick Hoggard Phone: + 46 46 168524 Man-Machine Communication Lab Fax: + 46 46 145620 ABB Corporate Research, Dept KLL Internet: nick@abblund.se Ideon Research Park, Ole Roemersvaeg 5, S-223 70 Lund, Sweden
cox@stpstn.UUCP (Brad Cox) (08/27/90)
In article <11233@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: }Cfront is a compiler that works roughly like this: } } 1. Read and parse a C++ program into an internal representation. } } 2. Walk through the internal representation translating the } parts of C++ that aren't in C into the corresponding C code. } } 3. Print out C source code corresponding to the internal representation. } }Now, (3) is a very small part of cfront -- somewhere around 5 percent }of the total code. The reason it's there, of course, is that it wouldn't }be very useful if all you got was internal representation! This should be so obvious that I needn't point out that the Objective-C *compiler* does the same things, in precisely the same fashion, for exactly the same reasons. The Objective-C *interpreter* does not, again for reasons that should be obvious. The downside of the difference is why the interpreter is presently available only for an old version of the language, and not on the newest machines. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
lerman@stpstn.UUCP (Ken Lerman) (08/28/90)
In article <11233@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: ->I would like to add one thing to Tony Hansen's remarks. -> ->Cfront is a compiler that works roughly like this: -> -> 1. Read and parse a C++ program into an internal representation. -> -> 2. Walk through the internal representation translating the -> parts of C++ that aren't in C into the corresponding C code. -> -> 3. Print out C source code corresponding to the internal representation. -> Ditto for Objective-C. Except that for some constructs, steps 2 and 3 are done in parallel. (substituting Objective-C for C++, of course) [...stuff deleted...] >-- > --Andrew Koenig > ark@europa.att.com Disclaimer: Although I ought to know, since I look at the compiler source every day, these opinions (do they look like facts? ) are mine and I represent myself. Ken Lerman
jimad@microsoft.UUCP (Jim ADCOCK) (08/28/90)
One way to try to put comparisons of OOPLs into perspective is to try to measure how much interest there is in each language. I've been tracking such interest by noting how many references to the various languages appears each month in the Computer Library database. The database is shipped monthly on CD-ROM, and represents abstracts and/or complete articles from almost all articles in almost all the major computer journals over the prior year.. The August database shows the following number of references by various OOPL languages: C++ 2044 Smalltalk 869 Objective-C 228 Eiffel 48
pcg@cs.aber.ac.uk (Piercarlo Grandi) (08/29/90)
On 25 Aug 90 15:01:58 GMT, ark@alice.UUCP (Andrew Koenig) said: That cfront is a C++ compiler compiler that generates C code instead of assembler, then adds: ark> Other companies have done similar things. For example, there's one other ark> that instead of generating C in ASCII form, generates it as a stream of ark> tokens that is then fed directly into the syntax analysis phase of their ark> C compiler. I remember Stroustrup writing that the 1.x cfront had not just a C backend but that is could also use as backend the pcc backend, much in the same way as f77 does it. Is that still possible with cfront 2.x, without too much trouble? There are all those BSD systems around that use pcc, and this would be a nice way to make compilation times shorter on those systems. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
bertrand@eiffel.UUCP (Bertrand Meyer) (08/30/90)
It is always surprising to see so many people confusing programming languages and their implementations. Again and again again people - apparently including professionals in the field - will overlook that distinction, making entire discussions irrelevant at best and misleading at worst. Why is that so? There is nothing tricky or difficult in the distinction. Just common sense. -- Bertrand Meyer bertrand@eiffel.com
bs@alice.UUCP (Bjarne Stroustrup) (08/30/90)
Piercarlo Grandi says: > I remember Stroustrup writing that the 1.x cfront had not just a C > backend but that is could also use as backend the pcc backend, much in > the same way as f77 does it. Almost correct. I had an assembler generating version planned and cfront collects much information needed for that in its tables, but I never got around to actually writing that version. > Is that still possible with cfront 2.x, without too much trouble? There > are all those BSD systems around that use pcc, and this would be a nice > way to make compilation times shorter on those systems. It can be done - and the proof is that it actually has been done.
cox@stpstn.UUCP (Brad Cox) (09/02/90)
In article <401@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: > > It is always surprising to see so many people confusing >programming languages and their implementations. Again and again >again people - apparently including professionals in the field - >will overlook that distinction, making entire discussions >irrelevant at best and misleading at worst. > > Why is that so? There is nothing tricky or difficult in the >distinction. Just common sense. > I've wondered the same thing, Bertrand, but with respect to nearly any software issue, not just with languages vs implementations. I boil it down as follows. Real engineers work with tangible things whose properties can be unambiguously understood by relying on natural senses. Theologians, philosophers, mathematicians, and the like work with pure abstractions; i.e. in a domain of belief rather than quantifiable fact. Software engineers work with software, an abstract/concrete hybrid; a swamp that's too thick to drink and too thin to plow. By hybrid, I mean that we get some of the best and some of the worst of both worlds. In particular, we get to deal with large numbers of people who exist in a world of belief and not quantifiable, observable fact. In other words, factual differences between languages and implementations are as relevant to true believers (that 'precompiler are bad...my professor said so) as a (hypothetical) discovery that Jesus never existed would be to true Christians. I chose this example carefully because it helps to distinguish effective vs ineffective ways of proceeding. Facts help, but do not solve. The kind of flaming this network is notorious for doesn't help, and makes things worse by hardening positions. The problem is not the unthinking mass of true believers, anymore than the problem is the unthinking mass of Christians or Jews or Moslems. The problem is the intangible, swampy nature of software itself that causes people to deal with it as a matter of abstract belief rather than concrete tangible fact. Thus direct manulation user interfaces, personal computing, OO technologies, etc, etc as the low-level technologies in the massive paradigm shift that I'm calling the Software Industrial Revolution. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
psrc@cbnewsl.att.com (Paul S. R. Chisholm) (09/04/90)
In article <401@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: > It is always surprising to see so many people confusing programming > languages and their implementations. . . . Why is that so? In article <5524@stpstn.UUCP>, cox@stpstn.UUCP (Brad Cox) writes: > I've wondered the same thing, Bertrand . . . I will try to post this entire article without giggling. Let me start out by pointing out that eiffel.uucp and stpstn.uucp are the Usenet systems of two companies which (currently) provide the sole implementations of their founders' respective object-oriented programming languages and/or environments. In these two cases, if one wants to use the one of the languages and/or environments in question, one will find that *the* (singular) implementation is tied very tightly to the language and/or environment. (The "and/or" stuff isn't meant to be stuffy. Dr. Cox has been very vocal that no programming language, not even Objective C, will bring about the kinds of improvements we'd all like to see; his company's product is a set of software components, written in a particular language, and a program that reads this language and produces object code.) There *are* languages with multiple implementations. C++ has been implemented by AT&T, Zortech, Oregon, GNU, and Borland, just to name companies that are reachable via the Internet. Parc Place Systems, Digitalk, and GNU all have Smalltalk implementations; they're all reachable electronically, though Digitalk hangs out on BIX, not the Internet or Usenet. (No, I don't have specific contacts for any of these guys!) If I have a Sun workstation or an MS-DOS system, I can choose between at least three implementations for my specific platform. And, yes, it makes less sense to ask, "Is C++ slower than C" than to ask "Does Turbo C++ 1.0 produce code as good as Turbo C 2.0's code?" And *any* language can, in theory and with enough work, be translated into better object code that that produced by a student compiler for <name your favorite low-level language here, e.g., Pascal or C>. (Just go to comp.lang.lisp, where anyone will gladly promise you that their favorite Lisp processor generates better code than the World's Greatest Programmer writing tight, hand assembled code.-) HOWEVER! C++ was designed so "in theory and with enough work" requires very simple theory, and relatively little work. On the other hand, turning Smalltalk into something that will run as quickly as well compiled C on an 8088 with 640K is a *real* challenge. Maybe it's impossible without some language hacks. (I defer to A. Dain Samples, David Ungar, and Paul Hilfinger; see their "SOAR: Smalltalk Without Bytecodes" in the OOPSLA '86 Proceedings.) So . . . will a program that, by the language definition, must do garbage collection, run as quickly as a program where the "user" (the programmer in the language in question) must manage memory? Probably not, unless the language implementor has done a terrific job, and the "user" has botched it. Will a program that, by the language definition, must do an additional memory indirection, or even a table look up at run time, run as quickly as a program where subroutine calls can be translated straightforwardly into a subroutine call instruction? Same answer. Paul S. R. Chisholm, AT&T Bell Laboratories att!mtunq!psrc, psrc@mtunq.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind.
johnson@m.cs.uiuc.edu (09/05/90)
>So . . . will a program that, by the language definition, must do >garbage collection, run as quickly as a program where the "user" (the >programmer in the language in question) must manage memory? Probably >not, unless the language implementor has done a terrific job, and the >"user" has botched it. Although I agreed with most of what Paul Chisholm said, I disagree with this statement. My experience with C++ is that memory management takes a lot of CPU time. We use reference counting, and have to lock objects before changing their reference count (we are using a multiprocessor). Not only is this time-consuming for the programmer to get right, it is time-consuming for the computer to execute. Because programmer-controlled memory management is all tied up with the application program, it is very hard to tell exactly how much time is spent in it. Thus, programmers don't know how much time their code spends in memory management. I would be quite surprised if an optimizing compiler that understood memory management couldn't do better. Ralph Johnson - University of Illinois at Urbana-Champaign
lgm@cbnewsc.att.com (lawrence.g.mayka) (09/05/90)
In article <1990Sep4.034131.532@cbnewsl.att.com>, psrc@cbnewsl.att.com (Paul S. R. Chisholm) writes: > So . . . will a program that, by the language definition, must do > garbage collection, run as quickly as a program where the "user" (the > programmer in the language in question) must manage memory? Probably > not, unless the language implementor has done a terrific job, and the > "user" has botched it. Will a program that, by the language > definition, must do an additional memory indirection, or even a table > look up at run time, run as quickly as a program where subroutine calls > can be translated straightforwardly into a subroutine call instruction? > Same answer. 1) Typical user-written memory management schemes, ranging from 'malloc' and 'free' to reference counting, are considerably *less* efficient than a well-written garbage collection algorithm. Further performance improvement in this matter typically comes only with some kind of "staticization" - e.g., fixed-size per-type buffer pools. 2) Language definitions rarely specify particular implementation techniques such as memory indirections or table lookups. Rather, a language might require the implementation to behave in a particular situation *as if* an array reference or table lookup takes place. Implementors are typically free to optimize the common cases (e.g., via caching or even instruction modification) at the expense of slowing down more exotic operations (e.g., the ones not reasonably available in a less powerful language anyway). 3) Attempting to deduce the performance of entire programs - written in different languages and styles - from the execution speed of individual machine instructions is a dubious endeavor at best. One of the advantages of a more powerful programming language is to facilitate the implementation of algorithms which are highly efficient but practically infeasible to implement in a less powerful language. In other words: At high levels of complexity, micromanagement may *lose* to macromanagement. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
rca@cslab9a.cs.brown.edu (Ronald C.F. Antony) (09/06/90)
In article <1990Sep4.034131.532@cbnewsl.att.com>, psrc@cbnewsl.att.com (Paul S. R. Chisholm) writes: |>I will try to post this entire article without giggling. Let me start |>out by pointing out that eiffel.uucp and stpstn.uucp are the Usenet |>systems of two companies which (currently) provide the sole |>implementations of their founders' respective object-oriented |>programming languages and/or environments. In these two cases, if one |>wants to use the one of the languages and/or environments in question, |>one will find that *the* (singular) implementation is tied very tightly |>to the language and/or environment. What you write is only half correct: The NeXT computer systems (on 18th Sept there are coming a couple of new systems, and I guess they already work, so I use the plural) work with Objective-C. Although NeXT licensed parts of the language I guess, they reimplemented it on top of the GNU-C compiler. It is no longer a preprocessor and the runtime system is different. Actually the new compiler that is out on Sept 18th will not only compile Objective-C but also C++ and this in the same source file. (This may be ugly if you are a purist, but it can be pretty useful if you are porting applications). Best of all that, as the GNU license agreement commands, all the changes made to the compiler will be copylefted and thus available to anyone. So StepStone's Objective-C is not the only implementation of the language. Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." Bernhard Shaw | rca@cs.brown.edu or antony@browncog.bitnet ------------------------------------------------------------------------------
cox@stpstn.UUCP (Brad Cox) (09/06/90)
This is to correct a misunderstanding that I've heard many times in the past and that was recently repeated on the net. I first heard of it when the author posted the following mail to me: } In article <deleted> I write: } > eiffel.uucp and stpstn.uucp are the Usenet systems of two companies } > which (currently) provide the sole implementations of their } > founders' respective object-oriented programming languages and/or } > environments. } } Dr. Cox, when I said this, I assumed that Stepstone code is behind the } NeXT and IBM implementations of Objective-C on those platforms, just as } AT&T code is behind (for example) the Glockenspiel and Comeau MS-DOS } implementations of C++. I understand that these other implementations } provide additional added value, better technical support, and all that. } But if my assumption is correct, I stand by my statement. } } If NeXT or IBM have independently developed products from scratch for } Objective-C, as (for example) Borland and Zortech have for C++ under } MS-DOS, I'll be happy to apologize publicly. (You have my explicit } permission to quote from this letter for that purpose.) I'd not read the news article when I responded by mail as follows: } I don't recall the context of your posting, so it could hardly have } been so dire that an 'apology' is necessary. } } But for your information, NeXT does distribute their own implementation of } Objective-C. They started NeXT with ours, but eventually hired one of its } developers to build an 'independent' implementation. When IBM purchased } rights to NeXTStep for the RS/6000, they chose Stepstone's implementation, } because of its wider availability on non-NeXT platforms, presumably among } other things that you'd have to ask IBM about. } } There have been at least two other competing implementations, } both derived more or less directly from the language as described } in my book. One company folded so that its founder could go back to school } for a graduate degree. The other language was dropped when its vendor } decided that it made more business sense for them to adopt Stepstone's } implementation and focus their resources on building libraries. } I'd have preferred that such issues be raised in a tone of voice such that questions of 'apology' never arise. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
stephen@estragon.uchicago.edu (Stephen P Spackman) (09/06/90)
In article <1990Sep4.034131.532@cbnewsl.att.com>, psrc@cbnewsl.att.com (Paul S. R. Chisholm) writes: > So . . . will a program that, by the language definition, must do > garbage collection, run as quickly as a program where the "user" (the > programmer in the language in question) must manage memory? Probably > not, unless the language implementor has done a terrific job, and the > "user" has botched it. Will a program that, by the language > definition, must do an additional memory indirection, or even a table > look up at run time, run as quickly as a program where subroutine calls > can be translated straightforwardly into a subroutine call instruction? > Same answer. Perhaps the thing to note is that the language implementor is being paid to optimise that implementation, while the programmer is trying to produce a different product entirely. I don't know how these things usually go, but I once spent the better part of a year working on a garbage collector. So, in a sense, what you say is true: the fact that in my sixth month or so I made changes that improved performance EIGHTFOLD (interactions with paging algorithms improved by adapting generation-scanvenging techniques, reordering memory-visits, and avoiding dirtying pages) means that there WAS a lot of work to be done when I started. But on the other hand, a compiler writer can amortise six man-months spent tuning the garbage collector; chances are you can't. It's a bit like saying, why have a compiler when I can write assembly code? stephen p spackman stephen@estragon.uchicago.edu 312.702.3982
psrc@cbnewsl.att.com (Paul S. R. Chisholm) (09/11/90)
In a previous article, I wrote: > So . . . will a program that, by the language definition, must do > garbage collection, run as quickly as a program where the "user" (the > programmer in the language in question) must manage memory? Probably > not, unless the language implementor has done a terrific job, and the > "user" has botched it. Looking back, this was a tad small. Times have changed, and most of the applications I write could probably run with garbage collection. That would would save me time in coding, and it might save me time in debugging (if I had a memory leak or dereferenced a dangling pointer). But if I was writing an operating system, or a real time application, the (unpredictable) overhead of garbage collection might not be acceptable. Then, I'd be willing to pay the (programmer) effort, and manage memory better than a garbage collector could. Somebody (Lawrence K-something, I think) said that good garbage collectors are hard to beat, unless you use a fixed-size memory pool or some such trick. Funny, it sounded as if he was disagreeing with me. That's *exactly* the kind of technique needed. In article <77500056@m.cs.uiuc.edu>, johnson@m.cs.uiuc.edu writes: > My experience with C++ is that memory management takes a lot of CPU > time. We use reference counting, and have to lock objects before > changing their reference count (we are using a multiprocessor). Not > only is this time-consuming for the programmer to get right, it is > time-consuming for the computer to execute. Reference counting is *slower* than garbage collection (see the Smalltalk implementation book). This is *not* what an efficiency- paranoid C++ programmer must do. > Because programmer-controlled memory management is all tied up > with the application program, it is very hard to tell exactly how > much time is spent in it. Thus, programmers don't know how much > time their code spends in memory management. I would be quite > surprised if an optimizing compiler that understood memory management > couldn't do better. Ungar's paper in the Smalltalk implementation book measures where the time goes. In his case, it was constructing and destructing stack frames! (Ungar's generation scavaging algorithm is one of the reasons garbage collection has such a good rep these days. To use the language from my earlier posting, he *did* a terrific job.) I don't think optimizing compilers can understand memory management at compile time. It's hard enough to understand at run time! > Ralph Johnson - University of Illinois at Urbana-Champaign Paul S. R. Chisholm, AT&T Bell Laboratories att!mtunq!psrc, psrc@mtunq.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind.
tma@osc.COM (Tim Atkins) (09/11/90)
In article <1990Sep4.034131.532@cbnewsl.att.com> psrc@mtunq.att.com (Paul S. R. Chisholm) writes: >In article <401@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: >> It is always surprising to see so many people confusing programming >> languages and their implementations. . . . Why is that so? > >In article <5524@stpstn.UUCP>, cox@stpstn.UUCP (Brad Cox) writes: >> I've wondered the same thing, Bertrand . . . > >I will try to post this entire article without giggling. Let me start >out by pointing out that eiffel.uucp and stpstn.uucp are the Usenet >systems of two companies which (currently) provide the sole >implementations of their founders' respective object-oriented >programming languages and/or environments. In these two cases, if one >wants to use the one of the languages and/or environments in question, >one will find that *the* (singular) implementation is tied very tightly >to the language and/or environment. Wrong in at least the Objective C case. I know Next has their own implemen- tation and have heard that IBM does also. In addition Objective-C covers at least as great a range of platforms as C++. I do not know of any Eiffel implementations outside the one by Interactive Systems but they also have fair platform coverage. The plus sides of single vendor languages are: a) you know the vendor has a stake in all aspects of language use and issues as in the cases above their very lives as companies are at stake; b) portability among supported platforms is much less of an issue when only a single consistent version is in existence; c) the vendor is much more likely to supply a decent supporting set of tools; d) applications that need low level access to the internals do not face the incompatibility issues they would in the multi-vendor case. > >There *are* languages with multiple implementations. C++ has been >implemented by AT&T, Zortech, Oregon, GNU, and Borland, just to name >companies that are reachable via the Internet. Parc Place Systems, >Digitalk, and GNU all have Smalltalk implementations; they're all >reachable electronically, though Digitalk hangs out on BIX, not the >Internet or Usenet. (No, I don't have specific contacts for any of >these guys!) Smalltalk has the library and tools issues well in hand for at least the "programming in the small domain". C++ to date, IMHO, does not. In addition I challenge you to simply recompile without modification any but the most trivial application on all the listed C++ products. >... >HOWEVER! C++ was designed so "in theory and with enough work" requires >very simple theory, and relatively little work. How so? The language is not very well behaved as far as formal language theory goes. The amount of traffic on comp.lang.c++ that requires the intervention of language lawyers would seem to indicate that it is also not that easy to understand and use. >So . . . will a program that, by the language definition, must do >garbage collection, run as quickly as a program where the "user" (the >programmer in the language in question) must manage memory? Probably >not, unless the language implementor has done a terrific job, and the >"user" has botched it. Will a program without GC guarantee the avoidance of mistakes that are next to impossible to catch by hand particularly in a multiple programmer environment? >Will a program that, by the language >definition, must do an additional memory indirection, or even a table >look up at run time, run as quickly as a program where subroutine calls >can be translated straightforwardly into a subroutine call instruction? >Same answer. I don't know which OO does not do this indirection to some degree. C++ certainly does, both for virtual function binding and for finding the base class portion of an object in the case of virtual inheritance. Which language does not allow late binding when that is called for and imposes lack of type checking and space overheads for use of MI in an environment requiring polymorphic container classes? In short I think there is very little for you to giggle about. > >Paul S. R. Chisholm, AT&T Bell Laboratories >att!mtunq!psrc, psrc@mtunq.att.com, AT&T Mail !psrchisholm >I'm not speaking for the company, I'm just speaking my mind. - Tim Atkins -- ditto on the disclaimer
pcg@cs.aber.ac.uk (Piercarlo Grandi) (09/11/90)
On 4 Sep 90 22:36:00 GMT, johnson@m.cs.uiuc.edu said: chisolm> So . . . will a program that, by the language definition, must chisolm> do garbage collection, run as quickly as a program where the chisolm> "user" (the programmer in the language in question) must manage chisolm> memory? Probably not, unless the language implementor has done chisolm> a terrific job, and the "user" has botched it. Probably yes, as others have remarked. Most programmers do not understand performance issues very well, least of all memory management. The greatest bottleneck in computer science is the number of competent system programmers; putting one of them to work on automatic memory management probably results in more efficient programs than putting hundreds of less competent (in the subject of memory management) application programmers to the task of doing memory management themselves. Notice that this applies to *any* kind of automatic memory management, not just garbage collection, which is just one of the techniques. johnson> Although I agreed with most of what Paul Chisholm said, I johnson> disagree with this statement. My experience with C++ is that johnson> memory management takes a lot of CPU time. We use reference johnson> counting, and have to lock objects before changing their johnson> reference count (we are using a multiprocessor). For example, this is *not* necessary in many cases. Since you *must* eventually invoke a garbage collector to reclaim cycles, you can just accept imprecise reference counting, that is counting that misses some count decrements. Or you can use reference count logs, etc... johnson> Not only is this time-consuming for the programmer to get johnson> right, it is time-consuming for the computer to execute. Case in point. The choice between reference counting and garbage collection is not an easy one. For example, Johnson is here restating the well known fact that the overhead of reference counting is proportional to the number of accesses to valid objects and the number/size of garbage objects, while that of garbage collection is proportional to the rate of object generation and the number/size of valid objects. Also, compaction under the two regimes has quite different effects, and so for example is the interaction with virtual memory (simple minded reference counting is very very very very bad under virtual memory). For example, Johnson may/may not be aware that many sophisticated reference counting schemes that substantially reduce reference counting overhead have been published, some designed with special reference to multiprocessors, but I am not sure that the implementation of an efficient multiprocessor reference counting scheme is his main research objective. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
lgm@cbnewsc.att.com (lawrence.g.mayka) (09/12/90)
In article <1990Sep11.030523.19830@cbnewsl.att.com>, psrc@cbnewsl.att.com (Paul S. R. Chisholm) writes: > But if I was writing an operating system, or a real time application, > the (unpredictable) overhead of garbage collection might not be > acceptable. Then, I'd be willing to pay the (programmer) effort, and > manage memory better than a garbage collector could. Garbage collection need not be unpredictable, with some degree of hardware support. Lisp machines are certainly able to manage their garbage collection quite precisely, and some research indicates that simple per-page read/write protection constitutes sufficient hardware support on which to build a predictable garbage collector (See the algorithm of Appel, Ellis, and Li.) > Somebody (Lawrence K-something, I think) said that good garbage > collectors are hard to beat, unless you use a fixed-size memory pool or > some such trick. Funny, it sounded as if he was disagreeing with me. > That's *exactly* the kind of technique needed. The difficulty comes in passing around references to an element of such a pool. Do you (a) Deallocate the element "out from under" its references, essentially requiring a validity check before each use of such a reference. (And if processes are preemptible, the validity check must be atomic with the access.) (b) Attempt to keep track of such references, through some inefficient or error-prone scheme. (c) Forbid such multiple references entirely. Advocates of garbage collection consider all these alternatives decidedly unattractive, to say the least. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
sakkinen@tukki.jyu.fi (Markku Sakkinen) (09/12/90)
In article <PCG.90Sep11165843@athene.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >On 4 Sep 90 22:36:00 GMT, johnson@m.cs.uiuc.edu said: > ... >johnson> Although I agreed with most of what Paul Chisholm said, I >johnson> disagree with this statement. My experience with C++ is that >johnson> memory management takes a lot of CPU time. We use reference >johnson> counting, and have to lock objects before changing their >johnson> reference count (we are using a multiprocessor). > >For example, this is *not* necessary in many cases. Since you *must* >eventually invoke a garbage collector to reclaim cycles, you can just >accept imprecise reference counting, that is counting that misses some >count decrements. Or you can use reference count logs, etc... Perhaps you didn't notice that Prof. Johnson wrote specifically about C++. Because of pointer arithmetic, it is not *possible* to use garbage collection safely with C++ (or any C-based language). (I have read Boehm's article in Software - Practice and Experience, but the reason for his success seemed to be that those large pieces of existing C software that he experienced with were amazingly constrained and well-behaving in their use of pointers.) Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)
pcg@cs.aber.ac.uk (Piercarlo Grandi) (09/14/90)
On 12 Sep 90 07:41:54 GMT, sakkinen@tukki.jyu.fi (Markku Sakkinen) said:
sakkinen> In article <PCG.90Sep11165843@athene.cs.aber.ac.uk>
sakkinen> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
pcg> On 4 Sep 90 22:36:00 GMT, johnson@m.cs.uiuc.edu said: ...
johnson> Although I agreed with most of what Paul Chisholm said, I
johnson> disagree with this statement. My experience with C++ is that
johnson> memory management takes a lot of CPU time. We use reference
johnson> counting, and have to lock objects before changing their
johnson> reference count (we are using a multiprocessor).
pcg> For example, this is *not* necessary in many cases. Since you
pcg> *must* eventually invoke a garbage collector to reclaim cycles, you
pcg> can just accept imprecise reference counting, that is counting that
pcg> misses some count decrements. Or you can use reference count logs,
pcg> etc...
sakkinen> Perhaps you didn't notice that Prof. Johnson wrote specifically
sakkinen> about C++.
I did, uhh, I did.
sakkinen> Because of pointer arithmetic, it is not *possible* to use
sakkinen> garbage collection safely with C++ (or any C-based language).
Or perhaps you misinterpret the C/C++ language -- pointer arithmetic is
only allowed within an array. As such it is exactly equivalent to array
indexing in other languages. Indeed in C/C++ array indexing and pointer
arithmetic are *exactly* equivalent. Any other use of pointer arithmetic
is outside the language. Therefore legal C/C++ programs do not special
problems because of pointer arithmetic.
The problem with C/C++ and collection, which is worked around by
conservative storage reclamation, is that since you do not have in
general type and size information available at runtime, the reclaimer
does not know which words contain pointers and how long objects are.
This has nothing to do with pointer arithmetic.
sakkinen> (I have read Boehm's article in Software - Practice and
sakkinen> Experience, but the reason for his success seemed to be that
sakkinen> those large pieces of existing C software that he experienced
sakkinen> with were amazingly constrained and well-behaving in their use
sakkinen> of pointers.)
The reason for his success is that, in the absence of type and size
information, he only reclaims store only when he is absolutely sure that
it is garbage -- every word that looks like containing a pointer into
the heap (even if in fact it only contains an integer or even a piece of
string whose binary value could be interpreted as an address into the
heap) is treated like one, and will protect the relevant store from
being reclaimed. This is absolutely safe, even if it will miss some
garbage -- but then reference counting will also miss some garbage
(cycles).
Note that conservative collectors require a BIBOP like memory
allocator to get around the other problem, not knowing an
object's length, and this is admittedly un unavoidable
disadvantage because a BIBOP style allocator may have a larger
working set than otherwise.
If we are to speak about actual, and not just _legal_ C/C++ programs,
*some* programs do things that are illegal (far fewer than is commonly
thought of), but those same C++ programs will not fail under
conservative garbage collection, they will just accumulate more
unreclaimed garbage, and on average not much of it.
The state of the art seems to be that even if clever reference counting
and sliding compaction are competitive with garbage collection, the
facts that you still need a collector alongside reference counting to
reclaim cycles, and that a copying collector can be tuned to optimally
pack objects for maximum locality of reference, mean that _in general_ a
copying compacting incremental collector will be simpler and perform
better.
Also, _even for C/C++_ there is no need to use simple reference counting
-- maybe Johnson is indeed using all the nice tricks (mostly discovered
or used by the Xerox people for their DORADO implementation) to make it
a much lower overhead technique than is commonly thought of. Or maybe
not, and he is using reference counting as illustrated in most C++
books.
Either way, I think that he should not be doing his own storage
reclamation at all, reference counting or garbage collection or
whatever, not any more than he should be doing his own storage
allocation, first fit or cartesian trees or BIBOP or whatever, unless he
is doing research on *this* subject, or has some *very* special
requirements. Otherwise he had better rely on some system programmer
having done the proper thing in some library.
This system programmer will have had the difficult task of making some
design choice after reading the abundant literature on the issue, and
here we have some serious problems. My own reckoning is that it is hard
to beat Baker's incremental collector or one of its derivatives, unless
one has very particular requirements (e.g. OS kernel), in which case one
should ponder things very carefully.
For example in some cases manual storage reclamation *may* be workable
and efficient, just as manual storage allocation may be, usually those where
reference counting or garbage collection are not necessary, because the
reclaimability of an object is implicit in the overall data structure in
which it is linked (e.g. if it is a tree or a forest of trees).
--
Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk