Linked by Eugenia Loli-Queru on Sun 11th Dec 2005 19:23 UTC
Derek M. Jones looks at low-level coding errors and the use of coding guidelines as a cost-effective means of avoiding some of the more common instances of such errors.
Thread beginning with comment 71250
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-08-26
You only need to manage memory when you're allocating on the heap, meaning you want to be able to pass a variable outside of the context in which it was created.
Allocations on the stack are managed by the compiler.
Example:
int c[50]; // Create an array of 50 ints on the stack
int *c = alloc(50 * sizeof(int)); // Allocate memory for 50 ints in the heap, and set c to the first entry.
In the first case, no need to free() the ints. In the second, free(c) -Must- be called to avoid a memleak.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2005-10-25
My own rules - always free memory after alloc ( i spend a lot of time finding memleaks and other "free w/o alloc" and now it is like religion, delay between i write alloc and corresponding free must be < 2 seconds ). May be stupid but it works for me.
This is why I only work in high level languages (EG: PHP) where spending time on such thing is mostly irrelevant. If I'm done with a variable, I unset() it. Usually, said variable is inside a function, and when function terminates, that's the end of varable.
I never understood the need to manually manage memory. The c language is great for when performance is critical, but for most business apps that I write, it's mostly irrelevant. The SQL database is almost always the bottleneck, spend time on that and save time by using PHP/Perl/Python instead!