Design Principles and Key Features and Principles

Top  Previous  Next

What principles guided the design of JrDebugLogger?

Cross-platform support, compile in any C++ compiler.
There should be absolutely no impact at all on the performance and size of your code if you disable the compilation of the debug-logging feature.
If you choose to disable but leave the debugging code compiled into your application in order to collect debug logs from users, the impact of the debugging code should be absolutely minimal if not engaged; should be easy to turn on and off.
The debug output should be easily configured to output via standard console, to a file, or through the standardized MS Windows system call DebugOutputString
Output should be possible in a variety of formats including plaintext, xml, html, csv, etc.
The debugging library should provide built-in support to parse commandline options that configure debugging.

 

What are some key features of the toolkit?

The syntax for debug-logging statements is unobtrusive and natural.  You can use normal printf and c++ stream io style formats, or you can specify additional information with events, including custom fields.
Requires no special startup/shutdown code; super easy to use.
The JrDebug toolkit contains an optional stand-alone Windows gui tool, similar to the Debugview application, but cutomized for capturing/viewing/manipulating debug-logging events.
Special functions for logging assertions and exceptions; setting alarms and filters.
Very lighweight and easy to use Unit Testing support functions.
Complete documentation.

 

What does JrDebugLogger include?

A set of (cross-platform) c++ header files that you can add to your applications in order to support advanced debug-logging.
A Microsoft Windows GUI application for capturing debug messages in real time and allowing you to view/sort/search them in an efficient manner.
A visual component for Borland C++ Builder that can be used to capture DebugOutputString messages in your own BCB applications.