std::string and std::cout

[Nubcake95]

When including iostream I see a lot of other files being included aswell but I just don't understand this -> Why can I declare a string (std::string) but not insert it into the output stream via std::cout without including the string class?

Thanks

[giblit]

You should be able to but anyways if you are using a string class object you should include the string header because you get to use all the neat functions for it. http://www.cplusplus.com/reference/string/

[Nubcake95]

It doesn't work for me unless I include <string> (using VS2010) , I need to know why it does not.

#include <iostream>

int main()
{

       //I can declare a string see here
	std::string mystr = "Hello World";
	std::cout << mystr << std::endl;    //Error no operator '<<' matches these operands
       return 0;

}

[giblit]

Your compiler probably doesn't have string in the iostream library but it will always be in the string library. What you are trying to do is use a vector without including the vector library.

http://www.cplusplus.com/forum/beginner/13356/

[naraku9333]

Because the definition of operator<< that handle std::string is in <string>

[Nubcake95]

@naraku9333
Thanks I get it now , that's exactly what I was wondering about.

Edit: I omitted the <string> and I used the operator[] to set the value of a part of the string. How does that work ? I mean it compiles and all but is this just random or a special case for operators? It's part of the <string>.

[Cubbi]

is this just random or a special case for operators

No, it's a special case for Visual Studio, which happens to include a part of <string> internally, inside <iostream>. With another compiler/library, this won't compile at all.

To write a portable program, you need to #include the appropriate headers for everything you use: <string> for std::string, <vector> for std::vector, <iostream> for std::cout, etc.

[Nubcake95]

Thanks Cubbi that clears it up , I was really confused there for a second ; You wonder why it works then find out it's compiler specific. :)
Edit: I can't seem to find a compiler where it doesn't work.

[Cubbi]

Edit: I can't seem to find a compiler where it doesn't work.

You might be right: now that I looked at the actual chains of includes that lead from iostream to string in a few libraries, it may be true that it's a requirement: two of the member functions of std::cout (imbue() and getloc()) return std::locale objects by value, so to compile it, the compiler must be able to see the entire class definition of std::locale.

std::locale::name() returns std::string by value, so to compile std::locale, the compiler must see the class definition (but not the non-member operators such as I/O) of std::string.

Just to appreciate the complexity behind the scenes, in dinkumware-derived libraries (IBM, and I believe Microsoft, too), <iostream> includes <istream>, which includes <ostream> which includes <ios>, which includes <xlocnum>, which includes <streambuf>, which includes <xiosbase>, which includes xlocale>, which includes <xlocinfo>, which includes <xstring> (technically, because their internal class _Locinfo has three private data members of type std::string. the chain didn't even reach locale::name())

in stlport-derived libraries (used by Sun), even quicker, <iostream> includes <stl/_istream.h> which includes <stl/_ios.h>, which includes <stl/_ios_base.h> which includes <stl/_string.h> because their std::ios_base has a private data member of type std::string.

In the best-designed (in my opinion) implementation, libc++, <iostream> includes <ios>, which includes <__locale>, which includes <string> for the sake of std::locale::name() only, no surprise private members.


Still, although it's an interesting bit of trivia, do include the headers for the thigns you use.