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.
Oct 2 '07
19  2057 
James Kanze wrote:
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.
Really? I never found one. :-)
I've never seen a professional who disagreed.
>Certainly there are many situations where it is just
unacceptable .
Such as?
One fundamental question is whether there is a notion of "correctnes s" for
the behavior of the program. Whenever correctness of the results matter, I
would hope that asserts are left in so that in case of a bug that causes
the state of the program to be unforseen (and therefore potentially bogus)
there is a chance that it will crash. Few things are worse than output that
is believed to be correct but isn't; that can be very costly, too.
Compilers are an example: I prefer a compiler crash to the generation of
potentially faulty object code any day.
On the other hand, there are programs where correctness is not that
meaningful a concept. Think of a game. The physics engine may sometimes not
detect that two objects are at the same place at the same time or the
rendering may be a little off due to rounding errors or arithmetic
overflows. Now, those effects might be gone after two or three frames and
as long as the user experience is good, there is a reason to prefer the
game going on to the game crashing. In that case, it could be a correct
business decision to eliminate the asserts in release code.
[snip]
Best
Kai-Uwe Bux
"James Kanze" <ja*********@gm ail.comwrote in message
news:11******** *************@5 7g2000hsv.googl egroups.com...
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]
>>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.
I guess that depends on how you define a professional.
I've been a software engineer using c++ 10 years and I
use a debugger. I understand what you mean when you
say that with the proper design it's not needed, but I've
never worked anywhere where the design methodology
was perfect. The tools aren't always perfect either.
Kai-Uwe Bux a écrit :
James Kanze wrote:
>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.
Really? I never found one. :-)
Giordano Bruno did but it was under the roman inqusition.
>
>I've never seen a professional who disagreed.
>>Certainly there are many situations where it is just
unacceptabl e.
Such as?
One fundamental question is whether there is a notion of "correctnes s" for
the behavior of the program. Whenever correctness of the results matter, I
would hope that asserts are left in so that in case of a bug that causes
the state of the program to be unforseen (and therefore potentially bogus)
there is a chance that it will crash. Few things are worse than output that
is believed to be correct but isn't; that can be very costly, too.
If there is a part of a programm where uncorrect behavior is manageable,
it is treated specifically and locally. I can't thing of a relevant
example where it would be the case.
>
Compilers are an example: I prefer a compiler crash to the generation of
potentially faulty object code any day.
On the other hand, there are programs where correctness is not that
meaningful a concept. Think of a game. The physics engine may sometimes not
detect that two objects are at the same place at the same time or the
rendering may be a little off due to rounding errors or arithmetic
overflows. Now, those effects might be gone after two or three frames and
as long as the user experience is good, there is a reason to prefer the
game going on to the game crashing. In that case, it could be a correct
business decision to eliminate the asserts in release code.
From the practical point of view, there are things that are not
assertable or asserted but are part of test. In the example you gave,
typically the game engine won't assert this kind of conditions.
I have worked on error correcting codes where post condition (the
checksum) were not respected but the data was used. It was by design: a
small noise or cracks in the voice could be bearable.
My understanding is that is not the topic here, we are talking about
asserts in pre an post conditions or invariants and check points.
Michael
On Oct 3, 6:57 am, Michael DOUBEZ <michael.dou... @free.frwrote:
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.
I'm a nuke. If one of the control computers did an
assert, the operator would come and find me. This
would not end well.
I don't think you mean the same thing by "assert"
that I do. When a program hits an assert and fails,
the program stops. All over, bang, goodbye, only
way to get it back is to restart the program.
This is something you put in your aircraft?
An assert should not be thought of as a safety belt.
This is the "known unknown" divide I talked about.
A safety belt is intended for expectable conditions:
A car in a crash. An assert is intended for implentation
errors: The steering wheel is not connected to the
steering mechanism because it's in the trunk.
You put the "safety belt" stuff into the interface
design, putting the details into the spec (the contract).
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.
Um. That's pretty much the point I'm making. The exceptions
are the "safety belt" stuff. An assert is a tool for detecting
implementation errors. An exception is part of the design.
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.
Um. You don't? You put it in the spec. Then you make
the code check how many it has before it adds one, and
if it would be over the limit it does whatever the right
thing is about that. Maybe send a denial message to the
request, or pass it to another server, or some other
specified thing.
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 ?
I'm just guessing, but what I'm guessing is that you are
a bigtime Unix coder.
You step through your code to catch stupid mistakes. I've
seen this lots of times where guys put code back into the
codebase without ever stepping through it. And when I come
along to see why the smoke is getting out (Electronics all
runs on smoke, which is shown by it always stopping when
the smoke gets out.) I find that the code branches the wrong
way or does not assign the calculated value, or has some
stupid thing like the classical for(yada yada); thing.
Which would have been instantly obvious as soon as you
stepped through the code and watched the values and the
execution. You can also catch off-by-one errors, and often
see non-initialized variables, wild pointers, etc. etc.
I've also had the case where the coder refused to believe
there was anything wrong with his code till I fired it
up in the debugger and showed him the bad behaviour.
Note that I'm not saying you step through the code as
a replacement for any other activity. I'm saying you do
this in addition to all other good practices. It's very
easy in a good debugger. And it's quite quick.
Note also that I'm not saying step through every line
of code every time you touch the app. Just the changed
or new lines.
Socks
Duane Hebert wrote:
I've been a software engineer using c++ 10 years and I
use a debugger.
Learn to use every tool in your kit. And part of "learn to use" is learning
how to avoid abuse. Programming in the debugger, or programming to the
debugger, are abuse.
--
Phlip
>
I don't think you mean the same thing by "assert"
that I do. When a program hits an assert and fails,
the program stops. All over, bang, goodbye, only
way to get it back is to restart the program.
This is something you put in your aircraft?
Software lives in an imperfect world. Do you code for all possible
breaches of contract by all the libraries your code calls? If you code
the system from the ground up, you may be able to ensure protection, in
that case the asserts will never fire, so why take them out? In some
instances the only safe thing to to when contractually impossible data
is presented is to restart.
>
You step through your code to catch stupid mistakes.
You write unit tests to catch stupid mistakes. If a code change breaks
a test, undo it and try again. If you have the time and are curious,
that you might consider stepping through to see why you broke the test,
but doing will slow you down.
Try working with a language that lacks a decent debugger for a wile, it
will sharpen up your testing or TDD skills.
I've
seen this lots of times where guys put code back into the
codebase without ever stepping through it.
Set you SCM system up to not accept commits that break the tests.
--
Ian Collins.
Puppet_Sock <pu*********@ho tmail.comwrote in
<11************ ********@r29g20 00hsg.googlegro ups.com>:
On Oct 3, 6:57 am, Michael DOUBEZ <michael.dou... @free.fr>
wrote:
>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.
I'm a nuke. If one of the control computers did an
assert, the operator would come and find me. This
would not end well.
I don't think you mean the same thing by "assert"
that I do. When a program hits an assert and fails,
the program stops. All over, bang, goodbye, only
way to get it back is to restart the program.
This is something you put in your aircraft?
Disclaimer: I've never worked on life-critical applications.
But I believe it would be better for the avionics suite to
shut down if an assert fails than to execute the code
outside of parameters it was designed for. For all you know
it might decide to fly a jumbo jet through a barrel roll,
or flush fuel tanks, or depressurise the passenger's
compartment. It's better for the software to honestly admit
to its human operators that it has encountered something it
cannot handle and has to give up, than try to cover it up
working in conditions it was never ever meant for. Humans
trust their computers. When they shouldn't, we gotta tell
them so.
A brief googling/wikiing failed to find a convincing case.
The following page: http://www.cs.tau.ac.il/~nachumd/verify/horror.html
....seems to describe something close to what I'm talking
about.
"16. An airplane software control returned inappropriate
responses to pilot inquiries during abnormal flight
conditions."
Unfortunately, the link to details is broken, so it's hardly
a convincing piece of evidence.
--
It is rare to find learned men who are clean, do not stink,
and have a sense of humour. -- Liselotte in a letter to
Sophie, 30 Jul 1705
On Oct 3, 1:04 pm, Kai-Uwe Bux <jkherci...@gmx .netwrote:
James Kanze wrote:
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.
Really? I never found one. :-)
Question of milieu. If you frequent a milieu where geography or
astronomy are unknown, you'll find them. If you frequent a
milieu where software engineering is unknown, you'll find people
who believe you should take asserts out of deliverable code:-).
I've never seen a professional who disagreed.
Certainly there are many situations where it is just
unacceptable.
Such as?
One fundamental question is whether there is a notion of
"correctnes s" for the behavior of the program. Whenever
correctness of the results matter, I would hope that asserts
are left in so that in case of a bug that causes the state of
the program to be unforseen (and therefore potentially bogus)
there is a chance that it will crash. Few things are worse
than output that is believed to be correct but isn't; that can
be very costly, too.
Compilers are an example: I prefer a compiler crash to the
generation of potentially faulty object code any day.
On the other hand, there are programs where correctness is not
that meaningful a concept. Think of a game. The physics engine
may sometimes not detect that two objects are at the same
place at the same time or the rendering may be a little off
due to rounding errors or arithmetic overflows. Now, those
effects might be gone after two or three frames and as long as
the user experience is good, there is a reason to prefer the
game going on to the game crashing. In that case, it could be
a correct business decision to eliminate the asserts in
release code.
I'll admit that games are a special case with regards to
software engineering, and obey very different rules. There are
probably also a few other cases, that I'm not familiar with
either. But you've doubtlessly seen enough of my postings to
know my predilection for hyperbole (which I alternate with
typically gallic litote to really confuse people).
--
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, +33 (0)1 30 23 00 34
On Oct 3, 2:08 pm, Michael DOUBEZ <michael.dou... @free.frwrote:
[...]
My understanding is that is not the topic here, we are talking about
asserts in pre an post conditions or invariants and check points.
I think that's a good point. We're talking about the detection
of programming errors. But the real point is simply this: can
you handle the error. If you can, then you don't use
assert---even in debug mode. You use something else, like
exceptions. And you write test cases which trigger it, so you
can verify that you do handle it correctly.
And if you can't handle it, of course, just ignoring it is NOT
really an option. You have to abort.
--
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, +33 (0)1 30 23 00 34
On Oct 3, 8:28 pm, Puppet_Sock <puppet_s...@ho tmail.comwrote:
On Oct 3, 6:57 am, Michael DOUBEZ <michael.dou... @free.frwrote:
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.
I'm a nuke. If one of the control computers did an
assert, the operator would come and find me. This
would not end well.
You mean he would prefer you to stumble on, not knowing the
internal state of the program, and behave in an undefined
manner, maybe causing a nuclear meltdown.
The very first rule in all critical systems is if there is the
slightest doubt about the program, abort and get the heck out of
there, so that the redundant back-up systems can take over.
I don't think you mean the same thing by "assert"
that I do. When a program hits an assert and fails,
the program stops. All over, bang, goodbye, only
way to get it back is to restart the program.
This is something you put in your aircraft?
It's certainly something that is in the control systems on an
Airbus (or was when I consulted there, in the late 1970's). It
was a contractual requirement when I did a locomotive brake
system, in the mid 1980's---in fact, any time there was any
doubt concerning the reliability of the system, they cut the
power supply to it.
[...]
>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 ?
I'm just guessing, but what I'm guessing is that you are
a bigtime Unix coder.
Which "you"? I've worked on many different types of systems,
from 8 bit embedded processors with 2 KBytes ROM, to IBM
mainframes.
You step through your code to catch stupid mistakes.
Except that stepping through the code doesn't necessarily catch
all, or even most stupid mistakes. You use code review to catch
stupid (and not so stupid) mistakes. And you use extensive
tests to catch problems in your code review process.
I've seen this lots of times where guys put code back into the
codebase without ever stepping through it.
In most places I've worked, at least since the late 1980's, the
version control system was set up so that you couldn't check in
code without it having passed its unit tests. And the unit
tests were reviewed, along with the code, to ensure coverage.
In some places, at least, checked-in code was quarentined until
someone cleared it, ensuring that it had passed code review.
The review process is critical. At least some of the reviewers
must be relatively unfamiliar with your code, to bring a fresh
view of it. Nothing you, or anyone who worked closely with you
during the development phase, can do will replace this.
[...]
I've also had the case where the coder refused to believe
there was anything wrong with his code till I fired it
up in the debugger and showed him the bad behaviour.
If the code review panel says that the code is wrong, it is
wrong. The programmer either fixes it, or is fired.
--
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, +33 (0)1 30 23 00 34 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Davy |
last post by:
Hi all,
I use VC and gcc/gdb to compile and debug C/C++ files. But I found some
of the debug version of the compiled files are too large to be run in a
small RAM. Can I compile C/C++ Debug partially?
Something like:
fileA.c fileB.c
And I can compile fileA.c with debug info and compile fileB.c without
debug info?
|
by: emma middlebrook |
last post by:
I have a question regarding asserting ... here's some code:
string GetAssertMessage()
{
... prepare a message string and return it...
}
void SomeMethod()
{
...
|
by: Srinivasa Rao |
last post by:
I have read in one article that when we compile the application in release
mode, all the debug classes and properties will be automatically removed from
the code. I tried to implement this thing by using the following code in
Page_Load event handler.
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Dim intcount As Integer
intcount = 0
For intcount = 0 To 4
|
by: dee |
last post by:
Hi
I'm about to upload my site and I have switched to release version. Is that
enough or do I still need to disable
<compilation defaultLanguage="vb" debug="true" />
the debug="true" in the .pdb file?
Is the .pdb necessary for the release version?
Thanks a bunch.
Dara
|
by: swartzbill2000 |
last post by:
Hello,
I have a VB 2005 Express project with a TraceListener-derived class to
route Debug.Print output to a log file. It works fine for Debug builds.
What is the correct combination of changes to make it work in Release
build?
Bill
| | |
by: pauldepstein |
last post by:
To help me debug, I am writing a lot of information into a stream which
I call debug.
However, because of the large amount of time taken to print this
information, I only want this printed while I am in debugging mode as
indicated by a preprocessor directive:
#define DEBUG
In other words, I need code which says "Whenever I write debug <<
|
by: Andrew Rowley |
last post by:
I am having trouble getting debug and release builds to work properly
with project references using C++ .NET and Visual Studio 2003.
I created a test solution, with a basic Windows form C++ project.
I then add a class library, and add a reference to this project in the
first project.
When I do a release build, I see the following in the output from the
DLL compile:
/OUT:"C:\Documents and Settings\Andrew\My Documents\Visual Studio
|
by: BA |
last post by:
I posted on this once before and could not get a solution, I am hoping
someone can help. I have a very strange code debug behavior that I cannot
make heads or tails of:
I have c# code being executed in BizTalk assemblies which is repeating debug
statements. I tried debug.flush() and debug.close() which did not solve the
problem.
In my BizTalk process I call a static method:
|
by: gfergo |
last post by:
Good Morning,
I seem to be having a problem. I thought I could display detailed
debugging information (including file name and line number) on a page
using two different methods:
1.) modify the debug attribute of the compilation element in the
web.config file -
|
by: rorni |
last post by:
Hi,
I'm porting code from Windows to HP-UX 11, compiling with g++.
I'm getting a compilation error on the system's debug.h include file, which is included very indirectly through a series of other system include files. The one I am including is <map> .
The errors I am getting are:
/opt/hp-gcc-4.2.1/lib/gcc/ia64-hp-hpux11.23/4.2.1/../../../../include/c++/4.2.1/debug/debug.h: At global scope:...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
