From 8528473257358359652 X-Google-Thread: f78e5,480a31feed3c6a1b X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: SeeWebsiteForEmail@moderncppdesign.com (Andrei Alexandrescu) Newsgroups: comp.std.c++ Subject: Re: boost::shared_ptr revisited again Date: Fri, 10 Jun 2005 23:34:26 GMT Organization: Computer Science & Engineering, U of Washington, Seattle Lines: 76 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <4299DE64.40403@poczta.onet.pl><3g55jqFajuhcU1@news.dfncis.de> <1118144437.192255.257840@g47g2000cwa.googlegroups.com> <878y1j9syu.fsf@ NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.demon.co.uk 1118446472 15053 158.152.254.254 (10 Jun 2005 23:34:32 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 10 Jun 2005 23:34:32 +0000 (UTC) X-Nntp-Posting-Host: tisbe.cs.washington.edu X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.1 X-Accept-Language: en-us, en X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Path: comp-std-cpp-robomod!not-for-mail X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id j5ANYQOA008561; Sat, 11 Jun 2005 09:34:26 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:5076 kanze@gabi-soft.fr wrote: > I'm not sure what I have to do with it. It doesn't take any > particularly great level of competence to add a isValid member > to the data, and an assert(isValid) as the first line in all > member functions. Yes indeed. And in a GC system, you can be sure that that isValid bit is your object's, not some random object that happens to be in memory at the location of the defunct object we think is there. > Personally, I don't see this as an argument either for or > against garbage collection. If an object must be explicitly > invalidated (disposed of, destructed, etc.), then you must do so > explicitly. Garbage collection or not. And of course, whether > the operator is called delete, and frees the underlying raw > memory as well, or is called dispose(), and the underlying raw > memory is only collected later, changes absolutely nothing in > your source code. (Not all objects are like this, and of > course, garbage collection reduces the amount of code you have > to write for other types of objects.) Allow me to try to change your opinion. I will do so by actually quoting --- typing by hand! that ought to be appreciated! :o) --- from Benjamin Pierce's classic "Types and Programming Languages", page 158: ----------------- A last issue that we should mentione before we move on formalizing references is storage deallocation. We have not provided any primitives for freeing reference cells when they are no longer needed. Instead, like many modern languages (including ML and Java) we rely on the run-time system to perform garbage collection, collecting and reusing cells that can no longer be reached by the program. This is not just a question of taste in language design; it is extremely difficult to achieve type safety in the presence of an explicit deallocation operation. The reason for this is the familiar dangling reference problem: we allocate a cell holding a number, save a reference to it in some data structure, use it for a while, ----------------- .here comes the interesting part, James, read on... ----------------- then deallocate it and allocate a new cell holding a boolean, possibly reusing the same storage. Now we can have two names for the same storage cell --- one for with type Ref Nat and the other with type Ref Bool. ----------------- > With regards to the discussion concerning garbage collection, > the only relevance I can see is in the fact that garbage > collection usually results in a process using more memory. As shown above, there is some more relevance in that explicit deallocation can readily lead to violations of type safety, while GC never has that problem. Disposing of other resources than memory deterministically is definitely a good thing to do, but you see, memory has a special status in that it is the flatbed of everything, and the cradle of type safety. Try to write to a closed file, and you'll get an error response --- big-o deal-o; but mess with memory, and you'll violate every single tenet of your program. Some of the people who hate GC don't realize, or (worse) don't care for the benefit above, consider GC the appanage (2nd time I got to use this word today :o)) of lazy programmers and go on to focus on the costs alone. Yes, there are costs. But the benefits must be understood. Andrei --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]