TC> Well, might be a) but also d) I learned a lot in my stay in the C_ECHO 
and
 TC> seemed to retained some* of it during my absence. ;) 
:-)
 TC> Also I happen to have a
 TC> couple local Wizards who help me out from time to time (*nix ones at 
that!
That's always helpful.
 TC> oriented lately. But I'm far from c) (that may have 
 TC> different implications ;)
Hmmm... :-)
 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.
 TC> I hate to have to use virtual ram techniques in my 
 TC> program.  I have written a
As you said, it makes messy code, so I don't bother.  However, when you're 
running in ring 0 of the protected mode of the 286+ chip, it isn't quite as 
messy as one would otherwise have to do.  I could imagine that it would be 
very clean, actually.  I also would imagine that DOS extenders do something 
similar, too.
 TC> all this automagically,
 TC> but IMHO, there's no point in adding to the problem by 
 TC> causing it to have* to
 TC> swap.  That's why I'm still stingy with memory.  For a text viewer, for
I just usually ignore memory considerations.  If I use 2 or 3 meg, not a big 
deal in the grand scheme of things.  However, I will use dynamic memory - 
using what I need, and keeping it down.  I just generally don't worry about 
how much it is I need.
 TC> Well, turned out I found that using a static variable 
 TC> was the answer in one
 TC> case.  However, that static variable will take up 
 TC> "permanent" space of sorts.
 TC> It's not much, but it still is enough to bug me.
4 bytes?  Should never be a big deal.  I've used thousands of bytes of static 
memory... not a big deal.  If:
   - it makes your code cleaner,
   - it makes your executable noticeably faster
then it is a good thing.  Especially the first one.  :-)
 TC> Now with pages, sounds like you have to free the whole 
 TC> friggin' page to free a
 TC> small block.  To me that's a waste.  That 4K page 
Pages are a function of the hardware - not much can be done about that.
 TC> should* shrink down to size
 TC> to compensate for the freeing of the small block.  However, I know that 
in
Again, since pages are functions of hardware, it can't be done.  It's not the 
design of the OS, but the design of the hardware.
 TC> some OSs that's just not a possiblity due to design, 
 TC> etc.  Unless you code in
 TC> something to detect memory fragments, etc.  and 
 TC> optimize the page(s), but why
 TC> bother.  :/ I think that should* be the OS's job.
If I(the OS) moved memory around on you(the user program), what would your 
pointers be good for anymore?  Everything has moved!
 TC> I think they do, but I don't know about Linux (which I may do some 
playing
 TC> around in) or Win95. As for what you described, what 
 TC> about realloc()? That I
 TC> heard about where you can probably make the memory area 
 TC> larger or smaller and
 TC> still use the same space (or most of it)? While we are 
If there is space available, realloc *CAN* (but doesn't have to) use it to 
grow.  When it shrinks, it can *NOT* move other memory around to use up the 
extra space created.
 TC> discussing it, maybe
 TC> you could tell me how that works?
What other questions?  Oh, and I try to avoid realloc at almost all costs.  
It's worse than goto in my books.  :-)
---
---------------