TIP: Click on subject to list as thread! ANSI
echo: c_echo
to: DARIN MCBRIDE
from: TIKA CARR
date: 1998-01-20 18:23:00
subject: free(question)

 TC> I strongly recommend against "mass allocation/deallocation"
 TC> because IMHO, you can run into lots of trouble with memory leaks and
 TC> holes. I like to deallocate
 DM> Either:
 DM> a) You've learned alot in your absence from the C_ECHO there, or
 DM> b) You've learned alot since you got back to the C_ECHO, or
 DM> c) You're a natural.  ;-)
Well, might be a) but also d) I learned a lot in my stay in the C_ECHO and
seemed to retained some* of it during my absence. ;) Also I happen to have a
couple local Wizards who help me out from time to time (*nix ones at that!
) One friend and his wife (who's also a close friend of mine) drop in 
bout
once a month for a visit and we often "talk shop". Also been experimenting 
nd
thinking of the logistics of it all, and since getting Win95, and playing 
ith
Visual Basic 3.0, Linux, and other things, I guess I've become more technical
oriented lately. But I'm far from c) (that may have different implications ;)
 DM> Well, there are a lot of considerations here.  Extraneously allocated
 DM> memory in 32-bit systems (Win32, OS/2, DOS32) can be swapped out of
 DM> memory to disk. This disk swapping (and the swapping back in if you
 DM> merely free it) can slow down the system.
I hate to have to use virtual ram techniques in my program.  I have written a
few DOS programs in another lanuguage where I considered using a file for
swapping out some data and back in as needed.  As you say, it slows things.
It also makes for messy code.  :( I know some OSs do all this automagically,
but IMHO, there's no point in adding to the problem by causing it to have* to
swap.  That's why I'm still stingy with memory.  For a text viewer, for
example, I'd find the size of the file, and allocate the memory needed for 
t,
rather than allocating a fixed amount.  I guess I'm learning more about the
benefits of using dynamically allocated memory :)
 DM> Or, if you are no longer using a small block of memory in a 4k page,
 DM> it can slow things down whether free'd or not.
That's a problem I happen to have in a little routine I had help with in this
Echo. Denis Boyles and Auke Reitsma (and I think others) helped me find a way
to preserve some registers in MS QC while making a call to an inline assembly
routine I wanted to use to read the VGA font table and return the pointer to.
Well, turned out I found that using a static variable was the answer in one
case.  However, that static variable will take up "permanent" space of sorts.
It's not much, but it still is enough to bug me.
Now with pages, sounds like you have to free the whole friggin' page to free 

small block.  To me that's a waste.  That 4K page should* shrink down to size
to compensate for the freeing of the small block.  However, I know that in
some OSs that's just not a possiblity due to design, etc.  Unless you code in
something to detect memory fragments, etc.  and optimize the page(s), but why
bother.  :/ I think that should* be the OS's job.
 DM> However, if you have a 32-byte chunk of memory you no longer need, and
 DM> need to allocate <32 bytes, you're best off to free the original chunk
 DM> and allocate the new chunk to "save space."  However, no one guarantees
 DM> that malloc will use the just-freed memory... (I think DOS compilers
 DM> usually do, mostly because of the 640k limit)
I think they do, but I don't know about Linux (which I may do some playing
around in) or Win95. As for what you described, what about realloc()? That I
heard about where you can probably make the memory area larger or smaller and
still use the same space (or most of it)? While we are discussing it, maybe
you could tell me how that works?
Tika
... The young know the rules, the old know the exceptions!
___ Blue Wave/DOS v2.30
--- QScan/PCB v1.17b / 01-0406
---------------
* Origin: Knight Moves - Rochester,NY 716-865-2106 (1:2613/313)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.