tags:

views:

368

answers:

6

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.

+3  A: 
  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
+10  A: 

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
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
@kevin:oops, quite right. Thanks for the translation.
Jerry Coffin
*printf still can't be used for i18n because the position and type of the variables is hard-coded.
rpg
@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
+7  A: 

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
Most complete answer and it mentions the stuff about safety.
Brian T Hannan
+1  A: 

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
+4  A: 

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

Goz
+1  A: 

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