title: Should I switch to C++ I/O streams?
body: <p>I've never been much to use C++ I/O streams and have always opted for what I know. 
  i.e. the printf functions.</p>
  
  <p>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.</p>
  
  <p>I would still like to be familiar with it even if I still continue to use printf.</p>
  
  <hr>
  
  <p>Edit.  Interestingly, google C++ coding style forbids the use of streams except for logging.
  See: <a href="http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml" rel="noreferrer">http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml</a></p>
  
  <blockquote>
    <p><strong>Streams</strong></p>
    
    <p>Use streams only for logging. Definition: Streams are a
    replacement for printf() and scanf().</p>
    
    <p><strong>Pros</strong>: 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.</p>
    
    <p><strong>Cons</strong>: 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.</p>
    
    <p><strong>Decision</strong>: Do not use streams, except where required by a logging
    interface. Use printf-like routines instead.</p>
    
    <p>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.</p>
    
    <p><strong>Extended Discussion</strong></p>
    
    <p>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.</p>
    
    <p>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.</p>
  
  <pre><code>cout &lt;&lt; this;  // Prints the address 
  cout &lt;&lt; *this;  // Prints the contents 
  </code></pre>
    
    <p>The compiler does not generate an error because &lt;&lt; has been
    overloaded. We discourage overloading for just this reason.</p>
    
    <p>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?</p>
  
  <pre><code>cerr &lt;&lt; "Error connecting to '" &lt;&lt; foo-&gt;bar()-&gt;hostname.first
       &lt;&lt; ":" &lt;&lt; foo-&gt;bar()-&gt;hostname.second &lt;&lt; ": " &lt;&lt; strerror(errno);
  fprintf(stderr, "Error connecting to '%s:%u: %s",
        foo-&gt;bar()-&gt;hostname.first, foo-&gt;bar()-&gt;hostname.second,
        strerror(errno)); 
  </code></pre>
    
    <p>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.)</p>
    
    <p>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.</p>
  </blockquote>