Like Tree13Likes

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

This is a discussion on Now that I'm used to C++, printf() >>>>>> cout >> endl; within the General Discussions forums, part of the Community Boards category; So, I've been using C++ for a little bit now and I love a lot of the language. But there's ...

  1. #1
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,283

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

    So, I've been using C++ for a little bit now and I love a lot of the language. But there's one thing I've noticed about C++ that's kind of weak when compared to C and it's mostly when I debug.

    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.

    So, the more I use C++ and am encountering more complex errors, I find myself using printf() simply because it's easier for me to type,
    Code:
    printf("(%f, %f, %f)\n", p->x, p->y, p->z);
    in lieu of
    Code:
    cout << "(" << p->x << ", " << p->y ", " << p->z << ")" << endl;
    Yeah, guess which one is easier to type? The answer is the first one!

    cout's useful because it'll just print anything but that's also a curse at the same time.

    When it comes printing things, I think I prefer printf() a lot more than cout even though cout makes things look soooo sexy.

  2. #2
    Registered User
    Join Date
    Oct 2006
    Posts
    2,590
    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.
    Code:
    namespace life
    {
        const bool change = true;
    }

  3. #3
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,308
    One option if you would like to use format strings with C++ I/O streams is to use Boost.Format.
    Elysia likes this.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #4
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,031
    Quote Originally Posted by MutantJohn View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,283
    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.

  6. #6
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,031
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #7
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by MutantJohn View Post
    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.
    Elysia and Elkvis like this.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  8. #8
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,283
    Idk. I do have gdb installed. But it's weird. I don't know how to use it! I know some commands like what was it, 'where'. Um... 'print local'? Is that one?

    At least with valgrind, it pretty much does everything for you.

  9. #9
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,676
    That's a silly reason. At one time, you didn't know C or C++, but you learned it, so learn GDB. Seriously, it will change your life as a programmer.It actually has amazing built-in help and tons of great tutorials and help pages on line.

    And yes, valgrind does give you great details about some problems, pretty much automatically, but they are slightly different tools. Honestly, I would say GDB is much more comprehensive.

  10. #10
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,283
    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?

    Like, seg fault at 0xFF3419A would suddenly become 'x' or whatever I called it.

  11. #11
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,676
    Yes, just compile with the -ggdb3 flag to include debug info in the program, and you can print variables, etc by name, examine the source code for a given function, etc.

  12. #12
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by MutantJohn View Post
    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.
    Last edited by brewbuck; 09-11-2013 at 03:15 PM.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  13. #13
    Registered User
    Join Date
    Oct 2006
    Posts
    2,590
    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.
    Code:
    namespace life
    {
        const bool change = true;
    }

  14. #14
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    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.
    whiteflags and Elysia like this.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  15. #15
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,694
    Quote Originally Posted by MutantJohn View Post
    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.
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. cout code, endl, and \n help?
    By ZezXion in forum C++ Programming
    Replies: 5
    Last Post: 11-15-2012, 06:16 PM
  2. printf to cout
    By crzy in forum C++ Programming
    Replies: 9
    Last Post: 04-28-2008, 04:05 PM
  3. cout << oct << -12 << endl; ?
    By manav in forum C++ Programming
    Replies: 1
    Last Post: 04-16-2008, 04:39 AM
  4. cout << SunTradingLLC << "is looking for C++ Software Developers" << endl;
    By sun trading in forum Projects and Job Recruitment
    Replies: 1
    Last Post: 04-02-2008, 12:48 PM
  5. printf/cout
    By Ivan! in forum C++ Programming
    Replies: 4
    Last Post: 03-02-2003, 03:23 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21