Re: [boost] none_t I/O operators

Subject: Re: [boost] none_t I/O operators
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2011-06-05 17:35:35

On 05/06/11 21:29, Gregory Crosswhite wrote:
<snip>
> On a more serious note, though, is there a trick one can use to write
> I/O operators like the ones I defined above without necessarily pulling
> in <iostream>?

#include <iosfwd>

On no account should you write your own forward declarations for
standard library objects.  It will cause you grief if and when you (or
your users) try to e.g. use libc++, which declares them in a different
namespace.

> I am of course aware of the existence of forward
> declarations, but unless my understanding of them is wrong (and
> hopefully it is :-) ) they cause compiler errors when the forward
> declared class has already been actually declared, so using forward
> declarations would break in the case that the user had already pulled in
> <iostream> before the forward declarations appeared.

There is no such issue with forward declarations in general.  There is
an issue when they involve default arguments, which some of these ones
will.  This is however a consequence of the same argument being given
more than one default value, and is independent of whether the
declaration appears before the definition.

However, <iostream> will certainly have included the same forward
declarations provided by <iosfwd> anyway, so multiple-include guards
will prevent the forward declarations appearing after <iostream> has
been included.  Therefore, #include <iosfwd> is safe.

> Or, on the other hand, is the relative overhead of pulling in <iostream>
> actually relatively small in the grand scheme of things so that this is
> something that a library writer should not worry about in general when
> thinking about supplying I/O operators for a supplied type?

One should always be cautious of including <iostream>.  Not only is it
general good practice to include minimally and a habit that is wise to
develop, but <iostream> has the unusual property that it has a (small)
runtime overhead in the program initialization phase for each
translation unit that includes it to ensure that all the global objects
are properly initialized.

John Bytheway