"Jan-Eric Duden" <jeduden@whisset.com> a écrit dans le message news: bm5mh1$2jd9$1@digitaldaemon.com...
> Being able to debug would help too... :)

D already have the most useful debugging primitive ever ! Namely, printf =)

-- Nicolas Repiquet

"Jan-Eric Duden" <jeduden@whisset.com> escreveu na mensagem news:bm65db$507$1@digitaldaemon.com...
> >
> > > Debugging helps, it takes you by your hand, and goes with you through
> the
> > > algorithm step by step.
> > > that's easier and faster than putting assertions after every
statement.
> >
> > It isn't a matter of putting assertions after every statement, instead
you
> > decompose your problem in smaller parts and write the contracts of those parts. Since I started using unit tests and DbC in my code I don't mess
> with
> > the debugger anymore, perhaps once a year to debug third party code ;)
>
> If you have a bug in your mind and therefore your model,
> then you need to work statement by statement. Unittests only help to see
> that there is a bug, but it doesn't help much to locate it.

The code does what you tell it to do. In practice it's very hard to have a bug both in the contract and the code. In this case debugging won't help because you won't know you have a problem. Of course you need to have a contract with an implementation different from the body, otherwise you're just wasting time.

> > ...
> Jan-Eric



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.524 / Virus Database: 321 - Release Date: 7/10/2003

I was referring to the case where your code perfectly implements the model and it still doesn't work.

Of course, It would be better to check and debug the model itself with the
standard model checking stuff,
but usually I have the model only in my mind and an implementation of the
model as code.
Since I can't really debug a model in my mind :), I debug the code and see
why the code fails.
Once, I know why the code fails I might also know why my model is wrong.
-- 
Jan-Eric Duden
"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message
news:bm6j16$n3j$1@digitaldaemon.com...
> "Jan-Eric Duden" <jeduden@whisset.com> escreveu na mensagem news:bm65db$507$1@digitaldaemon.com...
> > >
> > > > Debugging helps, it takes you by your hand, and goes with you
through
> > the
> > > > algorithm step by step.
> > > > that's easier and faster than putting assertions after every
> statement.
> > >
> > > It isn't a matter of putting assertions after every statement, instead
> you
> > > decompose your problem in smaller parts and write the contracts of
those
> > > parts. Since I started using unit tests and DbC in my code I don't
mess
> > with
> > > the debugger anymore, perhaps once a year to debug third party code ;)
> >
> > If you have a bug in your mind and therefore your model,
> > then you need to work statement by statement. Unittests only help to see
> > that there is a bug, but it doesn't help much to locate it.
>
> The code does what you tell it to do. In practice it's very hard to have a bug both in the contract and the code. In this case debugging won't help because you won't know you have a problem. Of course you need to have a contract with an implementation different from the body, otherwise you're just wasting time.
>
> > > ...
> > Jan-Eric
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.524 / Virus Database: 321 - Release Date: 7/10/2003
>
>

Daniel Yokomiso wrote:
> "Jan-Eric Duden" <jeduden@whisset.com> escreveu na mensagem
> news:bm5vhd$2uo8$1@digitaldaemon.com...
> 
>>Sure, D is high-level, but don't you make mistakes modelling an algorithm?
> 
> 
> Sure that's where design by contract helps you. You write the preconditions
> and posconditions of every function, and when you test it the compiler will
> do the checks and tell you "The parameter foo should be a list sorted by bar
> but wasn't". If you have the contracts for all of your functions you'll
> quickly find your bugs.

Hmmm. Contracts cannot be used to find all kinds of errors. To give one example: inter-thread behavior. Try to find a deadlock by adding contracts to your code.

Besides, contracts have one major drawback. Since the state of a sufficiently complex program is very big, you won't be able to check the consistency of everything after every operation. So basically you need to anticipate what might go wrong in order to be able to write meaningful asserts.

And another thing: you can easily get carried away by peppering your code with assertions everywhere. This may be nice from a theoretical point of view, but there IS the problem that when you're writing assertions you don't write code that actually adds functionality. Sure, the code you DO write may be less buggy, but there is a fine line between writing useful assertions and wasting time. Sometimes you just have to have faith that everything will work as expected and use a debugger afterwards if it doesn't.

I'm not saying you shouldn't use assertions. But you need to find a balance between coding time and the ability to prove that the code is bug-free (or at least that the issues you have anticipated do not occur).

In other words: debugging IS necessary ;).

Hauke

Phooey!  It doesn't even go to the debugger output window.

Sean

"Nicolas Repiquet" <deadcow-remove-this@free.fr> wrote in message news:bm671e$73j$1@digitaldaemon.com...
>
> "Jan-Eric Duden" <jeduden@whisset.com> a écrit dans le message news: bm5mh1$2jd9$1@digitaldaemon.com...
> > Being able to debug would help too... :)
>
> D already have the most useful debugging primitive ever ! Namely, printf
=)
>
> -- Nicolas Repiquet

I use windbg.exe on it. It works. On linux, I use gdb.

"Jan-Eric Duden" <jeduden@whisset.com> wrote in message news:bm5mh1$2jd9$1@digitaldaemon.com...
> Being able to debug would help too... :)
>
> --
> Jan-Eric Duden
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message
> news:bm544r$1pk0$1@digitaldaemon.com...
> > I know this has been said before, but having some stack trace in an assertion would be *very* useful
> >
> >
>
>

How ? I can't look up the _Dmain function and I just see assembler statements.

-- 
Jan-Eric Duden

"Walter" <walter@digitalmars.com> wrote in message news:bm6rn4$12ud$3@digitaldaemon.com...
> I use windbg.exe on it. It works. On linux, I use gdb.
>
> "Jan-Eric Duden" <jeduden@whisset.com> wrote in message news:bm5mh1$2jd9$1@digitaldaemon.com...
> > Being able to debug would help too... :)
> >
> > --
> > Jan-Eric Duden
> > "Matthew Wilson" <matthew@stlsoft.org> wrote in message
> > news:bm544r$1pk0$1@digitaldaemon.com...
> > > I know this has been said before, but having some stack trace in an assertion would be *very* useful
> > >
> > >
> >
> >
>
>

Walter wrote:

> I use windbg.exe on it. It works. On linux, I use gdb.
> 

Visual Studio (I've tried 7 and 7.1) works just fine too.  Just be sure to compile with symbolic debug info on, and point the debugger at the exe like anything else. (-g)

You can't inspect the members of structs and classes (including 'this'), which is a shame, but you can put watches on local variables, set breakpoints, and step through the program and so forth.

 -- andy

Cool! I may have to start using that. :)

"Andy Friesen" <andy@ikagames.com> wrote in message news:bm74a3$1e4u$1@digitaldaemon.com...
> Walter wrote:
>
> > I use windbg.exe on it. It works. On linux, I use gdb.
> >
>
> Visual Studio (I've tried 7 and 7.1) works just fine too.  Just be sure
> to compile with symbolic debug info on, and point the debugger at the
> exe like anything else. (-g)
>
> You can't inspect the members of structs and classes (including 'this'), which is a shame, but you can put watches on local variables, set breakpoints, and step through the program and so forth.
>
>   -- andy
>

so you debug assembler code? or actually d code?

I used the -g option:

c:\dmd\bin\dmd.exe -g -gt -debug -odC:\PROGRA~1\DIDE\Projects\T -version=Win dowsXP  T.exe "C:\Program Files\DIDE\Projects\T\T.d" -I\dmd\src

started windbg. execute with windbg the .exe and then I just see assembler
code.
so what am I doing wrong?

-- 
Jan-Eric Duden
"Andy Friesen" <andy@ikagames.com> wrote in message
news:bm74a3$1e4u$1@digitaldaemon.com...
> Walter wrote:
>
> > I use windbg.exe on it. It works. On linux, I use gdb.
> >
>
> Visual Studio (I've tried 7 and 7.1) works just fine too.  Just be sure
> to compile with symbolic debug info on, and point the debugger at the
> exe like anything else. (-g)
>
> You can't inspect the members of structs and classes (including 'this'), which is a shame, but you can put watches on local variables, set breakpoints, and step through the program and so forth.
>
>   -- andy
>