C/C++ memory management - responsibility which comes with power

When Java popped up - designed as improvement of prevalent back then C/C++ family - we didn't have to wait long for announcements of soon-to-be-seen death of C family. Java offered platform portability, internal memory management and got rid of templates which were somewhat enough complicated construct for many developers to get lost there completely and avoid them at any cost. Java being wonderful language I still felt a bit connected with the last language trying to get as close to the processor and memory as possible. Luckily people started embedding software into nearly everything and virtual machine and garbage collection costs were easily translatable into cents and dollars per device and C and C++ didn't go away. I could still put in CV that I speak 'the last language for adults' and hope to get more from it than just indication of how old I have to be.

But then with being treated by compiler as an adult comes responsibility, you have to manage things which otherwise your JVM parent would manage for you. If you act like a child your applications will be crashing in the middle of documents creation, will behave in a non-deterministic fashion, will slow down and potentially make the whole operating system unresponsive.

For anybody who developed something in C or C++ it is probably obvious already that all those symptoms usually means: incorrect memory/resource managament in C/C++. Memory is not being freed or is double-freed, is not allocated or not initialized before reading, the writing to it goes out of bonds.

If we are lucky the application crashes right away (with access violation indication), unfortunately in most of the cases the 'patient is starting to show symptoms long after (in instructions time) the initial infection'. That leads quite often to great deal of frustration as the causes are very difficult to trace back.

To be continued...