Re: [boost] none_t I/O operators

Subject: Re: [boost] none_t I/O operators
From: Gregory Crosswhite (gcross_at_[hidden])
Date: 2011-06-05 17:54:49

On 6/5/11 2:35 PM, John Bytheway wrote:
> 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.

Great, that is very good to know!  :-)

>> 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.
>

Excellent!  So even though my question was inspired by a silly 
misunderstanding about forward declarations, I seem to have nonetheless 
gotten very useful advice out of it.  :-)

>> 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.
>

Okay, great, that was actually my first instinct so I am glad to hear I 
was on the right track on at least one thing.  :-)

Thanks a lot!
Greg