Debugging

Graduating this May with BS in CS and I've only ever debugged with couts or printlns.  Am I doing it wrong?  No one ever taught us how to use a built in debugger so I guess it's not that important?

You're pretty much fucked OP, your degree is useless in the real world.

If you can't use a debugger, source control management tools, various *nix tools and IDEs, understand regular expressions and numerous application and systems development APIs and technologies outside of the basic standard libraries that you might have used with the languages you've learned, you're fucked.

If you don't understand the nuances of concurrency, socket programming, and database management systems, you're double-fucked.

Real developers don't use cout or println for even regular I/O, let alone debugging.

Best get cracking on trying to learn some of this stuff on your own personal projects if you want to find a job in the field that pays more than bottom of the barrel $30,000 a year.

>>4
For file I/O, developers in the know use the lowest level file I/O system calls. On POSIX systems, this means using open, close, read, write, lseek. On Windows, this means, CreateFile, CloseHandle, ReadFile, WriteFile, SeekFile. They also use asynchronous file I/O to read in large portions of files at a time in another thread without blocking.

For logging messages, they'll build an abstraction system with runtime polymorphism that allows for log messages to be written to a variety of sources, whether that be the terminal, a file of a particular format, over a network, to a debugger window or IDE, or a database. Behind that, they may use printf or cout, but it's all abstracted away, they aren't using printf/cout directly.

Iostreams in C++ have a huge cost performance wise, they use shit tons of virtual calls, way more than is necessary, and that means lots of cache misses every time you use them for I/O. So at the very least, most developers use printf if they have to.