The Pain of Debugging

We engage in debugging when a defect has been reported. The activity involves identifying the platform, the tools such as emulators and SDK, and the compiler used for that platform. Hopefully, there is an IDE and a modern debugging facility for our setup.

We then begin tracing the code, or stepping through it and observing the states of objects with the hope of locating the cause of defect. This may all be as it is except when the thread of execution enters an uncharted territory. Here we are in the wilderness of libraries not written by us. The pain is the same whether we are hiking the compiler’s land of standard libraries, such as C++ stream library, or we are climbing Java’s Everest library. A particular characteristic of these libraries is the fact that they change color and shape like the four seasons. So we must also be aware of the particular version we are linking with.

Finally we ask an innocent question. Why can’t I debug the code that I, and my team wrote? What do we have to do with finding bugs in other peoples’ code and reporting it? Surprisingly, there is a positive answer to your legitimate desire!

Z++ Visual is one single development point for any and all platforms. There are no SDK, no emulators, indeed nothing else for that matter. You only step through the code that you, or your teammates wrote. Your focus remains at locating the cause of defect in your code. The rest is taken care of by the Z47 processor.

A Z++ program has a single meaning, independent of platform. When a bug is reported, you analyze it on the same original consol that you wrote the program, regardless of the platform on which the defect was observed. Obviously, your fix takes care of the problem for all platforms. This is as natural as the innocent question that you asked earlier.