Howard: Funny you should ask... Since I've joined Bloomberg LP and become their core librarian, I've been removing some dependencies on <cassert> (because Bloomberg has its own assert macros) and <iostream> (because of the cost you mention) galore. Dependencies on malloc were the worst because malloc (which is used by the default allocator in our uses of stlPort) is a tightly regulated function at Bloomberg. In many cases, using <iosfwd> works just fine in the headers. (No problem using <iostream> in the .cpp though.) One typical case I remember was someFunction(std::ostream errorStream = std::cerr); In this case, we got rid of 'cerr' by replacing the function with two overloads: someFunction(); // use cerr in the documentation, but only needed in the .cpp someFunction(std::ostream errorStream); Of course, if someFunction is a function template or member function of a class template, that technique breaks, but then if one is really using cerr in there, there's not much that can be done. In that case, we usually try to push the use of cerr down into some non- template utility class, where we can use the technique above. So far, I think there are no #include <iostream> in any of the header files I'm responsible for. Knock on wood. -- Hervé Brönnimann hervebronnimann@mac.com On Nov 18, 2006, at 10:20 AM, Howard Hinnant wrote:
<iostream> is the only C++ header that extracts a cost simply by including it (in typical implementations). The usual implementation is for it to include a static object of type std::ios_base::Init which is responsible for initializing the 8 terminal streams (cin, cout, cerr, clog, wcin, wcout, wcerr, wclog).
I've always thought it good programming practice to avoid including <iostream> if the translation unit didn't actually need one of these 8 terminal streams. For example if I needed to just get to istream and ostream to write my own I/O I would include <istream> and <ostream> but not <iostream> (the naming is very unfortunate).
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.
-Howard
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost