|
|
Main Page Namespace List Class Hierarchy Compound List File List Namespace Members Compound Members File Members Related Pages
Why DGD?
The most common question asked about DGD is "Why do you need just another tracing/logging library? Why not use the existing ones?". Those of you who think that any other library supports all of the below are invited to contact the author. DGD was created for debugging of different computation geometry algorithms with the following requirements:- There are ready output tracing methods for std::cout, I wanted to reuse them without changing. This requirement implies that basic output class (see DGD::channel) must be derived from std::ostream.
- The resulting trace log must be fixed width. I usually use 80 columns-wide emacs window and I don't like wide broken lines.
- There is a need for automatic indentation and word/char wrapping
- The resulting library must have simple kernel, without complex class hierarchy. This one allows to use fragments of DGD in different applications without need to link with the whole library.
- The resulting library must be as portable as possible.
Missing Features
There are also features which are missing in DGD and present in other tracing libraries:- Message types, like NOTICE, WARING, ERROR, etc... Here I must to make a few points:
- DGD is not message oriented. It is stream oriented and its primary purpose is debugging of algorithms. I found that for that purpose message types are irrelevant, I usually need them all or need them off.
- Different applications require different message types, so hard-coding message types in the library puts some restrictions on its users.
- If required, message types may be easily implemented on top of DGD.
- Different physical targets for the resulting trace. For example cyclic memory buffers, socket streams, etc... Some of these are still in the planning. The main problem here is portability. Yet, any stream which has std::ostream as a base class is ready to work with DGD.
- Thread safety. DGD is not thread safe. More precisely, it is as thread safe as std::ostream is. My strong belief is that the application is responsible for stream synchronization.
- Memory debugging. Is out of scope of DGD. There are good stand-alone tools for debugging memory leaks.
Generated on Thu Aug 10 16:48:29 2006 for DGD Library by  1.3
|
|
|
