9

I find that it is tremendously easier to use streams in c++ instead of windows functions like ReadFile, WriteFile, etc or even fprintf. When is it not good to use streams? When is it good to use streams? Is it safe to use streams? How come a lot of programmers don't use streams?

This is just something I've always wondered about and maybe you can shed some wisdom.

Brian T Hannan
  • 3,925
  • 18
  • 56
  • 96
  • 2
    The boost::format library is another alternative that provides type-safe printf-like formatting: http://www.boost.org/doc/libs/1_41_0/libs/format/doc/format.html – Void - Othman Jan 21 '10 at 18:30
  • Frequent use of `boost::format` may hurt your performance badly. In a project using Boost 1.33, I had to stop using boost::format because of performance issues (measured with a profiler). – Danilo Piazzalunga Feb 26 '10 at 10:52
  • Thanks, that's good to know. I have never actually tried boost, but seeing as it is so popular I should probably check it out sometime. – Brian T Hannan Mar 01 '10 at 16:01

7 Answers7

11

Streams are generally quite safe. Under some circumstances, they can be slow and/or clumsy. Slow, mostly stems from the fact that they impose a few extra layers between your code and the OS, and under the wrong circumstance those layers can add overhead. The clumsiness is mostly in comparison to C's printf, not direct use of something like WriteFile (which doesn't directly support formatting at all). For example, however, consider:

printf("%2.2x", ch);` 

to

std::cout << std::hex << std::setw(2) << std::setprecision(2) << std::setfill('0') << ch; 
std::cout << setfill(' ');

Then consider the fact that if you care about i18n, printf is using a string that's easy to read in from an external source, where the C++ stream is embedding all the formatting into the structure of the code, so nearly any change in formatting requires rewriting the code, recompiling and relinking.

CreateFile, ReadFile, etc, also allow a number of things like memory mapped files and overlapped reading and writing that aren't supported by iostreams at all. If the situation lets you make good use of these, iostreams often won't be competitive.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • 2
    For the benefit of those not working with it usually, "i18n" from this post means "internationalization". There's 18 characters in between the 'i' and the 'n' in that word, hence "i18n". – Kevin Anderson Jan 21 '10 at 18:13
  • *printf still can't be used for i18n because the position and type of the variables is hard-coded. – rpg Jan 22 '10 at 10:38
  • @rpg:1) at most, that reduces, but does not eliminate i18n capabilities. 2) with POSIX printf, the positions aren't really hard coded either. Bottom line: printf isn't even close to perfect, but it's still a *lot* better than iostreams in this respect. – Jerry Coffin Jan 22 '10 at 14:04
10

When is it not good to use streams?

  • Streams are not guaranteed to be thread safe. It's easy to dream up a situation where you can not use streams without some synchronization.
  • Stream objects are typically pretty "heavy". They may be too heavy for low memory or embedded environments.

When is it good to use streams?

In general.

Is it safe to use streams?

Yes, but you've got to be careful when sharing a stream asynchronously.

How come a lot of programmers don't use streams?

Preference, style, or they learned a different method (or different language) first. I find that plenty of old "c++" examples online are written with a C-flavor to them, prefering printf to cout.

luke
  • 36,103
  • 8
  • 58
  • 81
4

You can't do asynchronous file i/o with streams ...

Goz
  • 61,365
  • 24
  • 124
  • 204
3
  1. When you want your app to be portable to different platforms.

  2. When you want more succinct code: win32 functions have more elaborate semantics, often require a collection of functions to do something, and definitely have more parameters.

Hassan Syed
  • 20,075
  • 11
  • 87
  • 171
1

One of the reasons I like printf() is that format strings themselves can be resources, thus allowing for more external control over program output without forcing recompilation.

One of the reasons I like cout() is it's raw speed.

In my experience, this tends to be a fairly religious issue.

dicroce
  • 45,396
  • 28
  • 101
  • 140
1

one reason is i18n

string time = "4:32";
cout << "the current time is " << time;
cout << "वर्तमान समय " << time << " है।"
cout << time << "في الوقت الحالي هو";

vs

string format = "the current time is %s";
string format = "वर्तमान समय %s है।";
string format = "%s في الوقت الحالي هو";
printf(format, time);
Anurag
  • 140,337
  • 36
  • 221
  • 257
1

There are three alternatives you've mentioned here:

  1. C++ streams (ostream, istream, fstream)
  2. C stdio (printf, sprintf fprintf)
  3. Windows files (ReadFile, WriteFile)

Options 1 & 2 are platform independant. This means you can compile the code for mac, linux, or many other operating systems. Option 3 is Windows only. That means you cannot compile it for anything but Windows.

When deciding between options 1 & 2, it is up to how you want to use it. The C library is easier to use regarding languages. It's a nightmare trying to replace text with alternative languages in streams, however it's much easier to make streams thread-safe, translate more complicated classes to a printable format, and extend stream capabilities.

C++'s iostream versus C's stdio is a highly heated argument which is discussed in many other places in this forum such as C++ Streams vs. C-style IO? and other places online.

Community
  • 1
  • 1
Stewart
  • 4,356
  • 2
  • 27
  • 59