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