Re: [boost] mistaken uses of <iostream>

From: Hervé Brönnimann (hervebronnimann_at_[hidden])
Date: 2006-11-20 22:34:11

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_at_[hidden]
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