C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Why no size_t to ::operator delete? Goto page 1, 2, 3  Next          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Scott Meyers Guest Posted: Sat Dec 23, 2006 7:33 am    Post subject: Why no size_t to ::operator delete? 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? Thanks, Scott --- [ 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 ] Back to top Lucas Galfaso Guest Posted: Sat Dec 23, 2006 2:58 pm    Post subject: Re: Why no size_t to ::operator delete? Scott Meyers wrote: Quote: Can someone explain to me why having the "normal" operator delete take a size_t is impractical? The answer is simple, there is nowhere to store this information, if you need it, you store it. This is just another example of C++ of not to make everybody pays for what just a few need. Regards, Lucas Quote: Thanks, Scott ] --- [ 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 ] Back to top P.J. Plauger Guest Posted: Sun Dec 24, 2006 1:00 am    Post subject: Re: Why no size_t to ::operator delete? "Scott Meyers" <usenet (AT) aristeia (DOT) com> wrote in message news:12omt8jit7rl379 (AT) corp (DOT) supernews.com... Quote: 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 ] Back to top Mathias Gaunard Guest Posted: Sun Dec 24, 2006 1:28 am    Post subject: Re: Why no size_t to ::operator delete? Scott Meyers wrote: Quote: 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. new is sure of the type, delete is not. Quote: 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. Just use an allocator directly instead of new/delete. --- [ 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 ] Back to top Scott Meyers Guest Posted: Sun Dec 24, 2006 3:10 am    Post subject: Re: Why no size_t to ::operator delete? P.J. Plauger wrote: Quote: It's another thing to get wrong. I don't see how it's any more error-prone than the class-specific version of operator delete that takes a size. Quote: 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. I don't believe this is the case; see my reply to Lucas Galfaso's post. Quote: 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, The situation in question is strict LIFO allocation, but not all objects are of the same size. Hence the need for the deallocator to know how big each allocation is. Storing the size of each object is clearly possible, but my contention is that it is not necessary, per my earlier posts. Scott --- [ 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 ] Back to top Andrew Koenig Guest Posted: Sun Dec 24, 2006 7:28 am    Post subject: Re: Why no size_t to ::operator delete? "Scott Meyers" <usenet (AT) aristeia (DOT) com> wrote in message news:12omt8jit7rl379 (AT) corp (DOT) supernews.com... Quote: 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? Because if it did, what would it mean? 1) If it means "Free just this much memory and leave the rest unallocated", then it becomes impossible to implement new/delete in terms of malloc/free. 2) If it can be ignored, which would appear to be necessary to use malloc/free for allocation, then what's the point? Many moons ago I tried to convince the C++ community that there would be much to gain from abandoning malloc/free, but I could never find anyone willing even to consider it seriously. --- [ 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 ] Back to top jam Guest Posted: Sun Dec 24, 2006 4:42 pm    Post subject: Re: Why no size_t to ::operator delete? On Dec 24, 4:28 am, a...@acm.org ("Andrew Koenig") wrote: Quote: "Scott Meyers" <use...@aristeia.com> wrote in messagenews:12omt8jit7rl379 (AT) corp (DOT) 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?Because if it did, what would it mean? 1) If it means "Free just this much memory and leave the rest unallocated", then it becomes impossible to implement new/delete in terms of malloc/free. 2) If it can be ignored, which would appear to be necessary to use malloc/free for allocation, then what's the point? Many moons ago I tried to convince the C++ community that there would be much to gain from abandoning malloc/free, but I could never find anyone willing even to consider it seriously. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-...@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ:http://www.comeaucomputing.com/csc/faq.html ] I am an amatuer programmer who started from C.I am convinced now that C++`s dynamic memory management mechanism can be much better than what it is .I have got good ideas I do not know where to submit.It envolves minamal backward compatible syntax corrections already implemented on some platforms.I beleive that the couple keywords "new/delete" can be decreased to one keyword ;in my suggestion a keyword for deleting is unnecessary(this does not mean that dealocation will not take place).I appreciate any advise. regards F Mehrabi --- [ 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 ] Back to top Guest Posted: Sun Dec 24, 2006 5:43 pm    Post subject: Re: Why no size_t to ::operator delete? Scott Meyers wrote: Quote: 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. Could they not write a template to call their stack alloc func, placement new, and another template to explicitly call desctructor, stack free func? Quote: 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? I think for this to make sense the delete [] operator would have to be change to require the dimension of the array, which I think I read in some book by Dr. Stroustrup was considered but rejected. --- [ 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 ] Back to top Greg Herlihy Guest Posted: Sun Dec 24, 2006 5:45 pm    Post subject: Re: Why no size_t to ::operator delete? Scott Meyers wrote: Quote: Can someone explain to me why having the "normal" operator delete take a size_t is impractical? Since the implementation of a class-specific delete operator always has the option of calling the global delete operator to perform the actual deallocation, a class delete operator does have a good excuse for not knowing the actual size of the block being deleted. Therefore, knowing the size of the original allocation request very well could be information that the class delete operator could not otherwise find out on its own. The global delete operator has no comparable back-up, there is no other delete routine that it can call to free the memory - global delete must free the block itself. And in order to free the block, the global delete operator must know the size of the actual allocation; knowing just the requested size alone (the value of the size parameter) is not enough information to free the block. Even assuming that the value of the size parameter is accurate in the first place. After all, the correctness of a program's memory management should not depend upon the faithful preservation of data points that are needlessly round-tripped through the user program, or so I would think. Greg --- [ 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 ] Back to top Scott Meyers Guest Posted: Sun Dec 24, 2006 10:42 pm    Post subject: Re: Why no size_t to ::operator delete? Andrew Koenig wrote: Quote: Because if it did, what would it mean? The same thing it means for a per-class deallocator: please deallocate the chunk of memory pointed to by this pointer; you can assume that the size indicated is correct for the chunk. (Actually, now that I look for it, I can't find anything in the standard (at least not in 3.7.3.2 or 5.3.5 or 12.5) that specifies the semantics of the size_t argument. I've always assumed it was the size of the chunk that should be deallocated if UB was to be avoided.) Scott --- [ 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 ] Back to top Scott Meyers Guest Posted: Sun Dec 24, 2006 11:43 pm    Post subject: Re: Why no size_t to ::operator delete? Lucas Galfaso wrote: Quote: Scott Meyers wrote: Can someone explain to me why having the "normal" operator delete take a size_t is impractical? The answer is simple, there is nowhere to store this information, if you need it, you store it. This is just another example of C++ of not to make everybody pays for what just a few need. One of us is missing something. At class scope, operator delete may take a size_t. If it does, it's provided by the compiler, which passes the size of the object. The information is not "stored" in the sense of a memory location holding the size -- the compiler passes a constant. If a pointer to a derived object via a base class pointer is being deleted and the base destructor is not virtual, the wrong size gets passed, but that's okay, behavior under those conditions is undefined. You can only delete three things: a pointer to a class type, a pointer to a non-class type, and a void*. My suggestion was that a global operator delete taking a size_t could: - For pointers to class types, get the same value that'd be passed to a class-specific operator delete taking a size. - For a pointer p to a non-class type, sizeof(*p). - for a void* pointer, zero. None of these options requires storing anything anywhere. Scott --- [ 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 ] Back to top Scott Meyers Guest Posted: Mon Dec 25, 2006 5:43 am    Post subject: Re: Why no size_t to ::operator delete? wkaras (AT) yahoo (DOT) com wrote: Quote: Could they not write a template to call their stack alloc func, placement new, and another template to explicitly call desctructor, stack free func? Sure, but they'd have to explicitly pass the size, which they would not have to do if the compiler would pass it for them. The interesting issue here is that this feature already exists for class-specific operator delete, so the question is why it doesn't or should also exist for global operator delete. Quote: Can someone explain to me why having the "normal" operator delete take a size_t is impractical? I think for this to make sense the delete [] operator would have to be change to require the dimension of the array, which I think I read in some book by Dr. Stroustrup was considered but rejected. The delete operator already has to have access to the number of elements in an array, at least for types with nontrivial destructors, so it could pass it through to operator delete, but I agree, the situation for operator delete[] is probably more complicated than for operator delete. Scott --- [ 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 ] Back to top jam Guest Posted: Mon Dec 25, 2006 6:36 pm    Post subject: Re: Why no size_t to ::operator delete? Scott Meyers wrote: Quote: wkaras (AT) yahoo (DOT) com wrote: Could they not write a template to call their stack alloc func, placement new, and another template to explicitly call desctructor, stack free func? Sure, but they'd have to explicitly pass the size, which they would not have to do if the compiler would pass it for them. The interesting issue here is that this feature already exists for class-specific operator delete, so the question is why it doesn't or should also exist for global operator delete. Can someone explain to me why having the "normal" operator delete take a size_t is impractical? I think for this to make sense the delete [] operator would have to be change to require the dimension of the array, which I think I read in some book by Dr. Stroustrup was considered but rejected. The delete operator already has to have access to the number of elements in an array, at least for types with nontrivial destructors, so it could pass it through to operator delete, but I agree, the situation for operator delete[] is probably more complicated than for operator delete. Scott --- [ 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 ] declare an empy class whose public templated constructor deletes the pointer passed to it and who delares operator delete of its own which devices the second size_t param too.use the constructor of this class to delete pointers --- [ 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 ] Back to top Lucas Galfaso Guest Posted: Mon Dec 25, 2006 6:37 pm    Post subject: Re: Why no size_t to ::operator delete? Scott Meyers wrote: Quote: Lucas Galfaso wrote: Scott Meyers wrote: Can someone explain to me why having the "normal" operator delete take a size_t is impractical? The answer is simple, there is nowhere to store this information, if you need it, you store it. This is just another example of C++ of not to make everybody pays for what just a few need. You can only delete three things: a pointer to a class type, a pointer to a non-class type, and a void*. My suggestion was that a global operator delete taking a size_t could: - For pointers to class types, get the same value that'd be passed to a class-specific operator delete taking a size. - For a pointer p to a non-class type, sizeof(*p). - for a void* pointer, zero. None of these options requires storing anything anywhere. Having that definition for an extra parameter for the global operator delete would be really a bad idea; The key is when you delete a void*. Say you have a pointer to a fundamental type, you cast it to void*, and you delete the casted pointer; What would you expect to happen? Lucas Quote: Scott --- [ 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 ] Back to top Scott Meyers Guest Posted: Mon Dec 25, 2006 7:25 pm    Post subject: Re: Why no size_t to ::operator delete? jam wrote: Quote: declare an empy class whose public templated constructor deletes the pointer passed to it and who delares operator delete of its own which devices the second size_t param too.use the constructor of this class to delete pointers I don't see how this can help. The class's operator delete will work only on pointers to objects of that type, not to random pointers (e.g. to pointers to built-in types). Scott --- [ 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 ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT Goto page 1, 2, 3  Next Page 1 of 3   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.