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:
>> 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
> 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
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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk