How do you debug?

[desktop]

When I write code I use a lot of:

std::cout << "TEST1\n";

....
....
<some code>
....
....

std::cout << "TEST2\n";

etc.

But is there some better way do this kind of debugging (maybe with some
preprocessor commands)?

I know that I could use the gdb debugger but often I prefer the above
procedure.

[jac]

You could try looking at the assert() function - see here for an intro
http://www.codeguru.com/forum/showthread.php?t=315371

On Oct 2, 4:55 pm, desktop <[e-mail] ote:

When I write code I use a lot of:

std::cout << "TEST1\n";

...
...
<some code>
...
...

std::cout << "TEST2\n";

etc.

But is there some better way do this kind of debugging (maybe with some
preprocessor commands)?

I know that I could use the gdb debugger but often I prefer the above
procedure.

[Zeppe]

Michael DOUBEZ wrote:

Actually, keeping asserts in the release code (i.e. not using NDEBUG) is
a good idea; just like wearing a safety belt after you have learned how
to drive.

It depends on the efficiency level that you need. For example, in many
libraries keeping _NDEBUG retains boundary checks on all the containers,
and that's not only desirable. That's why I suggested to create his own
asserts for release checks. I agree that, if you can, keeping asserts
may be a good thing (even though a failed assert makes the program crash
anyway).

I rarely use the debugger except as post mortem analysis; my unit tests
are usually sufficient.

And what about debugging unit tests?

Regards,

Zeppe

[Ian Collins]

Zeppe wrote:

Michael DOUBEZ wrote:

>Actually, keeping asserts in the release code (i.e. not using NDEBUG)
is a good idea; just like wearing a safety belt after you have learned
how to drive.

It depends on the efficiency level that you need. For example, in many
libraries keeping _NDEBUG retains boundary checks on all the containers,
and that's not only desirable. That's why I suggested to create his own
asserts for release checks. I agree that, if you can, keeping asserts
may be a good thing (even though a failed assert makes the program crash
anyway).

>I rarely use the debugger except as post mortem analysis; my unit
tests are usually sufficient.

And what about debugging unit tests?

The best way to debug unit tests is to undo the last edit!

--
Ian Collins.

[Zeppe]

James Kanze wrote:

The symbol to suppress assert is NDEBUG, not _NDEBUG. But of
course, you almost never want to use it. On larger projects,
it's also usual to have some sort of logging facilities, with
different log levels. If some subsystem seems to be causing
problems, you turn up the log levels in that subsystem.

True. It depends, as always, on the performance level, robustness level,
and complexity level that you want to achieve. In critical systems, you
may want to implement some mechanism that tries to partially recover a
bad situation, implementing most of the checks as exception that are
then handled properly.

>A good debugger anyway is often essential - for linux, a friendly
frontend of gdb is kdbg.

I'll admit that I've never found much use for a debugger
professionally. If you write the code so that it's easy to
understand, and have it correctly code reviewed, there generally
aren't any bugs in it anyway. (I forget who said it, maybe
Hoare: "Code is either so simple that it obviously has no
errors, or so complicated that it has no obvious errors."
Obviously, you should strive for the first.)

Obviously, I would say, the debugger is useful when the first is not
achievable (and there are situations in which it isn't) ;)

Regards,

Zeppe

[Jim Langston]

"desktop" <ff*@sss.comwro te in message
news:fd******** **@news.net.uni-c.dk...

When I write code I use a lot of:

std::cout << "TEST1\n";

...
...
<some code>
...
...

std::cout << "TEST2\n";

etc.

But is there some better way do this kind of debugging (maybe with some
preprocessor commands)?

I know that I could use the gdb debugger but often I prefer the above
procedure.

I've done this before where there is some bug in a program and it is not
known where it is and for whatever reason running it in the debugger is not
feasable. Usually when it is an intermittent bug that only happens
sometimes and I'm trying to figure out both why and where. Rather than send
the output to cout though I'll usually send it to a file.

For most debugging, however, I'll use an interactive debugger.

[Puppet_Sock]

On Oct 2, 4:56 am, Michael DOUBEZ <michael.dou... @free.frwrote:
[snip]

Actually, keeping asserts in the release code (i.e. not using NDEBUG) is
a good idea; just like wearing a safety belt after you have learned how
to drive.

You will find a lot of people who disagree with that.
Certainly there are many situations where it is just
unacceptable.

Such things as asserts should not be used as error
trapping during normal operation. That is, they
shouldn't be catching such things as bad input.
An assert should be catching only developer error.
That is, if an assert fires while a user is on
the system, it should only ever indicate a bug in
the code.

C++ exceptions are yet another refinement here. These
should be things outside the contract of interface
of the code, but still inside the design. These are
the "known unknowns."

In my code, I use macros to log debug information that are not included
in the released version and are useful only for tracing execution or
remarquable values. Other log are kept in the release version. Both use
the same mecanism.

See, that's troublesome. "Remarkable values" shouldn't
be traced through a debug mechanism. They should be
designed into the error checking of the code. That is,
they should be "in the contract."

Or, to put it another way: If the interface is supposed
to handle the user typing "blue" when asked for a speed,
then there shouldn't be an assert fired on it. That
should fire a pre-defined user-oriented error handling
routine, not an assert.

I rarely use the debugger except as post mortem analysis; my unit tests
are usually sufficient.

Again, you will get many people who disagree with that.
Indeed, my advice is to *always* step through every line
of code in the debugger, at least once. There should
*also* be unit tests.
Socks

[Phlip]

desktop wrote:

std::cout << "TEST2\n";

etc.

But is there some better way do this kind of debugging (maybe with some
preprocessor commands)?

Sure. Write "unit" tests for everything. (Actually "developer" tests - unit
tests are a QA thing.)

You can write the code completely decoupled from itself, so all functions
respond to tests as well as they respond to each other. The diagnostics you
need will go into the assertion diagostics.

When the time comes to actually debug, tests make a perfect platform for all
kinds of traces and experiments. Further, if you run the tests after every
few edits, and add to the tests whenever you add new abilities, you can
typically revert nearly any change that unexpectedly breaks the tests. This
implies you can take bigger risks with your changes, and at the same time
reduce your exposure to debugging. People using this system report their
time spent debugging goes way down.

--
Phlip

[James Kanze]

On Oct 2, 9:34 pm, Puppet_Sock <puppet_s...@ho tmail.comwrote:

On Oct 2, 4:56 am, Michael DOUBEZ <michael.dou... @free.frwrote:
[snip]

Actually, keeping asserts in the release code (i.e. not
using NDEBUG) is a good idea; just like wearing a safety
belt after you have learned how to drive.

You will find a lot of people who disagree with that.

You'll also find a lot of people who think that the world is
flat. I've never seen a professional who disagreed.

Certainly there are many situations where it is just
unacceptable.

Such as?

Such things as asserts should not be used as error
trapping during normal operation. That is, they
shouldn't be catching such things as bad input.
An assert should be catching only developer error.
That is, if an assert fires while a user is on
the system, it should only ever indicate a bug in
the code.

Who has ever claimed the contrary? And what does that have to
do with leaving them in in released code?

C++ exceptions are yet another refinement here. These
should be things outside the contract of interface
of the code, but still inside the design. These are
the "known unknowns."

I like that formulation: "outside the contract, but inside the
design". Except that throwing for specific input is often part
of the contract.

In my code, I use macros to log debug information that are
not included in the released version and are useful only for
tracing execution or remarquable values. Other log are kept
in the release version. Both use the same mecanism.

See, that's troublesome. "Remarkable values" shouldn't
be traced through a debug mechanism. They should be
designed into the error checking of the code. That is,
they should be "in the contract."

Or, to put it another way: If the interface is supposed
to handle the user typing "blue" when asked for a speed,
then there shouldn't be an assert fired on it. That
should fire a pre-defined user-oriented error handling
routine, not an assert.

I rarely use the debugger except as post mortem analysis; my
unit tests are usually sufficient.

Again, you will get many people who disagree with that.

Again, no professional. Most places I've worked, I've not even
had access to a debugger, and in places where a debugger has
been available, it's easy to see who uses it: they have the
worst code.

Indeed, my advice is to *always* step through every line
of code in the debugger, at least once.

And what does that achieve, except waste time? If you have to
"step through" the code to understand it, the code isn't well
written, and should be rewritten.

There should *also* be unit tests.

And code review, which is doubtlessly the most important and
effective means of reducing errors.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Michael DOUBEZ]

Puppet_Sock a écrit :

On Oct 2, 4:56 am, Michael DOUBEZ <michael.dou... @free.frwrote:
[snip]

>Actually, keeping asserts in the release code (i.e. not using NDEBUG) is
a good idea; just like wearing a safety belt after you have learned how
to drive.

You will find a lot of people who disagree with that.
Certainly there are many situations where it is just
unacceptable.

I work on an aeronautic embedded system with real time and fault
tolerant cobstraints. It is pretty critical and I can tell you the
asserts are still in the code when it takes off.

Such things as asserts should not be used as error
trapping during normal operation. That is, they
shouldn't be catching such things as bad input.
An assert should be catching only developer error.
That is, if an assert fires while a user is on
the system, it should only ever indicate a bug in
the code.

And of course, all relased code is bug free and in case there is a bug,
the log are always enough locate the bug. Supposing the bug is detected
by the user (when there is a user).

C++ exceptions are yet another refinement here. These
should be things outside the contract of interface
of the code, but still inside the design. These are
the "known unknowns."

I don't know what you call a "known unknowns" but exception are not part
of debug process but rather of design. If you want to design an
exception aware code, you'd better know who is likely to throw and if
you wan to recover from it, you'd better know what is thrown.

>

>In my code, I use macros to log debug information that are not included
in the released version and are useful only for tracing execution or
remarquable values. Other log are kept in the release version. Both use
the same mecanism.

See, that's troublesome. "Remarkable values" shouldn't
be traced through a debug mechanism. They should be
designed into the error checking of the code. That is,
they should be "in the contract."

I don't see how you can put a contract on let say the number of
connection a server is holding or outputting the state of a system.
Those are just information log that are of no interest in the release or
not critical but help in building a mental picture of the state of the
programme.

And it gives something to read when you run the tests :)

>
Or, to put it another way: If the interface is supposed
to handle the user typing "blue" when asked for a speed,
then there shouldn't be an assert fired on it. That
should fire a pre-defined user-oriented error handling
routine, not an assert.

>I rarely use the debugger except as post mortem analysis; my unit tests
are usually sufficient.

Again, you will get many people who disagree with that.
Indeed, my advice is to *always* step through every line
of code in the debugger, at least once.

What for ?
Michael