Thread: Now that I'm used to C++, printf() >>>>>> cout >> endl;

Originally Posted by whiteflags

Really? About what specifically?

Yes really. Undefined.

Originally Posted by whiteflags

I don't know if I can agree with you. I think you have to write many different kinds of programs to experiment with a variety of debugging techniques and in order to use all of the debugger's features. You probably are not going to use everything all the time. If someone mentions a specific feature, though, it's worth looking into instead of pretending it doesn't exist. If I acted like that, then I would be ignoring people who teach me things.

You missed the point. But anyway, let's not get off topic.
// If you are having a burning desire to find out what I meant pm me.

Why a PM? Explain to us why you -- who admits not understanding debuggers very well -- speak publicly that "when it comes to debugging, people will start talking and talking. However, as usually, the actual good info they spread is just a 30% of the whole talking" (sic)?

I'm also curious as to who has ever told you that it is a good idea to debug a program with print statements. Or why do you think it is a good idea to spread that concept to beginners to the language when you yourself don't understand debuggers.

Let's talk...

Kind of funny since printf statements are a verbose, not laconic, approach to debugging.

Hypocritical reasoning is another Greek invention.

Originally Posted by Mario F.

Kind of funny since printf statements are a verbose, not laconic, approach to debugging.

This is relevant. I want just the value of a variable at the i-th loop. printf seems a laconic solution.

Originally Posted by Mario F.

Hypocritical reasoning is another Greek invention.

One of the numerous.
Are you saying that I am lying?

Memory problems frequently come from wrongly maths.

Maybe you are right. I am not comfortable enough yet with the gdb.
However, printing always worked for me until now. Maybe it won't in the future. I remember that I was using gdb for some memory problem, but could not locate the source of the problem, without using printings. bdg said to me where and which variable causes the boom and some other info.

Originally Posted by Epy

Seems like you guys are talking about different kinds of debugging, i.e. segfaults/memory problems vs. output.

We are talking of debugging in general.

Tracing code execution through print statements essentially amount to a poor man dynamic analysis, which is merely an aspect of debugging. Naturally we won't hear anyone refusing print statements as a debugging technique, exactly because... it is a debugging technique. But what is being discussed here (and the OP should be read again for proper context) is the idea that debugging can be done through tracing.

There's little that can be said that we don't know already about the complications of tracing. We all do it, even when coding outside the console. But we do it sparingly and within the context of dynamic analysis. But for the benefit of the OP, I'll list here some of the problems with tracing, and that can be easily solved with the help of a proper debugging tool (like GDB, not valgrind), but not only (see below for a better alternative to tracing that doesn't involve a debugger):

• Print statements are awkward to write, often because they tend to require full formatting in order to gain visibility outside the program normal output. I suspect that even a seasoned C/C++ developer tends to spend time writing and correcting format in order to obtain a proper debugging output. For this reason, seems counterproductive to waste time writing and correcting debug code, when I should be writing and correcting program code.
• Debugging is a cyclic activity. We tend to have to revisit old code after having introduced new code. As is the case with tracing, we want to get rid of all those extraneous print statements as soon as possible. But we will eventually need to rewrite them again when some future code affects the runtime of already debugged code and forces us to maintain that code. As you can probably guess, MutantJohn, you will end up rewriting a lot of print statements if this is your only debugging technique. Seems a terrible way to spend your time, when you think that ultimately your goal is to write a working program in a timely fashion.
• As is often the case when I trace, I end up having to maintain my tracing code. To avoid the previous problem, I tend to leave my tracing code alive and not delete it. I comment it, or just leave it running. But this produces another problem: I end up having to maintain that code. I need to organize it, correct it when future code is introduced, or completely rewrite it. This means that my tracing code becomes de facto code, sometimes, ironically, it too requiring debugging. Now, on what code do you prefer to be spending your time?

Tracing is an interesting quick-and-dirty debugging technique. But it should only be practiced in the context of dynamic code analysis. That is, when you are required to inspect output under several input conditions. But even then, it comes at a cost. The "quick" moniker isn't as obvious as you may think, since a proper debugger will offer you with memory inspection tools that surpass most of what you can do with print statements:

• Watch variables values and much more at runtime
• Alter variables at runtime and witness the effects
• Break code execution based on many factors (when a variable has a certain value, when its value falls within a range, even after a variable has changed X amount of times).
• Step over, step into and step back(!) in code.

With more "recent" program techniques, tracing has even lost whatever little charm it had left. The day you start learning about Unit Testing and experiment with Test-Driven Development (TDD), assuming you adopt these programming methodologies, you'll realize they completely replace the need for dynamic code analysis as you know it. In fact, even if you end up not adopting Agile Development techniques, you may end up incorporating Unit Testing as an important part of your programming activity, even if not following to the letter the principles of TDD. Many programmers do this.

It may be that debug print statements will always end up finding a place in your code. I know they have a place on mine (and many others in here). But they are rare, they are not used to replace a debugger, and -- at least in my case -- they will often display my lazy self in a most unproductive way.

Mario said:
Hypocritical reasoning is another Greek invention.

Originally Posted by std10093

One of the numerous.
Are you saying that I am lying?

You forgot to answer? Please read the whole answers of others.......

Originally Posted by std10093

Are you saying that I am lying?

Yes.

Ancient Greeks did invented many many things. But people's ability to be wrong or correct is not a Greek product.

I feel very upset (yes I know that some days are passed from this) about the fact that someone claims that I am lying.

Claims are claims and I respect the right for everyone to assume things. Assumptions are ok, but they are not facts. For example, Mario made the assumption that I am lying and of course he is wrong.

But my target is not to argue with him. As a matter of fact, Mario is actually what he writes below his name (but he has a typo, since one letter is wrong). Of course this is an opinion, my opinion, so it may not be a fact. However, in my mind, this is surely fact, based on what I have seemed him saying in the General-discussions (either to me, or to other members).

What I am interested in, is all the other, to whom I want to make clear that I did not lie!

I do not want this to get way off topic so I am putting a period here. However, pm are welcome.