Thread: simple check.

Originally Posted by rogster001

i am intrigued - without wanting to divert this thread would like to hear your thinking on that.

Using namespace directives potentially cause ambiguity. For example, if there is a name in the global (unnamed) namespace that is the same as a name within namespace std, then any usage of that name will always be ambiguous after a "using namespace std" directive.

Once that ambiguity occurs, there are only two possible options to resolve it, since the effect of a "using namespace" directive can't be undone by any means except removing the directive.

The first approach to resolving such an ambiguity is to fully qualifying all names (i.e. prefixing all names with their namespace). That negates the point of the existing "using namespace" directive for all names where ambiguity has been introduced.

The second approach is to remove the "using namespace" directive, which then makes it necessary to ensure all names (except, optionally, those in the global namespace) are fully qualified.

Practically, for anything except the tiniest code samples, I find the effort of resolving such an ambiguity upon encountering it exceeds the effort of avoiding it in the first place (i.e. not employing any "using namespace" directives, and fully qualifying all names except - optionally - those that are local to a file or in the global namespace).

And since I generally write code with a view to maintaining it, using it in a larger system, or extending it ...... I find it better to simply avoid "using namespace" directives in real code. The only time I employ a "using namespace" directive is actually in code samples I post in forums.

I'm not fussed if people choose to employ a "using namespace" directive in their own code. They wear the impact. But a "using namespace" directive in a header file is a no-no, since it forces me to manage impacts whether I wish to or not. If I encounter a "using namespace" directive in a header file for a library, I do not use that library. Period.

Originally Posted by rogster001

Yes! that is the standard - Elysia has posted some good links on this if i recall, maybe she will drop one in this thread for you.

Actually, no.
The C++ standard says that main will implicitly return 0 if you don't add it yourself, so there is no need.
Whether it is good or practice omitting it is discussable, and I'm sure there are people on both sides.

I prefer just saying "using std::cout; using std::cin;" o3o

Originally Posted by Elysia

Actually, no.
The C++ standard says that main will implicitly return 0 if you don't add it yourself, so there is no need.
Whether it is good or practice omitting it is discussable, and I'm sure there are people on both sides.

I had no idea about that. I usually scramble to make sure main returns something. Thank you O:

Originally Posted by Mike Beal

i truly appreciate your help, but just to put it out there, I am very early on in learning.. Therefore I don't know of the terms vector or label.. and I will have to study this code for some time to fully understand each step. (there is alot going on that I am very unfamiliar with) However It DOES show me a more compact way of doing this and that's a start, even if I don't fully get it... YET

Fair enough. I accept you're on the learning curve.

vector and string, as I used them in the last sample, are names of type in the C++ standard library, and you'll find them eventually discussed in any decent textbook or reference material on C++. When you learn about templates (an important part of the C++ language, but there are plenty of things to learn before you can learn properly) you'll better understand what the syntax vector<string> means. For now, just look at "vector<string> label;" as declaring a variable named label that is a vector of strings. "label" is just an arbitrary variable name. A vector is a logical construct that contains a group of multiple elements.

Actually, no.
The C++ standard says that main will implicitly return 0 if you don't add it yourself, so there is no need.
Whether it is good or practice omitting it is discussable, and I'm sure there are people on both sides.

Yes I saw that i ahd got mixed up with the int main() / void main() thing - but i still didnt know about any implicit return value so nice one.

one way i can think of to reduce all the if statements are

Code:

#include<conio.h>
#include<iostream.h>
 int main()
 {
 	int obama=0,romney=0,bank=0,answer=0;
 	while(obama<5&&romney<5&&bank<5)
 	{
		cout<<endl<<"who do you want to see as president?";
 		cout<<endl<<"1.obama\n"<<"2.romney\n"<<"3.bank..";
 		cin>>answer;
 		switch(answer)
 		{
	 		case 1:obama++;
 					break;
	 		case 2:romney++;
	 				break;
			case 3:bank++;
					break;
			default:cout<<endl<<"what the??";
		
	 	}	
	 }
	 cout<<endl<<"obama->"<<obama<<endl<<"romney->"<<romney<<endl<<"bank->"<<bank;
	 getch();
 }

the braces can be avoidedlthis way
do give your feedback
cin.ignore() can be replaced by getch().


just keep this in mind when you move forward and become a high performance server programmer one day...a series of nested if statements is faster than a switch statement. Compared to if, a switch statement is only faster if there are 100 or more conditions.

Originally Posted by theju112

cin.ignore() can be replaced by getch()

getch() is non-standard, as is <conio.h>. Furthermore, the correct header is <iostream>, not <iostream.h>

Originally Posted by theju112

just keep this in mind when you move forward and become a high performance server programmer one day...a series of nested if statements is faster than a switch statement. Compared to if, a switch statement is only faster if there are 100 or more conditions.

Spoken like a true noob. Are you a troll or are you really that clueless?

Okay, let me put it clearly...
Anyone giving advice that ridiculous is not qualified to make ANY performance recommendations whatsoever! Kapish?!