brett@wjvax.UUCP (Brett Galloway) (02/04/88)
In article <1988Feb1.182545.12952@jarvis.csri.toronto.edu> flaps@csri.toronto.edu (Alan J Rosenthal) writes: > >In article <1209@wjvax.UUCP> I wrote: >[ on: having a function to return the amount of size in a malloc'd block ] >>All implementations of malloc() will give you *at least* the amount of >>room you asked for; many will give you more. I have several >>applications where I could make more efficient use of space if I knew >>how much space malloc() actually gave me. ... > >I don't see why this would save you time. > >If the value you call realloc() with is greater than the malloc() value >but less than the amount actually allocated, obviously nothing will >happen ... [example form SUN OS 3.3] It does save you the call to realloc() ... Actually, cases where one will malloc() and then realloc() repeatedly are not the best example why a malloc() that returned the actual size allocated would be useful (despite the fact that that's the example I gave). A better example is a related case. I have an application where I am accumulating an indefinite number of items. One way to solve this would be to use malloc() ... realloc() ... realloc() as required. However, as the size grows, performance gets worse and worse. An opposite extreme solution is to allocate single items on a linked list. But that incurs substantial overhead. My middle solution was to allocate nodes on a linked list that stored some quantity of items per node. It would be more efficient if I could know when more items would fit in a node than I asked for. -- ------------- Brett D. Galloway {ac6,calma,cerebus,isi,isieng,pyramid,tymix}!wjvax!brett