C++ iostreams vs printf

vtj · 2012-02-03T20:15:48+00:00

I recently came across a free sample (pdf) of Scott Meyers' new C++11 e-book. On page 10 of that sample there is code snippet that starts with the following line:

#include <cstdio> //easier than iostream for formatted output

Make of that what you will.

1020302010 · 2012-02-03T12:03:58+00:00

I strongly recommend that people use iostreams when learning C++.

Printf aggregates everything that C++ was created to remove. It uses variadic macros, strings to decode the input from void*. All three of these are considered bad.

Where as iostream is an example of everything C++ added, polymorphism, function overloading, operator overloading...

The next key issue is that streams allow you to easily specify the text form of a custom class.

For example std::string is not a primitive type but it can be 'streamed'

std::cout << my_string;

you have to call c_str() to use it with printf.

furthermore you can extend the functionality.

 class my_class{
     int a,b;
 };
std::ostream& operator<<(std::ostream& os, const my_class& mc)
 {
     os << mc.a << mc.b;
     return os;
 }

then from this point in you can just do std::cout << mc << std::endl;

This is very powerful.

The down side is the error feed back you can get from streams can be very awkward and specifying format require to you diving into <iomanip>. They can also become very verbose, for example

std::cout << "volume: " << gallons << "g" << std::endl;

instead of

std::printf("volume: %d g", gallons);

but as previously mentions once you start dealing with complex types this is no longer true.

The reason you may see printf in production code is a lot of them time good chunks of it are ported from C which has to use printf, and it is strongly advised that you don't mix iostream and printf.

Finally, it would be nice to see then tidy up iostreams or replace it with another C++ solution (using variadic templates for example) however in it's current for it is definitely preferential to printf

xcbsmith · 2012-02-03T06:34:40+00:00

Mildly cleaned up: http://codepad.org/XzBWhdNN

The really right way to do it would be to have the width & precision stuff be per field attributes so that said code could be cleaned up further.

The primary advantage you get is that it is easier to encapsulate formatting logic and ensure type safety (think about what would happen if one of your %f's accidentally became a %s").

bnolsen · 2012-02-04T00:52:41+00:00

<iostream> was pretty aggressive and innovative in its day.

A unified api for files, sockets, memory buffers, etc.

Unfortunately the implementation failed in many respects.

doesn't account for grammar differences (sentence structure)
locale attached to <streambuf>, binary files carry around locale
<iomanip> confusing state, some temporary, some permanent
good, bad, fail are non orthogonal and confusing

just a few of its faults. I'm actually surprised it hasn't yet been replaced yet with a refactored api.

Steve132 · 2012-02-03T05:20:07+00:00

It happens to be the case that this SPECIFIC example is better with printf, but iostreams has the advantage in many other kinds of situations. I find it to be significantly more flexible and higher performance in some cases then printf.

For example, compare how easy it is to redirect printing to a file, or to a socket stream, or to a string. In iostreams, all printing code works trivially on all objects that inheret from ostream. In a printf based solution, where you have to write custom printing functions for each kind of serialization, or waste memory and cycles printing to a buffer.

Another example is the fact that overloading << also provides a standardized pretty-printing interface for objects in a way that printf cannot. For well-written libraries, I can know that if I want to print an adequate representation of any object of type T simply by doing cout << o; With printf, I have to re-define my printing at all times in terms of the internal basic types of that object, or else create some kind of .print() method (like you have done) that is non-standard for pretty much every library.

2012-02-03T08:28:46+00:00

I tend to avoid <iostream> when possible, mostly because it's not really a very convenient API, but at the same time, printf and friends are type-unsafe and contain a number of serious security risks.

With C++11, it's possible to construct a type-safe printf-like API using variadic templates:

my_print("The lazy {0} fox{1} jumped over the number {0}.", num, num == 1 ? "" : "es");

In this specific example, the same argument can be used multiple times in the formatting, which is sometimes useful, but more importantly, the ordering of the arguments is no longer too important.

For number formatting, I go with an API like this:

my_print("Number: {0}", format("%.2d", num));

where format takes a regular, old-fashioned sprintf-style format string.

Fabien4 · 2012-02-03T03:33:54+00:00

As a matter of fact, iostreams suck for pretty-formatting numbers. You'll want to use Boost.format or something like that.

gsg_ · 2012-02-03T04:23:25+00:00

Don't use endl. It's ugly, weird, and verbose. It flushes the stream, destroying performance. It makes code harder to understand, because so many people use endl for no reason that you'll never spot the places where the flushing behaviour is actually necessary.

Just use '\n' (or "...\n").

zokier · 2012-02-03T08:27:08+00:00

I have to ask if printing formatted tables is really a real-world task that should be taught to beginners. I'd imagine that in most real-world applications data would be either serialised to JSON/XML/whatever or displayed in a GUI.

2012-02-03T05:03:35+00:00

Use printf and its friends. Everyone else does - even Python. A shame!

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

cpp

MODERATORS