realloc's design
in [C++]
|
Prev: hash_map
Next: reading entire file to a string
From: baibaichen on 17 Nov 2005 06:05 In sutter's C++ Coding Standards, he has gave realloc as an example in item5, he said "In Standard C, realloc is a infamous example of bad design. it has to do too many things: ..., it is not easily extensible. it is widely viewed as a shortsighted design failure." why the realloc is the bad design? From the user's view, this design is quite useful! For void *realloc(pblock, newsize), these are the Special ANSI Requirements (1) realloc(NULL, newsize) is equivalent to malloc(newsize) (2) realloc(pblock, 0) is equivalent to free(pblock) (except that NULL is returned) (3) if the realloc() fails, the object pointed to by pblock is left unchanged could someone give me more inforamation or reference about this issue? Thanks Chang [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Ulrich Eckhardt on 17 Nov 2005 18:56 baibaichen wrote: > In sutter's C++ Coding Standards, he has gave realloc as an example in > item5, he said > > "In Standard C, realloc is a infamous example of bad design. it has to > do too many things: ..., it is not easily extensible. it is widely > viewed as a shortsighted design failure." > > why the realloc is the bad design? From the user's view, this design > is quite useful! I know that there are several criticisms on realloc/malloc/free: 1. There is no way to query the size of an allocated block. This information must be present, but it can't be queried by the user that therefore always needs to be passed alongside, either explicitly or implied by e.g. the type. 2. There is no way to use realloc for C++ objects in general because it might contain pointers to itself. It would therefore be much better if one could e.g. request a resize that does not involve reallocation and copying. Also, querying how large this memory block could be made would be useful. These are only deficiencies, not straight design bugs though, so I can't comment on what exactly he meant. Uli [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Hyman Rosen on 17 Nov 2005 18:58 baibaichen wrote: > why the realloc is the bad design? It fails to separate the following two possible outcomes when increasing the size: 1) Lenghthen the size of the memory area pointed to by pblock. 2) Allocate a separate area of the new length, and copy over the old data. Ideally, you would want to increase length in two phases: 1) Increase size in place. 2) If (1) fails, allocate new area and copy and free old one. Especially in C++, operation (2) needs to be done at the language level, not with a memcpy. As it stands, you cannot even check to see what happened. The following code void *oldp = p; p = realloc(p, newsize); if (p != oldp) ... yields undefined behavior if in fact p is different than the old value! I suppose you could tinker with arrays of char, unsigned char oldp[sizeof(p)]; memcpy(oldp, &p, sizeof(p)); p = realloc(p, newsize); if (memcmp(oldp, &p) == 0) ... but that's not portable because pointers which are == are not necessarily the same bit-for-bit. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Antoun Kanawati on 17 Nov 2005 19:00 baibaichen wrote: > In sutter's C++ Coding Standards, he has gave realloc as an example in > item5, he said > > "In Standard C, realloc is a infamous example of bad design. it has to > do too many things: ..., it is not easily extensible. it is widely > viewed as a shortsighted design failure." > > why the realloc is the bad design? From the user's view, this design > is quite useful! > > For void *realloc(pblock, newsize), these are the Special ANSI > Requirements > (1) realloc(NULL, newsize) is equivalent to malloc(newsize) > (2) realloc(pblock, 0) is equivalent to free(pblock) (except that NULL > is returned) > (3) if the realloc() fails, the object pointed to by pblock is left > unchanged > > could someone give me more inforamation or reference about this issue? <imho> The missing piece is "bool resize_in_place(void *,size_t)" which would allow you to adjust the size of a block, without potentially moving it to a new address. This can reduce pointer-related headaches siginificantly, and allows the programmer a wider range of options to handle relocation of data. </imho> -- A. Kanawati NO.antounk.SPAM(a)comcast.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Ben Hutchings on 17 Nov 2005 19:02
<baibaichen(a)gmail.com> wrote: > In sutter's C++ Coding Standards, he has gave realloc as an example in > item5, he said > > "In Standard C, realloc is a infamous example of bad design. it has to > do too many things: ..., it is not easily extensible. it is widely > viewed as a shortsighted design failure." > > why the realloc is the bad design? From the user's view, this design > is quite useful! > > For void *realloc(pblock, newsize), these are the Special ANSI > Requirements > (1) realloc(NULL, newsize) is equivalent to malloc(newsize) > (2) realloc(pblock, 0) is equivalent to free(pblock) (except that NULL > is returned) > (3) if the realloc() fails, the object pointed to by pblock is left > unchanged > > could someone give me more inforamation or reference about this issue? The special cases (1) and (2) duplicate existing functions. In case (3), the obvious usage pblock = realloc(pblock, newsize) will leak memory; one must use an additional temporary variable to avoid this. In the usual case, realloc may succeed either by extending the block or allocating a new one. You can't tell in advance which it will do, so there is no way to do anything other than a simple memcpy in case of reallocation. In C it may be possible to fix up the results afterwards, but this is a kluge. In C++ this should be done by copy-constructors (or in future move-constructors), and it's too late to call them when realloc returns. -- Ben Hutchings Having problems with C++ templates? Your questions may be answered by <http://womble.decadentplace.org.uk/c++/template-faq.html>. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |