From 2909822595986278365 X-Google-Thread: f78e5,480a31feed3c6a1b X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!newshub.sdsu.edu!newshosting.com!nx02.iad01.newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!peer-uk.news.demon.net!kibo.news.demon.net!mutlu.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: jm@bourguet.org (Jean-Marc Bourguet) Newsgroups: comp.std.c++ Subject: Re: boost::shared_ptr revisited again Date: Wed, 8 Jun 2005 07:05:23 GMT Lines: 53 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> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.demon.co.uk 1118214328 27134 158.152.254.254 (8 Jun 2005 07:05:28 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 8 Jun 2005 07:05:28 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Original-Trace: 8 Jun 2005 00:00:11 -0700, cdssoph29.cadence.com X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Original-NNTP-Posting-Host: cdssoph29.cadence.com X-Received: By mx-sanjose.cadence.com as j5870Feg000146 at Wed Jun 8 00:00:20 2005 X-Path: comp-std-cpp-robomod!not-for-mail X-Delivered-To: std-c++@ucar.edu 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++:5029 "Andrei Alexandrescu (See Website For Email)" writes: > >> There are languages that eliminate all bad-pointer bugs. > >> Java, for one. > > But Java did eliminate all dangling pointer bugs. I don't see how a GC could possibly eliminate all dangling pointer bugs. In my experience, most of these are accessing objects which have been freed at the correct time but to which some pointers have been incorrectly kepts. In these cases, a GC would simply keep the objects alive, but the bugs would still be present (the consequences of the bugs change, sometimes for the worse -- silent wrong results instead of a crash -- sometimes for the best -- obvious wrong result instead of a security break). GC doesn't even elimitate all memory leaks in you use the term "memory leaks" in a broad enough sense like keeping objects around which will no more be accessed. > To clarify my response to the "runtime check": it is runtime, but if > it is done in hardware, it has zero time cost. More precisely, once it has been decided for other raisons to activate the features doing such checks, using them to trap null pointers has zero time cost. Completely desactivating virtual memory could have a gain. > My understanding of the context of the discussion was that we were > discussing that there is a price to the "runtime check". The > hardware trap mechanism costs only silicon on the chip, and zero > time. Simply increasing die size can have effects on the minimal cycle time achievable (increase of net length and capacitance, decrease of yield). And obviously depending on other features present and architectural choices (some things can be done in parallel, like cache checks -- but having a cache organized for virtual adress prevent sharing between process*), adding virtual memory would probably also have effects on latence and/or cycle time: there is simply more things to do for a memory access. (*) And security driven minds can consider this as a good effect as it reduce/supress one cover channel. -- Jean-Marc --- [ 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 ]