Howard Hinnant wrote:
It has recently come to my attention that I could be overly sensitive to this issue and making a fuss about nothing. So I'm writing here for a reality check. Do boost programmers consider the use of <iostream> as a short cut to get to non-terminal-streams I/O a reasonable technique? Or do boost programmers feel that use of <iostream> should be reserved only when using one or more of cin, cout, cerr, clog, wcin, wcout, wcerr, wclog?
I did a brief survey of boost 1.33.1 and found many "relaxed" uses of <iostream> under the boost/ directory (i.e. non test-case code). So in practice it does appear that using <iostream> as a shortcut is considered acceptable practice. However I wanted to highlight the point just in case people do view this as a bug that has simply snuck in under the radar to date.
Well it snuck under *my* radar I admit. I think the problem here is that it's tricky to ensure that you have all the necessary headers included: different implementations may or may not flag up an error depending which headers you've included, so including <iostream> is a sort of "belt-and-braces" approach. But in principle you are correct. As an aside, I've always wanted a sort of "conceptual" std lib implementation, that included in each header nothing except what absolutely has to be there. Just the declarations would do, so we could do compile-time tests against it to verify inclusion of the right headers: the only tricky bit is getting the compile time constants correct so that it can still compile meta code. Any volunteers? :-> John.