Should I switch to C++ I/O streams? [closed]

问题

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 7 years ago.

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 contents 

The 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.

回答1:

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 like : homogeneity

I may have a enum, a class or anything else, making my user defined type printable is always done by providing the same operator<< next to my type :

std::ostream &operator<<(std::ostream &, const MyType &);

You may ask yourself if a type is printable, but never how it is printable.

• I like : abstraction

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 dislike : formatting

I've always thought iomanip to be a mess. I hate writing things such as (I'm just throwing random manipulators here) :

std::cout << std::left << std::fixed << std::setprecision(0) << f << std::endl;

I think it was much easier with printf, but Boost.Format is helpful here.

回答2:

Use boost::format. It's got the best of both worlds.

回答3:

The massive advantage that iostreams offer is safety. printf() is an inherently unsafe function. Not just that, but it's trivial to overload << for your own types, whereas it's realistically impossible to extend printf()- this has the added advantage of instantly overloading for output to files as well, and anything else connected to a stream. In combination, these make printf() unusable in high-quality code. I've also noticed absolutely no performance difference, although I see many people posting about how slow they are.

回答4:

@Matt, I'm with you. I've always hated streams. Sure, I can use them. Make them do pretty much anything I want. But I like printf because I prefer the syntax.

I even wrote a strprintf that worked exactly the same as sprintf except returned a std::string instead of writing to a char buffer.

But gradually, begrudgingly, I have almost completely stopped using sprintf. Because, simply speaking, I write too damned many bugs and I get sick and tired of going over and over my same mistake time & time again. stringstreams type safety saves me from myself.

The bugs I'm talking about for me come in 2 forms, mainly:

1. I picked the wrong magic number for my output buffer. Say I come up with char buf_[256] to format up a little something. Well, just like Bill Gates famously attributed comment that "256KB of memory ought to be enough for anybody," I'm wrong on the low side enough to catch my eye. On the other hand, what am I going to do? char buf_[1024*64]? Extreme, but you get the point. There's no perfect magic number. You either expose yourself to more crashes, or you waste memory.

2. I sprintf-ed a string, but sent it a float. Do this all the time. Well, not all the time. For every 100 calls to sprintf, I probably do this once or twice. For production code, that's a lot.

With streams neither of these can ever happen. So I use streams now, and my code never crashes. Well... there, anyway.

Some will say that streams are slower than sprintf. Eh, maybe. For the sake of argument, I'll even just go along with it. Doesn't matter much though. I work on real-time stock market servers that routinely process 3 million messages per second, all day long. And I've never had a problem with the speed of streams. Maybe it's a little slower, but I've got bigger fish to fry.

回答5:

You cannot extend printf with new format specifiers to handle your own types.

回答6:

You get more protection against type errors with C++ I/O streams, but they are SLOW. So it mostly depends on how important performance is.

I/O streams are also polymorphic, unlike the C stdio functions, the user of a stream doesn't need to know whether it's connected to a console, file, or some other logic. But this isn't important for most applications.

回答7:

I switched to iostreams after I learned C++ 10 years ago. Several years ago I was convinced that it was a bad choice so I switched back. I did not regret the switch. For a good C++ programmer you need to know both.

Google C++ style guide prefers to use printf/sprint/snprint over iostreams. It says to use iostreams only for logging.

In terms of iostreams benefits:

• Type safety. Compiler (gcc) can detect type errors, as well as all static analysis tools. Even there is a type error, one can spot the error easily from the print out.
• Extensibility. Yes iostreams have overloading but all data members eventually go to POD types.
• No buffer overrun. Use snprintf to overcome the buffer size issue.

Now come the benefits of sprintf:

• Much better readability. "Record(%d): %s\n" is much easier to read than os << "Record(" << i << ") " << msg << endl;
• Performance. If you are doing a lot of iostreams stuff, changing them significantly improves performance. I once worked on a library that uses stringstream to convert int/doubles to strings. I replaced with sprintf and performance has improved a lot (there are a lot of calls to the conversion routine). For the record, boost::format has even worse performance.

My conclusion is that to use iostreams sparely. I use it to read memory buffer, or write to memory buffer occasionally. For other work, I use plain C function.

回答8:

To follow up on Noah's answer, boost's format library allows for several different syntaxes, including printf like syntax. It works by overloading the % operator, and so at first appears a little strange. But, something I rather like, it allows you to reuse arguments. For example

cout << format("%1% %2% %1%") % 1 % 2 << endl;

will print

1 2 1

It's pretty versatile and if you can get used to the % signs everywhere, gives you the best of both worlds. As I agree, printf style is often much much easier.

http://beta.boost.org/doc/libs/1_43_0/libs/format/doc/format.html

来源：https://stackoverflow.com/questions/4339523/should-i-switch-to-c-i-o-streams