-
scared of malloc...
i'm always scared that malloc will fail and that i need a super clean shut down procedure [which can be used from any nested sequence of mallocs during nested function calls]... so is it a good idea to allocate a big ole' chunk o' memory at the very first then distribute that amongst pointers? is this the best way to go about it? also, if i do this, i can use varying base pointer types, correct? thank you...
-
Well if you are using EMS that's kind of the way you do it, but probably not in DJGPP. How would you know how much memory to allocate? As long as you call free for every malloc you should not have any problems. If you are using classes just make sure all your classes have a destructor (not always necessary in every instance - but just to be safe) that release memory allocated with new. If you do that, then you should have a safe clean shut down. You are wanting to statically allocate a huge chunk of memory at startup and then portion it out to those that need it. Dynamic allocation is a better method for memory management - but as always you can use both which is probably the best method. In your method you would want to register an atexit() function that cleaned up the memory. Yes you can use varying base pointer types by using typecasts. But, using new and delete, the type is already known.
Are you still using malloc after my long post about using new and delete? To think.....all my typing effort wasted.:)
-
oh yeah that's right, by now i should have C++onverted even more by using new/delete... but those could fail too right? [i specifically mean new/malloc not delete/free...] and maybe those are more well documented... y'know bubba, you'd better search for that post so i can just html complete save it to my hd for, eventually, future reference... [i'll be searching too...] thanks!
-
da, just a note about your site...need to fix the line
font color="#000000
to
font color="#000000" (the missing " was causing the code to display).
-
Well I'll look for it. You haven't converted to C and I haven't taken the time to read my HTML book. Translation: You have a website and I don't.
It looks very easy, but I guess I'm either too lazy or too uninterested. Maybe I'll dig into it and get my own site up and running...........maybe.
It's so hard to program over the holidays. Been gaming (relaxing) too much.
:p
-
OOOPS!!
I meant you haven't converted to C++.
Wishing the earth would swallow me whole about now. Slaps self. Walks out of the room quietly.
-
>> It's so hard to program over the holidays. Been gaming (relaxing) too much. <<
Let's just say I'm living a "Half-life"...
-
>Translation:
i have a 'site'... but i am lazy... but i do have the book! but it's 3.0... and i DO use ++!!! just not new/delete of it! :) what'dja think? how the heck could i have created amanda? :)
[edit 1]
i mean, organization wise... nested classes and extended scope rules are a must! :)
-
What is to be afraid of with malloc() ? Is it just that you don't understand how it works, or the way memory gets used up? Sorry the questions are basic, but I'm a little shocked at your statement...
To be blunt: The only reasons you will run out of memory (and cause a malloc() call to fail) is--
a) Your heap is not large enough to begin with
b) You use excessive recursion and need a bigger heap
c) You have a memory leak using up your heap
d) your stack chain is growing into your code
e) You are not deallocating malloc()'d pointers (dangling pointers)
All are resolved by:
a) knowing how big your object code is-- whatever size your .exe is is pretty close to *all your code being loaded*.
b) Heap size is specified in your makefile or compiler project window
c) Stack size is specified in your makefile or compiler project window
d) You know how much data your going to malloc() when you design your code...
So:
heap = (exe_size + heap size + estimated_malloc()s + free)
where:
free = additional you might expect you need or want to keep in reserve (such as 100K).
---
enjoy.
-
okay thanks. there are just a few critical allocations that need to be made [to provide the programs' functionality] and every other allocation is marginal, in that it's just used to provide more interesting output [and can be avoided of no extra memory is availiable]. and i've never seen a faillure in my correct usage of the allocation procedures, so i guess i'm fine.