Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.lang.c++ Subject: Re: Smart pointers and stupid people (was: garbag Message-ID: <70353@microsoft.UUCP> Date: 31 Jan 91 18:53:34 GMT References: <4127@osc.COM> <3344@lupine.NCD.COM> <4175@osc.COM> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Distribution: comp Organization: Microsoft Corp., Redmond WA Lines: 65 In article <4175@osc.COM> tma@osc.UUCP (Tim Atkins) writes: |It is precisely the assumption of "dead" that makes object relocation such |a nightmare in a an untagged environment. Most compilers and optimizers |work hard at not putting pointers and other intermediate products in valuable |register and less valuable stack space UNLESS they expect to reuse them |in the near future. However, there is no guarantee that an operation that |invalidates those stored intermediaries such as a copying GC will not occur |before the reuse without the compiler being any the wiser. If it occurs then |the subsequent use must be restricted not from the user but from the |generated code! If there is some unknown magic for doing this outside |of changing the compiler then I am not aware of it. Also, I would expect |such magic to make the code decidedly less efficient if it did exist. Such "magic" does exist. It need not make code much "less efficient" than the relatively minor inefficiencies already designed into C++. Note that if GC is forced to occur only when it is known that there are no such intermediaries in existance, or if GC doesn't move any objects that could be being referred to by such intermediaries, then there is no problem. Both these approaches are frequently pretty easy to implement. |The only other, and the traditional, option is to change these stored pointers |which brings us right back to the problem of knowing a real pointer from |some arbitrary data with the same bit pattern. Various semi-solutions have |been proposed but I would argue that only a compiler could be expected to |do the job without overburdening the user. I disagree with the "overburdening" part of the argument. In one limit, a GC scheme could choose to never move objects. Then there is no burden on the user to know where pointers are. So, at least one GC design choice is *not* overburdening. The question then becomes, how many *other* GC design choices are not overburdening? And what kinds of applications do these various GC schemes represent good design trade-offs for? In general, more efficient GC schemes require more work -- either from the programmers of the compiler, or programmers of the code compiled by that compiler. How efficient a GC scheme needs to be is critically dependent on what it is you're trying to do. In some applications, GC can be _truly_ trivial. I claim that there are lots of GC schemes that can work perfectly well in lots of applications, though I know of no scheme that will work in all applications. Note that there is no rule that says one must implement GC for all one's objects -- schemes that only perform GC on certain classes will solve the problem for some applications. Reference counted string classes being one pervasive, if silly, example. You do correctly point out the central issue in "conservative" garbage collection schemes: If one has to "conservatively" guess that some location *might* contain a pointer, then you can't move the *maybe* referenced object, because you can't update the location, because it *might not* contain a pointer. The important design choice is: Are my classes going to use GC or not? Using GC or not leads to pervasive changes in how one writes and thinks about software. If you don't believe this, spend a week or two writing little programs, ignoring issues of memory reclamation, and *pretend* that a GC is cleaning up after you. The freedom to design and use new data structures is tremendous. The exact details of what GC scheme to use are relatively unimportant design issues. GC or not GC is the real question. What the C++ community needs to be working on is ways to abstract-out issues of GC and memory management from other aspects of class design, so that class libraries are not "hard-wired" to one or another memory management or GC schemes.