Why do I need to type in using namespace std;
in order to be able to use cout
and endl
? Also what are these called; is cout
a function?
Is there cout
in C? I heard it was implemented in C++ because it is better in many ways.
Why do I need to type in using namespace std;
in order to be able to use cout
and endl
? Also what are these called; is cout
a function?
Is there cout
in C? I heard it was implemented in C++ because it is better in many ways.
cout
is a global object defined in the std
namespace, and endl
is a (stream manipulator) function also defined in the std
namespace.
If you take no action to import their names into the global namespace, you won't be able to refer to them with the unqualified identifiers cout
and endl
. You have to use the fully qualified names:
std::cout << "Hello, World!" << std::endl;
Basically, what using namespace std
does is to inject all the names of entities that exist in the std
namespace into the global namespace:
using namespace std;
cout << "Hello, Wordl!" << endl;
However, keep in mind that have such a using
directive in the global namespace is a BAD programming practice, which will almost certainly lead to evil name clashes.
If you really need to use it (e.g. if a function of yours is using many functions defined in the std
namespace, and writing std::
makes the code harder to read), you should rather restrict its scope to the local scope of individual functions:
void my_function_using_a_lot_of_stuff_from_std()
{
using namespace std;
cout << "Hello, Wordl!" << endl;
// Other instructions using entities from the std namespace...
}
Much better, as long as this is practical, is to use the following, less invasive using declarations, which will selectively import only the names you specify:
using std::cout;
using std::endl;
cout << "Hello, Wordl!" << endl;
No! You do not need using namespace std
, and you shouldn't use it. Use fully qualified names std::cout
and std::endl
, or, in a small scope,
using std::cout;
using std::endl;
As for the other questions, std::cout
is not a function. It is a kind of global output stream object bound to the standard output. And there isn't an std::cout
in C.
std
namespace, it is ok to do it –
Mapel using namespace std;
–
Mapel std::
, and even if you do, you cannot know the names that will appear in future versions of the C++ standard library. –
Merrillmerrily using namespace std;
brings the names in a collection of names (called a namespace) into the current scope. Most textbooks seem to encourage the use as follows:
#include <iostream>
using namespace std;
int main()
{
//Code which uses cout, cin, cerr, endl etc.
}
Some people discourage its use in this manner because you could have unexpected collisions with names when namespace scopes overlap and will encourage you to use the fully qualified names like std::endl directly
You have other options such as
a) exploiting the scoping rules to temporarily bring in the namespace
int main()
{
{
using namespace std;
//Code which uses things from std
}
//Code which might collide with the std namespace
}
b) or only bring in the things you need
using std::endl;
using std::cin;
In answer to your last question cin is a stream object (a collection of functions and data that supports the stream extraction and insertion operators >> and << )
cout and endl are members of the standard library in C++. If you want to use them without the using statement, just prepend the namespace:
std::cout
std::endl
This might be of use to you:
http://msdn.microsoft.com/en-us/library/bzbx67e8(VS.80).aspx
cout
does not exist in C.
Typically, "using namespace std" is declared only in small learning projects, never in real programs. The reason is that you do not need to include everything from that namespace into your code, first of all because it is takes time for compiler to do that. Stroustrup himself writes that this is bad taste. And it is better than printf in C, because it is type-safe and can be easily overloaded for your own types without needing to change the library classes.
© 2022 - 2024 — McMap. All rights reserved.
cout
is not aC
library and there are many who would argue with the notion that it is "better in many ways." :-) – Characharabanc