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

List:       kde-core-devel
Subject:    Re: RFC: Strategy for integrating the Nana debugging library
From:       David Faure <faure () kde ! org>
Date:       1999-12-19 13:56:51
[Download RAW message or body]

On Sun, Dec 19, 1999 at 01:56:43PM +0100, Mirko Sucker wrote:
> Hello,
> I was investigating the benefits we could gain from using Nana and how to do
> it. 
Great, thanks for doing so.

> 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. 
Agreed.
> 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. 

I don't see how that would work. If "nana" redirects the calls to kdebug,
how does it figure out the debug area code ? This isn't handled by nana...
Does this mean patching nana to add debug area codes to every macro ?

> 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)
> 

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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