iostream - Should I switch to C++ I/O streams? -

i've never been use c++ i/o streams , have opted know. i.e. printf functions.

i know there benefits using i/o streams, i'm looking tips stackoverflow community me (or convince me) switch. because still prefer printf , think printf style easier read , quicker type.

i still familiar if still continue use printf.

---

edit. interestingly, google c++ coding style forbids use of streams except logging. see: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

streams

use streams logging. definition: streams replacement printf() , scanf().

pros: streams, not need know type of object printing. not have problems format strings not matching argument list. (though gcc, not have problem printf either.) streams have automatic constructors , destructors open , close relevant files.

cons: streams make difficult functionality pread(). formatting (particularly common format string idiom %.*s) difficult if not impossible efficiently using streams without using printf-like hacks. streams not support operator reordering (the %1s directive), helpful internationalization.

decision: not use streams, except required logging interface. use printf-like routines instead.

there various pros , cons using streams, in case, in many other cases, consistency trumps debate. not use streams in code.

extended discussion

there has been debate on issue, explains reasoning in greater depth. recall 1 way guiding principle: want make sure whenever type of i/o, code looks same in places. because of this, not want allow users decide between using streams or using printf plus read/write/etc. instead, should settle on 1 or other. made exception logging because pretty specialized application, , historical reasons.

proponents of streams have argued streams obvious choice of two, issue not clear. every advantage of streams point out, there equivalent disadvantage. biggest advantage not need know type of object printing. fair point. but, there downside: can use wrong type, , compiler not warn you. easy make kind of mistake without knowing when using streams.

cout << this;  // prints address  cout << *this;  // prints contents  

the compiler not generate error because << has been overloaded. discourage overloading reason.

some printf formatting ugly , hard read, streams no better. consider following 2 fragments, both same typo. easier discover?

cerr << "error connecting '" << foo->bar()->hostname.first      << ":" << foo->bar()->hostname.second << ": " << strerror(errno); fprintf(stderr, "error connecting '%s:%u: %s",       foo->bar()->hostname.first, foo->bar()->hostname.second,       strerror(errno));  

and on , forth issue might bring up. (you argue, "things better right wrappers," if true 1 scheme, not true other? also, remember goal make language smaller, not add yet more machinery has learn.)

either path yield different advantages , disadvantages, , there not superior solution. simplicity doctrine mandates settle on 1 of them though, , majority decision on printf + read/write.

i'm not big user of streams myself, i'll list think them. subjective, i'll understand if answer voted deletion.

• i : homogeneity

i may have enum, class or else, making user defined type printable done providing same operator<< next type :

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

you may ask if type printable, never how printable.

• i : abstraction

obviously, incredibly easy provide 'streaming capacities' user defined type. it's great able provide our own implementation of stream , have fit transparently in existing code. once operator<< appropriately defined, writing standard output, memory buffer or file trivially changeable.

• i dislike : formatting

i've thought iomanip mess. hate writing things such (i'm throwing random manipulators here) :

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

i think easier printf, boost.format helpful here.