Boost logo

Boost :

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
    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
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: 
> listinfo.cgi/boost

Boost list run by bdawes at, gregod at, cpdaniel at, john at