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

one problem with printf is that you can't use it to print std::string objects naturally, and you absolutely can't extend it in any way. you can write your own output and input functions for your user-defined types (structs and classes) for use with cout and cin, respectively.

iostream objects like cout and cin are also type safe. you can't accidentally print something as the wrong type. if you pass it a float, it will print it as a float, no matter what.

yes, they can be a bit more cumbersome to use, but they're also much more powerful and flexible.

One option if you would like to use format strings with C++ I/O streams is to use Boost.Format.

Originally Posted by MutantJohn

I'm one of those guys like std100something or w/e who prefers to use print statements to debug code. For me, I don't type anything until I have a good idea of what's gonna happen and if my code should fail, I like to use print flags to narrow it all down and it works well. I hate IDEs.

Please don't do that. That is an affront to all programmers out there and you are severely limiting yourself by not using advanced functions.
Not using IDEs is fine; some prefer CLI and some prefer command line debuggers. That's fine. You can use whichever suits you better, but please don't use debug statements unless you absolutely have to.

Yeah, valgrind counts as a good debugging tool. GDB counts as well.
But tools can be used improperly too. Don't forget that. Tools must be used right to unlock their true potential.

Originally Posted by MutantJohn

Well, does valgrind count?

I pretty much use flags to find up unto a part where my code seg faults, mostly. Also to make sure my calculations are accurate, etc.

I don't understand why you would eschew a debugger, a tool which is capable of instantly and 100% accurately pinpointing a segfault.

Originally Posted by MutantJohn

Alright, I'll take that into consideration. Not going to lie, the only thing I want from it is for it to tell me which address are failing. Valgrind does but I have no idea what those variables are called in my code. Will gdb be able to translate those addresses into the same names of the variables I'm using?

Often, that's all you need the debugger for.

Provided you've compiled with debug information (the -g) flag, just run the code under the debugger and when it crashes, type "where" and it will show you a full stack trace and the exact line number which crashed. That's always the first step, and the debugger greatly accelerates that.

EDIT: If the code crashes while not running the debugger, you can still debug it if you have a core dump. Just run "gdb MyProg core."

Unfortunately, modern Linux distros tend to either turn off core dumping or redirect it to some kind of user friendly crash handler, which is not developer friendly. But it can all be re-enabled if you want.

there are also graphical wrappers for gdb that you can use, even if you don't like IDEs, it's still nice to see the code as you're stepping through it. several of the advanced text editors available for Linux/X have makefile and gdb integration.

A thought to keep in mind: You spend more time correcting your code than writing it. So it can really be said that programming is the act of debugging. That being the case, the most important tool of a programmer is the debugger. The programming language is just an inconvenient middle step.

Learn to use your debugger and you'll become a programmer.

Originally Posted by MutantJohn

I'm one of those guys like std100something

I am that guy!!

A piece of advice: as I have written here: std::endl vs “\n”, "However, notice that I strongly suggest you to use std::endl when debugging."

I can recall several times that I did not get the output I expected, when debugging, because I did not use std::endl;.

What you say about print and cout has been into my mind too, but I usually overload the operator, or write a function.

It is a fact that I use output for debugging. However, this does not mean that I discourage you from learning using the debugger.
I have used it some times, but maybe I haven't get used to him yet.

You see, 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.
So, I strongly suggest you to learn to use a debugger, to see what are the differences and use what suits you best.