Elysian Shadows

does any one have any tips for memory management?

cndr wrote:does any one have any tips for memory management?

What type of memory managment? Need more details.

any really, I'm trying to improve my coding, so anything as basic as ints take up more space than short ints, I'm new at memory management so any help would be great.

the amount of memory used (even by very larg programs) is typically pretty low. You really only have to worry about dynamic allocation, and that's only if you're forgetting to free A LOT of memory. Aside from that, it shouldn't be a major issue.

a crude way to see if you have a memory leak is too:

a) make sure every new has a delete (preventative)

b) watch your systems task manager resource usage. if it is going up over time, for your program, you may have a leak. remember when marcel's editor had sys req's of over a gig ram and they caught it in task manager? baha

With today's computers with gigabytes of memory, basic types wont make much difference no matter what you are trying. Even with embedded and hadnhelds and such, the amount of memory your using for basic types doesn't matter so much anymore. If it matters, you'll know anyway. I'd only think of it if you were doing a LARGE allocation of the same class, such as a particle manager, and even then I wouldn't think of it that much.

Or simply said: You'll know if you need to conserve the memory usage of your basic types.

The one thing I will suggest is to use references in place of pointers whenever possible. It's very easy to create a memory leak with pointers, and not so easy if it's even possible with references.

There's a few options available:

1. Use smart/shared pointer containers
2. Write a garbage collector
3. Explictly allocate & deallocate memory on demand

Using smart pointers gives you the advantage of regular pointers with automatic reference counting to destroy objects and deallocate the associated memory once no references to an object exist.

Garbage collection has the advantage of allocating memory is large chunks to reduce the overhead of single object allocations/deallocations and uses a set of heuristics to determine if memory is no longer in use.

Option 3 is what you should avoid unless you need strict control over how much memory your application is using (e.g. when dealing with embedded devices).

cndr wrote:does any one have any tips for memory management?

Use destructors. Their entire point is to encapsulate the memory deallocation process.

Genesis wrote:1. Use smart/shared pointer containers
2. Write a garbage collector
3. Explictly allocate & deallocate memory on demand

Coming from a C/++ background, I'm not so sure how realistic these are.

Writing a garbage collector is pretty overkill when you're using a language like C++ whose explicit memory management comes from the low-level nature of the language. If you aren't going to be handling your resources yourself, then perhaps you should consider writing whatever project in Java/C# or another language with a runtime and garbage collector?

Genesis wrote:Option 3 is what you should avoid unless you need strict control over how much memory your application is using (e.g. when dealing with embedded devices).

I'm not exactly sure how to interpret this. In the C/++ world, manual memory management is just how things work. You are responsible for deallocating what you allocate--embedded devices or not. You can't just "avoid" that in the language.

Unless your advice is to use C#/Java for their garbage collection and avoid C++ and manual memory allocation unless you're working on an embedded system?

here are some pitfalls i have learnt to avoid.

1. Be very careful of std function that allocate memory, strdup for example. its easy to forget to free those.
2. Be very careful when using class constructor in function call as a perameter. for example, you might have a function foo(bar *obj), then you call it foo(new bar(params)); (this goes for anything that allocate memory really)
3. Make very good destructors. especially when you have composition. and in times of inheritance you can run into issues as well.
4. Umm... all i can think of now. but generally its fairly easy to spot where a leak is occuring. sometimes its not so easy to fix.

also, avoid allocating and deallocating frequently. malloc, free, new, delete. can be time costly.
if you can get away witrh using the stack. sure go for it. if you need persistance, estimate how much you need and allocate it once.