[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    RFC: Strategy for integrating the Nana debugging library
From:       Mirko Sucker <mirko.sucker () unibw-hamburg ! de>
Date:       1999-12-19 12:56:43
[Download RAW message or body]

Hello,
I was investigating the benefits we could gain from using Nana and how to do
it. 

The logging support, the first thing that comes to discussion, does not seem
the most important thing for me. Since we have kdebug already, I thing we are
able to continue to use some parts of kdebug. 
Mostly, I will redirect Nana logging messages to kdebug (the message handler is
defineable). This would save us form having to rewrite the dialog and debug area
stuff, and all messages written from the Nana logging macros would appear in
the same buffer/daemon/whatever that is selected in kdebug. Additionally, this
option requires the least code changes and the smoothest way of integration. 

The second feature that seems to be usefull to me is the invariant method in
C++ classes. It is a feature derived from Eiffel, where conditions are tested
at the beginning and the end of methods. See the documentation of eiffel.h. It
is a kind of programming per contract, and proved really efficient to me.
Consider the example taken from the Nana docs:

// compiled with EIFFEL_DOEND defined
void Stack::push(int n) 
DO  // checks the class invariant + {
   ... 
END // check the class invariant + }

The DO statement calls the method "bool invariant()" that returns true if all
invariants of this object (conditions that must be true all the time) are
fulfilled. That means your program stops if any part of it left the object in a
forbidden state. IMHO, it should be used in all non-trivial classes.

Most other features of Nana seem to be a matter of taste to me. If you use gdb
or its derivates/GUIs regularly, you will like it. 

Of course, all this calls are removed when compiling without debugging. 

What disturbs me is the problem of portability. It still needs prove that all
this macros are resolved to nothing when compiling without debugging even on
non-linux/gcc-platforms. 

If you agree, I will
- add a subdirectory "nana" to kdelibs containing everything needed to create
the basic nana (shared) library (~10kB library size unstripped) 
- implement the kdebug-based message handler for Nana logging output and
- check where the Eiffel-statements would be useful.

Are there any missing features then? David, you asked for some...
Greetings,
--Mirko.
-- 
Denn der  Mensch  liebt und ehrt den  Menschen,  solange er ihn
nicht zu beurteilen vermag, und die Sehnsucht ist ein Erzeugnis
mangelhafter Erkenntnis. (Thomas Mann)

[prev in list] [next in list] [prev in thread] [next in thread]