Printable View
using namespace std
using std::Command
std::cout << something; std::cin >> anything;
Its the same but I think that the first-line method is more handy, even if you have 2-3 commands to include.. But fairly often I see two other methods in someones code. Why so? Maybe they're differs in memory usage or whatever? Can anyone explain me?
I know, its nonsense. But Im asking myself - 'why so?'.. So I need any answer to be quiet :)
It's about personal style. The third is used mainly to get into the habit(no, it's only cause it's more professional looking :p ) I like the first one :D
Yes yes, me too! :PQuote:
I like the first one
Professional looking? I say messy.
using namespace std; is kinda a newbie work around. Do a board search and you'll find a couple thousand threads on why it should be avoided.
Indeed! Search::"namespace std" found 99999999999s threads...Quote:
Do a board search and you'll find a couple thousand threads
Anyone who have a time please explain me why shoud I avoid to use "using namespace std"?
How about doing a simple search and READING the threads. Its been discussed at length and in depth many times before.
Thantos is right, there are plenty of places that can be searched to find that answer. However, here is yet another explanation attempt:
When you put the using directive into your code, it means that all names that are in the namespace can now be used without having to explicitly state which namespace they are from. So, if you put "using namespace std;" into your code, then anywhere inside that scope you could just type cout instead of explicitly stating that you are using the cout in the std namespace.
That seems easier to you, why would you want to always explicitly state that you want to use the cout from namespace std, right? Well, there are all kinds of things in the std namespace, not just cout. As your code gets more complicated and you use other third party libraries, or you use classes written by other programmers or even yourself from a different project, you start to lose track of all the different names that are being used in your program.
Eventually, it becomes more and more likely that you will be using two different things - classes, variables, enums, functions or anything else with a name - that have the same name. If you are lucky, the compiler will complain, if not, it might just choose a different one than you intended without you ever knowing it. That is the point of namespaces - to group names together that are used in the same set of code so that it can be used with other code without fear of naming conflicts. If std has a cout and your partner's class is called cout, then the compiler knows which one you are referring to if you explicitly state the namespace it is in.
When you have very small programs, all of which are in one file and use only one or two classes and a couple header files, then chances are slim that you'll get any naming conflicts. That is why many newbies prefer the using directive - it is easier and not very dangerous for them. Also, many people used to older C++ that did not use namespaces also put in the using directive as a simple way to update their code to the new standard.
I always explicitly type std:: (unless making modifications to someone else's code), and I would recommend you and all newbies do the same. That's just a recommendation, it's not the end of the world if you don't. It just helps you get into that habit, so in 6 months or a year when you work on a big project not only are you used to seeing std::, but you even start to like the look of it better. At the very least, if you want to use a using directive, I'd suggest putting it inside the function you want to use it in, or only add a using directive for the specific names you want, rather than bringing in the entire namespace.
Now its clear... And its not 'the same' as I think before :\ Thanks for explanation, jlou.
While it is better to try to avoid using namespace, it's not that bad to use it.
This is particulary true for the std namespace, because programmers will avoid using names that conflict with the standard C++ ones.
It's not like using void main, or anything like that.
I cannot see that actually happening. Please give an example of an unintentional use of a symbol.Quote:
Originally Posted by jlou
When we try to modify x we have to specify which x we want to use, like:Code:namespace A
{
int x = 1;
int y = 1;
}
//This namespace is hidden away in some header
namespace B
{
int x = 2;
int z;
}
//Some left-over global variables
int x = 3;
int w = 3;
using namespace A;
using namespace B;
int main()
{
y = 0; //Legal
z = 0; //Legal
w = 0; //Legal
x = 0; //Error: ambiguous symbol
}
What should be avoided is the using-declaration within header files and other namespaces.Code:A::x = 0;
B::x = 0;
::x = 0;
I would think these problems are rare, especially if you are on your toes, however here is an example:Quote:
Originally Posted by Sang-drax
Result: undefined behavior with no compile errors. Output: 5578235 on my machine.Code:// Deep in a header in a library somewhere
int count(int* array1, int* array2, int numElements)
{
int sum = 0;
for (int i = 0; i < numElements; i++)
{
sum += array1[i];
sum += array2[i];
}
return sum;
}
// In main.cpp
// Ooops, forgot to #include <algorithm>
#include <iostream>
using namespace std;
int main()
{
int A[] = { 2, 0, 4, 6, 2, 3, 2, -7 };
const int N = sizeof(A) / sizeof(int);
cout << "Number of twos: "
<< count(A, A + N, 2)
<< endl;
}
In fact, in MSVC++ 6.0, even if you don't forget to include the <algorithm> header, it still uses the wrong count method and outputs the large value.
If you had explicitly typed std::count, however, then a compile error would have made you realize that you forgot the correct header, at which point you'd fix it and then the correct function would be called.
If you have two choices, and one has a remote chance of biting you in the butt, but is easier by a few keystrokes to implement, then I would recommend the one that takes a few more keystrokes and a little getting used to, but doesn't have the same dangers as the easier way. That's just my opinion.
I prefer using none of those methods and including <iostream.h> instead of iostream. In <iostream.h> you don't have to do anything with namespace std!
>>I prefer using none of those methods and including <iostream.h> instead of iostream. In <iostream.h> you don't have to do anything with namespace std!
...
does your compiler yell at you a lot?
<iostream.h> is no longer standard... As JaWiB is getting at, the compiler really should scream at you for using it instead of the standard one, although many compilers have that file for backward compatibility.
My compiler never screams at me, are u kidding me?
Hmm what a good idea for a project: A compiler that will audiobly berate you for errors and warnings. Something in a sarcastic brithish tone
Heres another question on this topic, whats so bad about using "using std::cout;" instead of putting "std::" infront of each cout? Or is it no difference, or is there another big 4 paragraph story about why you shouldnt? :D
Good question. I'm also wondering this. I've heard this is better than the first choice (using namespace std), but that is all I know...
hmm... which compiler are you using, C++Child?
The fact is that namespaces now exist, and using deprecated headers solely to avoid them is just sticking your head into the sand.
It may not be bad, from what I see.Quote:
Heres another question on this topic, whats so bad about using "using std::cout;" instead of putting "std::" infront of each cout? Or is it no difference, or is there another big 4 paragraph story about why you shouldnt?
For example, in a header file or the code of some library, it would make sense to use the entire identifier.
On the other hand, within main() one might want to use the using directive and then avoid being bothered by the prefix.
>>>>>>>>>>Hmm what a good idea for a project: A compiler that will audiobly berate you for errors and warnings. Something in a sarcastic brithish tone
Hmmm, I like that idea, "You included [#include <iostream.h>]! Make sure you include [#include<iostream>] or else I'll hack your registry! *snickers*"
>>>>>>What compiler are you using.
Borland C/C++ Compiler 5.5 (BCC55 Command Line)
I agree. The risk is small, but is is there.Quote:
Originally Posted by jlou
The more specific syntax is OK to use.Code:using namespace std; //Should perhaps be avoided
using std::cout; //OK to use
Some guidelines for using namespaces then:
- Do not put using-declarations at the global scope or directly within other namespaces in header files
- Try to avoid "using namespace XX", as there is a (very small) risk that something could go wrong within larger projects.
Using "using std::cout;" has the basically the same problems as "using namespace std;", except they are confined to cout, which of course is even more unlikely to be used as a name somewhere else. I certainly wouldn't tell anybody they are forming a bad habit if they used that form. For other namespaces besides std that are longer and more cumbersome to type (or may be nested several namespaces deep), I use that form inside functions or other small scopes, so it certainly has its place. At this point I am only arguing style, but for the std namespace, it just seems to make more sense to use "std::" everywhere.
Ha! - all in one paragraph! ;)
Hmm... I kind of like the Fritz chess program... Nothing quite like getting yelled at in German for making a stupid mistake.Quote:
Originally Posted by Thantos
Your example would give an error at compile-time if "using namespace std;" was replaced with "using std::count;", so I'd say it's safer to use.Quote:
Originally Posted by jlou
Also, I think this thread is great.
I think he meant that you can still run into the same errors that you can with a normal 'using namespace ...' statement. It is safer in a sense, though, if you are the only one modifying the code, because whenever you do import a particular symbol, it should register in your mind if it conflicts with something else you put in.
Yes, but how?Quote:
Originally Posted by Zach L.
Show me some code. :)
Take the same example and then add the #include <algorithm> :) Assuming the 'using' behaves the same way (I haven't tried it) when using specific parts of the namespace or entire namespaces, it should still give the 'wrong' output.Quote:
Originally Posted by Sang-drax
I say this because jlou said even after including the header it still used the wrong function, which makes sense if you think about it... because when a function without a namespace identifier is called, and there's a choice between a 'real' global function and a 'pseudo' global function resulting from the using statement, who wouldn't go for the real function? :D
The basic problem is that you override something without being aware of it. You can still do that, but it is a bit les likely because you are (hopefully) aware of what you explicitly imported into the namespace. Other programmers working on the same code, however, may not. I'll post a concrete example later.
Any standard-conforming compiler would issue an error "ambiguous command", or something equivalent. The "real" function would not be called.Quote:
Originally Posted by Hunter2
The question is currently whether using-declarations like this one
can result in the wrong func being called somewhere.Code:using N::func;
I haven't been able to find such a case, but we have earlier seen that this can happen when using
Code:using namespace N;
This is just for fun, it is not in any way an attempt to say that using std::count is bad. But there are still the same types of errors that could occur - name conflicts or unknowingly using the wrong name. Here is my contrived example.Code:// In MyClass.h
#ifndef MYCLASS_H_
#define MYCLASS_H_
#include <iostream>
using std::cout;
using std::endl;
#include <algorithm>
using std::count;
class MyClass
{
public:
MyClass() {
sizeOfA = 8;
A = new int[sizeOfA];
for (int i=0; i<sizeOfA; i++)
A[i] = (i%3)+1;
}
void PrintItemCount(int item) {
cout << item << " count: " << count(A, A + sizeOfA, item) << endl;
}
private:
int* A;
int sizeOfA;
};
#endif // MYCLASS_H_
Code:// In HelperFunc.h
#ifndef HELPER_FUNC_H_
#define HELPER_FUNC_H_
int count(int* array1, int* array2, int numElements)
{
int sum = 0;
for (int i = 0; i < numElements; i++)
{
sum += array1[i];
sum += array2[i];
}
return sum;
}
#endif // HELPER_FUNC_H_
Result: undefined behavior - on my machine it crashed. Since HelperFunc.h wasn't included, the code found the std::count included in the MyClass.h header file. Because the using std::count was put in that header file, the main code used the algorithm count instead of the intended one.Code:// In main.cpp
// Maybe this header is included by another header deep in a library somewhere.
#include "MyClass.h"
// Oops! Forgot to #include "HelperFunc.h"
#include <iostream>
using std::cout;
using std::endl;
int main()
{
int array1[] = { 2, 0, 4, 6, 2, 3, 2, -7 };
int array2[] = { 5, 8, 0, 4, 1, 1, -4, 2 };
// Try to use the count in HelperFunc.h
cout << count(array1, array2, 8) << endl;
}
This is more of an indictment on putting using directives in header files, but there you go.
Nice example jlou... You saved me from having to think later on. :)
And, the problem may just throw a compile-time error, or crash, and not be a subtle little bug, but it is nice to be able to reuse those names for your own functions/objects on occasion.
Since MSVC isn't a standard-conforming compiler, it would (theoretically).Quote:
Any standard-conforming compiler would issue an error "ambiguous command", or something equivalent. The "real" function would not be called.
And since MSVC isn't a standard-compliant compiler, it would seem that it can - and that was the point I was trying to make :)Quote:
The question is currently whether using-declarations like this one
using N::func;
can result in the wrong func being called somewhere.
OK jlou, but your example has using-declaration in header files, which is bad for other reasons as well.
What I wanted (I was unclear) is an example of the same phenomenon, but only with using-declarations in source files (if it exists).
Umm, MSVC++ does issue an error.Quote:
Since MSVC isn't a standard-conforming compiler, it would (theoretically).
What version are you using? The lastest three version are quite conforming and this is a relatively basic feature.
Of course it exists Sang-drax, but at some point it crosses over into the realm of "that would never happen - I'm not stupid enough to ever do that." I think bringing in a single name from a namespace is perfectly acceptable, preferably inside the scope of a function or loop where it is being used. Bringing in a single name from a namespace at the top of a source file can also be acceptable in my personal opinion, but I don't think it would necessary in most cases, especially for the std namespace.
So, here is my example of a using directive in a source file that only brings in a single name and causes unwanted behavior.Code:// In HelperFunc.h
#ifndef HELPER_FUNC_H_
#define HELPER_FUNC_H_
int count(int* array1, int* array2, int numElements)
{
int sum = 0;
for (int i = 0; i < numElements; i++)
{
sum += array1[i];
sum += array2[i];
}
return sum;
}
#endif // HELPER_FUNC_H_
Result: undefined behavior. On my machine it crashes.Code:// In main.cpp
// Oops! Forgot to #include "HelperFunc.h"
// In main.cpp
#include <iostream>
#include <algorithm>
int main()
{
int array1[] = { 2, 0, 4, 6, 2, 3, 2, -7 };
int array2[] = { 5, 8, 0, 4, 1, 1, -4, 2 };
using std::cout;
using std::endl;
using std::count;
// Use std::count
cout << count(array1, array1 + sizeof(array1), 2) << endl;
// ...
// Try to use the count in HelperFunc.h
cout << count(array1, array2, 8) << endl;
}
Your last example results in undefined behavior even if HelperFunc.h is included.Quote:
Result: undefined behavior. On my machine it crashes.
std::count is called in both cases even if the header is included.
What I didn't realize at first was:
But if one using-declaration is omitted, all calls to f will revert to the other one because the functions are compatible.Code:namespace A
{
int f(int);
}
namespace B
{
int f(char);
}
using A::f;
using B::f; //Possible because the two fs are a little different
Really? Well, I guess the using directive is more dangerous than I thought. ;)