Why should we log debug info while developing a software package? In the first place for yourself and your team. If you encounter undefined behavior in your part of the code, you can have a pretty rough idea where it came from, which isn’t the case if the code has been written by another developer. In most cases, the console will be able to help you just enough to debug in real-time. If this doesn’t solve the problem, everything should be written to an external log file so the cause can be determined. Once the package has been delivered to the customer, you want to hide this information. But what if the client contacts you to report a problem? The typical answer you would get is “I clicked on the button on the left and then on the button on the right and nothing works anymore!”. Go figure out what went wrong, spending time and money on something that could be helped in 5 minutes maybe? Off course you can’t ask the customer to open a console window, start the software in debug, … This would not be a good idea. Just keep the external log file on a safe location while running and ask the customer to mail the file too you, or use a build in contact mechanism. For big software packages I suggest logging some text, and most of the time error codes. In this example, I will just show you how to log text, but by using a stream you can append error codes and log them in the same way.
Click on the link below to watch the tutorial.
Logging to a console and a file in a Win32 C++ GUI application
