[PATCH] Include explicit instantiations of iostream inserters and extractors in string.cpp.

[Howard Hinnant]

On Sep 21, 2013, at 7:26 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:

> On Sat, Sep 21, 2013 at 07:09:48PM -0400, Howard Hinnant wrote:
>> On Sep 21, 2013, at 6:59 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
>> 
>>> On Sat, Sep 21, 2013 at 05:23:18PM -0400, Howard Hinnant wrote:
>>>> Can you show a conforming example that demonstrates this problem?  My thinking has been that there is no way to use these functions in a conforming manner wtih including <{i,o}stream>.
>>> 
>>> This is what I had in mind:
>>> 
>>> TU1:
>>> ========================================================================
>>> #include <iosfwd>
>>> #include <string>
>>> 
>>> void f(std::ostream &os, const std::string &s) {
>>> os << s;
>>> }
>>> ========================================================================
>>> 
>>> TU2:
>>> ========================================================================
>>> #include <iostream>
>>> #include <string>
>>> 
>>> using namespace std;
>>> 
>>> void f(ostream &os, const string &s);
>>> 
>>> int main() {
>>> f(cout, "hello world");
>>> }
>>> ========================================================================
>>> 
>>> I believe this is conforming, but I may be mistaken.
>>> 
>>> Thanks,
>>> -- 
>>> Peter
>> 
>> I believe 17.6.2.2 [using.headers]/p3 makes TU1 non-conforming:
>> 
>>> A translation unit shall include a header only outside of any external declaration or definition, and shall include the header lexically before the first reference in that translation unit to any of the entities declared in that header. No diagnostic is required.
>> 
>> #include <ostream> is required in TU1.
> 
> Would #include <iosfwd> not satisfy this requirement as for the
> reference to std::ostream?  I haven't found anything that would
> prevent the forward declarations in <iosfwd> from being considered
> declarations for the purpose of [using.headers]p3.
> 
> Thanks,
> -- 
> Peter

I know that the intent on the LWG is that if the definition is used, the definition has to be available.  If the definition is an inline or template, it has to be in the TU.  My understanding is that if the standard doesn't currently say it, if brought to the attention of the LWG, they will make it say it.  At least that is the impression I've repeatedly been left with from the LWG over the years.  I'm not aware of a change in position on this matter.

Howard