From -5077744942435077471 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,2847ea2daacb5072 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2004-04-21 12:33:08 PST Path: archiver1.google.com!news1.google.com!news.glorb.com!border1.nntp.ash.giganews.com!nntp.giganews.com!newshosting.com!nx01.iad01.newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: stephenPOINThoweATtns-globalPOINTcom@eu.uu.net ("Stephen Howe") Newsgroups: comp.std.c++ Subject: Re: Proposal: free() and delete/delete[] compatibility Date: Wed, 21 Apr 2004 19:33:06 +0000 (UTC) Lines: 70 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <408677a9$0$26189$ed9e5944@reading.news.pipex.net> References: <8b42afac.0404190833.18bdf219@posting.google.com> <8b42afac.0404200949.74388665@posting.google.com> X-Trace: mail2news.demon.co.uk 1082575986 21516 10.0.0.1 (21 Apr 2004 19:33:06 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 21 Apr 2004 19:33:06 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 1BGNSz-0005as-00 for mail2news@news.news.demon.net; Wed, 21 Apr 2004 19:33:06 +0000 X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP id i3LJX2i2001571; Thu, 22 Apr 2004 05:33:02 +1000 (EST) X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i3LJX293001562; Thu, 22 Apr 2004 05:33:02 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ucar.edu X-Reply-To: "Stephen Howe" X-Newsgroups: comp.std.c++ X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NNTP-Posting-Date: 21 Apr 2004 13:31:21 GMT X-Spam-Checker-Version: SpamAssassin 2.60-mulga_r1 (1.212-2003-09-23-exp) on mulga.cs.mu.OZ.AU X-Spam-Status: No, hits=0.7 required=5.2 tests=PRIORITY_NO_NAME autolearn=no version=2.60-mulga_r1 Xref: archiver1.google.com comp.std.c++:1828 > My proposal is aimed towards POD types which i forgot to mention. Then I suggest you work at your proposals a little harder. Don't just post here proposals where you have put a few seconds thought into it and expect the newsgroup to pick at obvious holes in your proposal; holes that you should have thought of and countered. There is a chapter in Stroustrups Design and Evolution of C++ where he talks about design considerations for candidate proposals. You should look at these and before submitting a proposal here, you spend time considering To me, your proposal does not look well considered. My points: 1) delete is designed to dispose of single objects created by new delete[] is designed to dispose of an array of objects created by new[] And that means somehow with new[], the system has to keep track of how many objects were created so that when delete[] is called, the correct number of destructors is called. One of the ways that may be done by a vendor is that new[] may allocate a bit more memory to keep track of the number of objects created. In your proposal, how will free() know that it is dealing with a single object allocated by new compared to an array of objects allocated by new[] ? One way would be to make new equivalent to doing new[1] but by so doing, that means new is now wasteful and inefficient. Further, it seems to me, that the compiler & library will have to do some pointer thunking because free() only knows how to deal with block of memory allocated by malloc() etc and therefore, pointers allocated by new/new[] will have to be adjusted to be same as what malloc() would return before free() is called 2) AFAIK, the standard is such that new/delete/delete[] maybe implemented on the back of malloc()/calloc()/realloc()/free() but the vendor is free to choose differently. Your proposal would mean that the vendor has less freedom of implementation. The vendor before could supply an optimised version of new/new[]/delete/delete[] that is independent of malloc() etc. Now they cannot. You should have thought of 1) and 2) objections and made sure that the answers were in your original proposal. Here is an ill-thought proposal that I could make here: Alter the standard so that setjmp() and longjmp() work and that if you longjmp() back to previous valid setjmp() position, all local objects destructors are correctly called. Looks marvelous does it not? Great for newbie programmers as well - they can longjmp() away without worrying about local objects on stacks being correctly destroyed - the standard will guarantee that they will be. But what is the price of such a guarantee? The price is that function like longjmp() is reasonably simple under the hood - it just restores enough of the environment context to continue at the point where setjmp(). Now it has the additional burden of making sure that all the local objects destructors are called as it wanders up the stack back to where setjmp() is called. And there is a perfectly reasonable alternative for C++ programmers to use, namely try-catch. Stephen Howe --- [ 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 ]