Originally posted by Kevin Sanderson
Arthur Walasek responded:
[QUOTE]
If a program crashes, its the program’s fault. Pretty much all the time. period. There is absolutely no reason for a crash. In any program. You can check return values when allocating memory, check and validate memory contents when accessing memory, check drivers, etc. IT CAN BE AVOIDED.
Oh, really. Wish more software companies hired you.
[/QUOTE]
And so do I! 
(and I’m not ironic…)
According to most of the crash descriptions, A:M probably suffers from memory leaks. Knowing how to avoid memory leaks is indeed a noble art, unknown to but a few brave souls. A pity! however, since the art is as easy to adopt as is it noble.
Most software companies would benefit from thinking on this at the planning of a software project. When the program is already written it is anything but simple to correct it.
My own experience is from the defence industry and its needless to say that software instability is not even an option there
The rumour has it that Microsoft products are more buggy than, for instance, Linux. I’d like to stress that this is nothing more than just a rumour. The number of users, finding bugs, constitutes the difference, rather.
:lightbulb Memory Handling Quick Start Tutorial:lightbulb
In c++ this is what to think about:
[list=1]
[li] Never dynamically allocate new memory outside a class.
[/li][li] Always use a class to control the memory lifetime. If you thoroughly debug the memory allocation and deallocation in the constructor and destructor of the class, you will never have to worry about it again.
[/li][li] Do use containers (e.g. std::vector<>) from the standard library instead of using dynamic arrays
[/li][li] In general, avoid C-style programming in C++. Think OOP!
[/li][/list=1]
Sincerely,
/K.T.
(and I’m not ironic…)
