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.
Permalink for comment 71250
To read all comments associated with this story, please click here.
by mcrbids on Mon 12th Dec 2005 09:06 UTC
in reply to "7+-2"
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!
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!