This question already has answers here:
Why does omission of "#include <string>" only sometimes cause compilation failures?
(7 answers)
Closed 7 years ago.
Here is my code:
#include <iostream>
int main(int argc, char const *argv[])
{
std::string s = "hello";
std::cout << s.size() << std::endl;
return 0;
}
To my surprise, I can compile and run it with clang++, though I even don't add #include <string>.
So, is it necessary to add #include <string> in order to use std::string ?
Your implementation's iostream header includes string. This is not something which you can or should rely on. If you want to use std::string, you should always #include <string>, otherwise your program might not run on different implementations, or even in later versions of your current one.
In short: yes, it is necessary.
Parts of standard library often use other parts, so <string> was included somehow through <iostream>, and your code compiles nicely.
If you accidentally decide that you don't need <iostream> anymore and remove that include, <string> will be implicitly removed, too, and you get a confusing compilation error. That's why it is a good practice to put all necessary includes.
Some header might include other headers, but that's an implementation issue and not something you can count on. Always explicitly include the headers you need.
iostream includes <string>. It ripples through.
Well actually that's implementation dependant and not a guarantee. You should explicitly include the headers you need.
Related
This question already has answers here:
C++ code compiles without include
(2 answers)
Why does omission of "#include <string>" only sometimes cause compilation failures?
(7 answers)
Closed 3 years ago.
So I am learning C++ at the moment, and at some point I saw that you "have to" #include <string> at the top of your code to use strings.But when I run my code, it does the same thing in both cases.So is it really needed to use it?
#include <iostream>
using namespace std;
int main()
{
string fullName;
cout << "Type your full name: ";
getline(cin, fullName);
cout << "Your name is: " << fullName;
}
Some compiler implementations include the header <string> in the header <iostream>.
But you shall not rely on this.
A compiler is not required to accept your program if you don't.
It might (coincidentally) be included through a different header and work anyway, but that might not be the case after your next compiler update or if you move to different platform.
Whether you "have to" include it is mostly down to how strict an environment you're working in – if you're hacking away at home you can do whatever, but if you're working for somebody else you're usually expected to Do The Right Thing.
Don't rely on transitive includes. Your implementation may include whatever it wants in other headers that may cause your code to work, but you cannot rely on that. A good, portable, robust program includes what it needs, when it needs it, explicitly. That way it stays working when you change compiler, standard library, Operating System, etc.
In C++, #include just says to paste the code from the file included into that location. If something is already #includeing string, then the compiler won't care if anything after it includes it.
This does not mean you should do that! Always include what you need. Don't rely on other headers, especially those from libraries, including anything for you.
I am exploring the work on cstring inside a C++ code. One of the functions that is commonly used is strrev().
But I found that this function is considered undefined on Mac & Linux, even if I included the header file <cstring> or <string.h>.
However, the function works fine on Windows.
(I am aware that I can define the function myself as the solution presented in here strrev not available on Linux)
This might be a very naive question, but aren't the definitions of header files supposed to be the same across different platforms? or does each platform have a different definition of the header file?
Another weird thing that is I did not find strrev() in the description of the <cstring> header file (cstring header file description), but if I don't include this header file on Windows I get an error and the error is resolved when I include it.
One of the functions that is commonly used is strrev().
Actually, other than in programming classwork, I can't think of any viable reason why strrev() would be useful. I don't think I've had a need for such a beast in my entire multi-decade career :-)
The reason it's not defined in some platforms is because it's not mandated by the C++ standard.
The reason why it's defined in some other implementations is because the standard dictates what must to be made available, not what mustn't. In other words, implementations are allowed to include it, they're just not required to include it.
An implementation can choose to include all sorts of wonderful extra stuff, provided it doesn't break any of the stuff mandated by the standard.
It's an implementation specific decision to include certain functions other than the standard ones.
However, in C++, you may use std::reverse from <algorithm> header to reverse the string.
Here's an example:
#include <iostream>
#include <algorithm>
int main()
{
char s[] = "Hello World!";
std::reverse( std::begin(s), std::end(s) );
for ( const auto& i : s )
{
std::cout << i;
}
return 0;
}
Output string:
!dlroW olleH
here is a link where you shall find the list of function & class that should be in the header according to the standard : http://www.cplusplus.com/reference/
About the question on the header itself, C++ standard does not propose one uniformed header, but the list of what is required.
And the definitions in the headers will even vary for the same compiler, from one target to another (32 or 64 bits, etc.. ). If you check the iostream header for GCC, for instance, it includes 3 files :
#include <bits/c++config.h>
#include <ostream>
#include <istream>
the header under the bits/ directory usually vary from one target to another, and you don't directly include it in your own application.
This question already has answers here:
Removing '#include <algorithm>' doesn't break the code
(7 answers)
Closed 4 years ago.
#include <iostream>
using namespace std;
int main(int argc, const char * argv[]) {
int arrr[5] = {21,124,1521,123,1};
sort(arrr,arrr+5);
return 0;
}
As you can see above, I don't use #include <algorithm> but I can use the sort() function! Why? I don't know.
<iostream> doesn't have #include <algorithm>
Please tell me why this works.
I'm using Xcode on Mac OSX.
In C++, including any standard header is allowed (but certainly not required) to have the same effect as including any or all other standard headers.
In this case, it appears that some part of the implementation of <iostreams> used an algorithm from <algorithm>, so your inclusion of <iostreams> accidentally included <algorithm> as well.
Of course, you don't want to depend on this--on a different implementation, your code can (and often will) fail. Even updating your compiler (or possibly even just using different compiler flags) could prevent your code from compiling.
Whether standard headers include other headers is unspecified. It is not guaranteed that a standard header won't include any other standard headers. Standard (draft) quote:
[library] / [requirements] / [conforming]
/ [res.on.headers]
A C++ header may include other C++ headers. [snip]
So, std::sort happened to be declared, since it happened to have been included by <iostream>. But that was neither guaranteed by the standard, nor is it against the standard.
Consider the following code:
#include <iostream>
using namespace std;
int main () {
srand(time(0));
double dd [10];
for(int i=0;i!=10; ++i) dd[i]= rand()%5+0;
for(auto i:dd)
cout<<i<<' ';
cout<<endl;
exit(100);
}
Why is it compiling without the #include<ctime> and #include<cstdlib> for the calls to time(0) and exit(100)(which is absolutely useless there, I know)? Are they already included in iostream?
The C++ standard, section 17.6.5.2 [res.on.headers], says:
A C++ header may include other C++ headers.
Which means an implementation is free to include other headers when you include one of them. From an implementor's point of view, that's just quite practical, of course.
There are even headers which are guaranteed to include others. For example, <string> implies <initializer_list>.
As for <iostream>, it implies <ios> (which itself implies <iosfwd>), <streambuf>, <istream> and <ostream>. So there is no guarantee for <ctime> and <cstdlib>, and you should include them explicitly for better portability.
To find out which headers are guaranteed to include others, you can either have a look yourself in the standard or in a draft (see all the synopses starting in section 18), or just go to cppreference.com, for example http://en.cppreference.com/w/cpp/header/iostream for <iostream>. It's quite a reliable online C++ reference.
Or you just explicitly include every header you need. Which may be the best choice in the end.
Yes, iostream includes cstdlib (at least in your case; you should not rely on that dependency chain).
Your compiler might have an option to list the dependencies, e.g. for the GNU C compiler, you can use the -M flag to list all includes.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
I'm learning C++ and I got stuck on why this happends. This code will compile and run perfectly, however if I uncomment the //cout << foo << endl; it won't compile.
#include <iostream>
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
string foo = "temporary";
//cout << foo << endl;
// Pause then exit
system("pause");
return 0;
}
I solved it by adding: #include <string>. Can anybody tell me why this is becuase to me (coming from C#) this doesn't make sense why you are allowed to create a string object but not printing it?
Thanks!
When you #include <iostream>, it's up to the header to include whatever other headers and consequence declarations and definitions it wants - the C++ Standard doesn't forbid it including more than is strictly necessary to provide the required functionality. Clearly, with your compiler/version, #include <iostream> is also including enough of the string related definitions to know there's a template <...> std::basic_string::basic_string(const char*); constructor (std::string is a typedef to a specific instantiation of basic_string for char) such that your code is known valid:
string foo = "temporary";
Still, when you went to stream foo, it clearly hadn't seen a matching definition ala template <...> std::ostream& operator<<(std::ostream&, const basic_string<...>&) that specifies how streaming is to be performed: that's why the compiler complained. The definition for operator<< is probably in your <string> header, which is why it really is needed before streaming a string.
You can observe this yourself by asking your compiler to output and not delete preprocessed files, which show the translation unit after #includes have been expanded. You'll find the options to do so somewhere in your project's build configuration.
All up, that's why you might sometimes have code work with fewer includes than are strictly necessary. If you realise you've done this, it's always a good idea to include the other headers, ensuring portability to other compilers and future versions of the same compiler.
The standard library documents per § 21.3 [string.classes] that using the string classes, their members, operator overloads, etc, requires inclusion of <string>. Any reliance that a different header does so, either of your own devices or some other header to include said-same, is non-standard compliant unless documented it does so (includes <string>). The insertion operator you're using is described in § 21.4.8.9 [string.io], but ultimately the same rules apply: include <string>.
You can speculate what may be allowing compilation to succeed without including <string> by avoiding using that inserter overload. Perhaps the operator overloads for std::basic_string are included in a manner that is not fulfilled by simply including <iostream> on your implementation.
That speculation makes little difference in the end, however. That is all it would be: speculation. Ultimately you're code is not well-formed because you're not following the rules per the standard, which thankfully in this case is trivially addressable.