From 5958694350309398421 X-Google-Thread: f78e5,a10702d4a7db0a94 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!news.glorb.com!peer1.news.newnet.co.uk!194.159.246.34.MISMATCH!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: pjp@dinkumware.com ("P.J. Plauger") Newsgroups: comp.std.c++ Subject: Re: Why no size_t to ::operator delete? Date: Sat, 23 Dec 2006 19:00:33 GMT Lines: 58 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <12omt8jit7rl379@corp.supernews.com> NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1166900441 29116 158.152.254.254 (23 Dec 2006 19:00:41 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sat, 23 Dec 2006 19:00:41 +0000 (UTC) X-Original-To: std-c++@mailman.ucar.edu X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Priority: 3 X-RFC2646: Format=Flowed; Response X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au X-MSMail-Priority: Normal X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Received: (from fjh@localhost) by mulga.csse.unimelb.edu.au (8.13.8+Sun/8.13.8/Submit) id kBNJ0XXZ003670; Sun, 24 Dec 2006 06:00:33 +1100 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Sat, 23 Dec 2006 02:36:34 -0600 X-Delivered-To: std-c++@mailman.ucar.edu X-Postfilter: 1.3.32 X-Authentication-Warning: serv3.gc.dca.giganews.com: news set sender to poster@giganews.com using -f X-Newsreader: Microsoft Outlook Express 6.00.2900.3028 X-Newsgroups: comp.std.c++ Xref: g2news2.google.com comp.std.c++:5145 "Scott Meyers" wrote in message news:12omt8jit7rl379@corp.supernews.com... > I'm sure I used to know this once upon a time, but why doesn't the global > operator delete take a size_t argument specifying the size of the memory > chunk being freed? The ARM doesn't seem to say anything about this design > decision, and I don't know where else to look. > > The question arose recently when I was working with a team on an embedded > project, and it became clear that (1) dynamically allocated memory was a > reasonable design option for them and (2) they could guarantee that they'd > delete objects in the inverse order in which they'd be allocated. This > meant that they could use a stack allocator, so calling operator new for > an object of type T would simply increase the stack pointer by sizeof(T) > (modulo alignment issues) and calling operator delete would simply > decrease it by sizeof(T) (again modulo alignment issues). Unfortunately, > the global operator delete doesn't get the sizeof(T), and, unless I'm > overlooking something, the only way to get it is to store it somewhere, > which they didn't want to spend the memory to do. > > I can imagine specifying the global operator delete like this: > > void operator delete(void *p, size_t sz); > > such that an expression "delete E" that ultimately yields a call to > ::operator delete would pass sz as follows: > - For an expression E of class type, the same value that'd be passed to > typeof(E)::operator delete taking a size_t. > - For an expression E of non-class type T, sizeof(T). > - For an expression E of type void*, 0 (zero), meaning "size unknown". > > Can someone explain to me why having the "normal" operator delete take a > size_t is impractical? It's another thing to get wrong. And it's a false economy not to want to "spend the memory" to pack it with the allocated storage. You're storing the information *somewhere*, in some form. Okay, maybe a thousand items can all have the same compile-time constant size, which occupies just a field in one instruction. If that's an important part of your size budget, then you should be maintaining a LIFO array as a single block, IMO, not demanding that a general heap truckle to your particular needs. We've had decades of experience with heap management by now, and the learned wisdom is to let the heap maintain its own integrity as much as possible. That has proved to be the best general mechanism. P.J. Plauger Dinkumware, Ltd. http://www.dinkumware.com --- [ 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.comeaucomputing.com/csc/faq.html ]