[llvm-bugs] [Bug 41563] New: operator<<(ostream, string) declared in <string> but defined in <ostream>

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41563

            Bug ID: 41563
           Summary: operator<<(ostream, string) declared in <string> but
                    defined in <ostream>
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: smeenai at fb.com
                CC: eric at efcs.ca, ldionne at apple.com,
                    llvm-bugs at lists.llvm.org, mclow.lists at gmail.com

$ cat f.cpp
#include <iosfwd>
#include <string>
void f(std::ostream &os) { os << std::string("Hello world!\n"); }

$ cat main.cpp
#include <iostream>
#include <string>
void f(std::ostream &);
int main() { f(std::cout); }

$ clang++ f.cpp main.cpp
Undefined symbols for architecture x86_64:
  "std::__1::basic_ostream<char, std::__1::char_traits<char> >&
std::__1::operator<<<char, std::__1::char_traits<char>,
std::__1::allocator<char> >(std::__1::basic_ostream<char,
std::__1::char_traits<char> >&, std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced
from:
      f(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) in
f-e729ff.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The operator<<(ostream, string) overload is declared in <string> but defined in
<ostream>, so if you just include <string>, you end up with an undefined
reference to it which results in a link error, as demonstrated above. It links
successfully if I change f.cpp to include <ostream> instead of <iosfwd>.

I don't know if this would necessarily be considered a bug, but I find it
strange that you can end up in a situation where you include a header and have
all the declarations needed to compile, but then have to pull in another header
to actually be able to link.

My above test case was run with Xcode 10.2, but in theory you should have the
same issue with upstream libc++.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190423/3715c89d/attachment.html>