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

List:       kde-core-devel
Subject:    Re: any more pros for nana?
From:       Stephan Kulow <coolo () kde ! org>
Date:       2000-01-25 22:26:31
[Download RAW message or body]

Mirko Sucker wrote:
> 
> Stephan Kulow wrote:
> > I'm sorry for the work that Mirko put into integrating
> > it and Phil to fullfill our constrains, but I see no
> > reason to confuse developers by having two debug solutions
> > and kdebug is surely the one that fits better into the
> > KDE framework.
> 
> It was much less work than the CORBA experiment.
> 
> But there is one more pro:
> I think, it will take some time until more people get used to this
> approach. And definitly, it is a better idea to check whether your
> assumptions are fulfilled than to hope they will. Finding the
> hard-to-find bugs is easier with it.
> Sure, it makes no sense to use it "widely" in 500-loc-applications, but
> in larger projects invariants, for example,  become inevitable.
> So, the main pro is: If you are used to it, you will write better code,
> and bad sideeffects and logical errors will force you to erase them,
> since even wrong but non-critical states of your application are found
> and kill the program by an assertion. And you will know what happened.
> Approaches like programming per contract mainly create better
> programmers (from the average programmer, not David :-), not better
> code.
> 
> I tried to erase all problems with other compilers. Currently, KDE
> should compile with compilers different from gcc, at least I got no
> messages against it. The only problems are ugly header names and
> compilers warnings. Both should be solveable.
> 
> On the other hand, if I am the only one opting for it (I am the only one
> using it, but this may be a matter of time), it is no problem to remove
> it. I would even completely remove nana from my sources, since due to
> the rewrite, this sources do not depend on nana except single
> statements.
> 
> Possibly, I would add vector assertions and require/ensure statements to
> kdebug. This is what we wanted to avoid when we talked about integrating
> nana.
> 
Well, if you write the parts we could use in a compatible (speak C++)
way,
I would perfer this. I myself love to mark my thoughts while coding with
asserts. But it seems you need an extra manual to get what LG, I and A
do

And the fact that they rely on gcc specific extensions, do not really
make me feel better :)

Greetings, Stephan

-- 
It said Windows 95 or better, so in theory Linux should run it
                                                GeorgeH on /.

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