I’ve never been much to use C++ I/O streams and have always opted for what I know.
i.e. the printf functions.
I know there are some benefits to using I/O streams, but I’m looking for some tips
from the stackoverflow community to help me (or convince me) to switch. Because I still
prefer printf and I think the printf style is so much easier to read and quicker to type.
I would still like to be familiar with it even if I still continue to use printf.
Edit. Interestingly, google C++ coding style forbids the use of streams except for logging.
See: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Streams
Use streams only for logging. Definition: Streams are a
replacement for printf() and scanf().Pros: With streams, you do not need to know the type of the object you
are printing. You do not have problems with format strings not
matching the argument list. (Though with gcc, you do not have that
problem with printf either.) Streams have automatic constructors and
destructors that open and close the relevant files.Cons: Streams make it difficult to do functionality like pread(). Some
formatting (particularly the common format string idiom %.*s) is
difficult if not impossible to do efficiently using streams without
using printf-like hacks. Streams do not support operator reordering
(the %1s directive), which is helpful for internationalization.Decision: Do not use streams, except where required by a logging
interface. Use printf-like routines instead.There are various pros and cons to using streams, but in this case, as
in many other cases, consistency trumps the debate. Do not use streams
in your code.Extended Discussion
There has been debate on this issue, so this explains the reasoning in
greater depth. Recall the Only One Way guiding principle: we want to
make sure that whenever we do a certain type of I/O, the code looks
the same in all those places. Because of this, we do not want to allow
users to decide between using streams or using printf plus
Read/Write/etc. Instead, we should settle on one or the other. We made
an exception for logging because it is a pretty specialized
application, and for historical reasons.Proponents of streams have argued that streams are the obvious choice
of the two, but the issue is not actually so clear. For every
advantage of streams they point out, there is an equivalent
disadvantage. The biggest advantage is that you do not need to know
the type of the object to be printing. This is a fair point. But,
there is a downside: you can easily use the wrong type, and the
compiler will not warn you. It is easy to make this kind of mistake
without knowing when using streams.cout << this; // Prints the address cout << *this; // Prints the contentsThe compiler does not generate an error because << has been
overloaded. We discourage overloading for just this reason.Some say printf formatting is ugly and hard to read, but streams are
often no better. Consider the following two fragments, both with the
same typo. Which is easier to discover?cerr << "Error connecting to '" << foo->bar()->hostname.first << ":" << foo->bar()->hostname.second << ": " << strerror(errno); fprintf(stderr, "Error connecting to '%s:%u: %s", foo->bar()->hostname.first, foo->bar()->hostname.second, strerror(errno));And so on and so forth for any issue you might bring up. (You could argue, “Things would
be better with the
right wrappers,” but if it is true for one scheme, is it not also true
for the other? Also, remember the goal is to make the language
smaller, not add yet more machinery that someone has to learn.)Either path would yield different advantages and disadvantages, and
there is not a clearly superior solution. The simplicity doctrine
mandates we settle on one of them though, and the majority decision
was on printf + read/write.
I’m not a big user of streams myself, so I’ll only list what I think about them. This is really subjective, I’ll understand if my answer is voted for deletion.
I may have a
enum, aclassor anything else, making my user defined type printable is always done by providing the sameoperator<<next to my type :You may ask yourself if a type is printable, but never how it is printable.
Obviously, it is incredibly easy to provide ‘streaming capacities’ to a user defined type. It’s also a great to be able to provide our own implementation of a stream and have it fit transparently in an existing code. Once your
operator<<are appropriately defined, writing to standard output, a memory buffer or a file is trivially changeable.I’ve always thought
iomanipto be a mess. I hate writing things such as (I’m just throwing random manipulators here) :I think it was much easier with
printf, but Boost.Format is helpful here.