Why I can't compile without the using namespace std line?

I need to add .h in some libraries in order to being recognized by G++, but some others works without the .h extension. Why is that??

Recommended Answers

All 6 Replies

Why I can't compile without the using namespace std line?

You can, but you have to qualify things.

Things like cout and string and transform() are all defined in the std namespace. If you don't using namespace std (to tell the compiler that all the stuff in std is also in the current namespace) then you must explicitly tell the compiler where to find it.

#include <iostream>

void uses_everything()
  using namespace std;  // import everything from 'std' into current
  cout << "everything in std is used here.\n";

void uses_cout()
  using std::cout;  // import only 'cout' from 'std' into current
  cout << "Only 'cout' was used here.\n";

void uses_nothing()
  std::cout << "Nothing was used.\n";

int main()
  return 0;

There is a second issue here. Make sure that you never using anything in header files.

The file extension on header files has nothing to do with g++, but everything to do with the library author.

The C++ standard requires that certain headers take the form <iostream> and <algorithm> and <cstdio> and the like.

Some people think that was stupid, and use things like ".hpp", as in <boost/any.hpp> and the like.

Some librarys were written in C, or they follow the C convention, and have the ".h" extension, as in "regex.h" and the like.

Just about anything is possible, but most compilers do require you to stick to one of the mentioned conventions.

Hope this helps.

I just have two extra question: what is a namespace and why it's not necessary to put the using namespace line in windows?
Thanks for the responses

>>what is a namespace

A namespace is literally a "name-space". When programming large libraries, you need names for everything (e.g. data-types, variables, constants, classes, functions, parameters, etc., etc.). How do you make sure that the names that you pick will not conflict (or "clash") with other names in other libraries that a programmer might be using at the same time as yours? The answer is: you put it in a namespace. A namespace creates a little private world (or space) where you can name things the way you want to without fear that it will clash with other names, because those other names will be in other namespaces. It is also a way to "hide" parts of your library by putting it in another sub-namespace that is not published (often that "hiden" namespace is called "detail", by convention). For example, if I wanted to make my own version of std::vector, but I didn't want it to be confused with std::vector, but still enjoy the nice and intuitive name "vector" for the class, I could do this as so:

namespace my_lib { //this puts all the stuff between { } into namespace 'my_lib'

template <typename T>
class vector {


//The user can now use both, without conflict:
int main() {
  std::vector<int> v1; //using the standard version
  my_lib::vector<int> v2; //using my library's version.

The statement "using namespace std;" or "using namespace my_lib;" means that you "import" all the names that are defined in the std namespace into the current scope where the statement appears. This should seldom be used because it defeats the initial purpose of namespaces (protect against name clashes). If you use several different libraries and make a "using namespace.." statement for each of the namespaces of all those libraries, the code could break in unexpected ways if there are conflicts between the same names appearing in different libraries (afterall, there aren't that many words in the English dictionary!).

>>why it's not necessary to put the using namespace line in windows?

I assume you are talking about windows API libraries (like windows.h or winbase.h and so on). This is because windows API is written in C, not in C++, and namespaces don't exist in C. Microsoft people could, of course, get off their lazy butts and make a C++-friendly version of their API libraries, but that's unlikely to happen. This also means that you have to be extra careful not to "overuse" the Win32 API, or more precisely not to "over-include" its headers. Only include windows headers where you need them, try to limit yourself to only cpp files (avoid including any kind of C library in a header file).

The two important rules for writing header files: "Don't write 'using namespace ..;' in a header file" and "Don't #include C header files in your header files". These rules are part of the general philosophy of not polluting the name-space (the space of all available names). The idea is that if someone uses your library by including your header file, it should not have polluting side-effects such as importing an entire namespace from another library, or including a bunch of non-namespaced (i.e. global) identifiers from a C library.

commented: great :) +17

>>Don't #include C header files in your header files
That's one of YOUR rules that is frequently broken. I agree with the general pholosophy, but it doesn't really work that way in real-world programs and libraries.

>>Don't #include C header files in your header files

Oohh I didn't know it's wrong to do that.

Thanks for all your responses. I have it clear now. XD

>>Don't #include C header files in your header files

Oohh I didn't know it's wrong to do that.

It isn't wrong to do that.

You don't want to #include anything more than you absolutely must, but the whole point of #includes is to make stuff work.

How, for example, would the <sstream> header be able to specify anything useful without #including <string> ? You would have to duplicate information, and that is worse...

I always explain namespaces like having two friends named Jennifer. One is Jennifer Logan and the other is Jennifer Warner. When neither is present, I need to indicate that I am speaking about one or the other by using her full name. When one is present, I just call her "Jennifer", and I refer to the other by her full name. If both are present, I must again specify exactly who I mean.

Hope this helps.

commented: Awesome analog for namespaces. +6
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, learning, and sharing knowledge.