#include <iostream>
// using namespace _; is strongly discouraged, especially for beginners.
class Help {
private:
int name;
public:
void setName(int newValue) // no reason to accept a pointer parameter
{
int *n = &name;
*n = newValue;
}
void printInfo()
{
std::cout << "Name: " << name;
}
};
int main()
{
Help help;
// Call setName here to set help's Name
help.setName(12);
help.printInfo();
return 0;
}
// using namespace _; is strongly discouraged, especially for beginners
How can it be that? It is the first thing our instructors taught me in the first C++ course I learned C++. And they see it as perfectly fine when I use them.
#include <iostream>
usingnamespace std;
//http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practiceclass Help{
private:
int Name;//not a good 'name', usually associated with std::string
public:
Help() {}
Help(constint* n){Name = *n;};//implementing this overload
void setName(constint *n)//const qualify variables wherever possible
{
Name = *n;
}
void printInfo()const//also const qualify methods wherever possible
{
cout << "Name: " << Name << "\n";
}
};
int main()
{
Help help;
int x = 12;
constint y = 22;
constint* p = &x;
help.setName(p);
help.printInfo();
Help help1(&y);//overloaded ctor
help1.printInfo();
}
Thanks! Is there anyway to do it while accepting a pointer in the setName function? I am following a ULM diagram for a larger problem that accepts pointers in the functions.
How can it be that? It is the first thing our instructors taught me in the first C++ course I learned C++.
...And your instructors are wrong.
In the very worst case, the introduction or removal of a name more preferable to the overload resolution rules by either the first or third party (the implementer of the imported namespace) can silently change the behavior of your program.
Usually this issue exhibits itself as otherwise-compliant code that compiles and works fine under one implementation but not under another. Still, take it from experience that random name collisions and unexpected macro anaphora are terrible to diagnose. They have no apparent cause.
For this reason, namespace imports should be restricted to locally importing small first-party namespaces containing only implementation details.
Sanboro - in addition to Max's reply above, check out this link and then go and speak with your instructors. JLBorges has a description of such instructors, 'career teachers' which is very apt:
@Sanboro
If you have a need to continue to use usingnamespace std; in your course, you have other choices to use it while avoiding side-effects :
You can clearly state which standard objects you will be using, like this :
1 2 3 4 5 6 7 8
using std::cin;
using std::cout;
using std::endl;
int main()
{
cout << "Hello World!!!"; // You can now write it without std::cout
}
If your instructors does not "like" new stuff, other way is you can use the namespace in your function, it is the best practice. I don't recommend use the namespace in global area.
1 2 3 4 5
int main()
{
usingnamespace std;
cout << "Hello World!!!"; // You can now write it without std::cout
}
In the end you should still avoid using namespace std, the first one is better. I know that writing std:: everywhere is a little bit tedious but the first method is always the best.