   A quick question...
  Hello, I am a newbie programmer, I have learned a little java and python before jumping into C++, by taking a course at the nearby community college.The course is moving a bit slowly for my taste, so I began to look around for some decent articles after reading ahead in my book.I've seen most places consider using "using namespace std;" to be a generally bad idea.I have talked to my professor about this, and he chastised me for working ahead, and suggested I move at the pace of the class >.> .I'm not well versed in C++ yet, but why would "using namespace std;" be a bad idea?? I cannot seem to get the answer out of my professor.Also, I was using Dev-C++, however I have recently downloaded Visual C++ Express 2005, as well as 2008 beta 2. I was wondering what differences in compiling these might have from Visual C++ 6.0, which is the compiler the class uses.   
  I'm not too sure, I haven't heard this argument but I imagine it's no deeper than name clashes.  That it's safer to just use fully qualifying names.  Just prevention from future errors that could be a pain to catch.  Such as using a function that you believe belongs to one namespace when it belongs to another.  So, it's safer to not use 'using' at all, except maybe within the scope of a function where it's easily contained.   ;  as a general rule it's "never use 'using' in header files".The reason is because then anyone who #include's your header will be forced to also be "using" that namespace, this can cause name collisions in their code and is generally the most hassling thing in the universe.Within the bounds of your own .cpp files, use whatever floats your boat (but remember that a using statement will affect any headers that are included after the using statement.I tend to never use 'using' statements because it's more clear to me to see std::vector or MySpace::elitefunction, than it is to see vector (not least of which because it makes me think of the mathematical vector structure, not the dynamic array [smile] )-me   ;  well, the majority of the code i do is very basic.I mean a program to print 10 random numbers is 8 chapters ahead of the class >.>#include <iostream>#include <cstdlib>#include <ctime>using namespace std;int main () { int count = 0; srand(time(NULL)); do  {  cout << 1 + rand % 20 << endl;  count++; }while(count <= 10); return 0;}I consider this very basic.I think we won't even learn how to create our own header files in the course I am taking.   ;  Namespaces are a means of removing naming collisions from code.Lets use an example to illustrate it's value.  One common type of computer science data structure is a 'stack', and the STL implements such a container, and calls it 'stack'.  So all is well and good so far, but lets say you have been programming the low-down parts of a project for a while now, and have created your own thing that you've called 'stack' [which is okay since you have not included the STL implementation, or do not know such an implementation even exists], perhaps even something with similar functionality [though it does not have to be, of course].  Now, you/someone else who is working on the higher-level components of the same project decide that it is best to use an STL stack container for a given purpose, so they include the stl version of stack, and decide to type in 'using namespace stl' too, so they don't have to constantly type stl::.  It has just become ambiguous which class is referred to by the term 'stack', which means the compiler will throw up a huge number of errors, leaving you with many places to change your code to change your own instance of 'stack' to something else [since you can't change the name of the STL container to something that isn't 'stack'], which could very easily introduce bugs [especially if your stack has similar functionality to the STL stack implementation, including member names].  If you were using namespaces, you can unambiguously specify what 'stack' you're talking about, since there would be std::stack, and there would be myOwnNamespace::stack, removing the need to change anything, and removing any chance of naming conflicts.  More importantly, it removes any chance that there'll be a naming conflict later, when somebody else includes something else.So, in an implementation file somewhere, you're dealing extensively with the stl version of 'stack', and are sick and tired of typing 'std::' over and over.  At the top of that implementation, you can use 'using namespace std' to remove the need to type std::, and do so in a way that won't propagate the merged together namespace down into other files.The actual value of namespaces doesn't really even exist until you start dealing with *BIG* projects, often with several [even several dozen] people working on them, which is when the likelihood of name collisions becomes very high.  Small school projects don't really highlight the value of namespaces, but large projects really do benefit from the added layer of organization.  Look at it this way, consider that your teacher wants to collect every single student's project 1 [whatever it is] to present as a demonstration of the classes efforts, and compile it all together.  What do you think are the chances that such an action will result in thousands of 'function already defined elsewhere' errors.  If everyone was assigned their own namespace, there would be no errors, and the whole class could work together without worry.   ;Quote:Original post by LeeLI have talked to my professor about this, and he chastised me for working ahead, and suggested I move at the pace of the class >.> Heh, he probably actually meant "Stop working ahead, I haven't learned that part yet!".   ;Quote:Original post by HodgmanHeh, he probably actually meant "Stop working ahead, I haven't learned that part yet!".heh, that would explain the syntax errors >.>... edit: and the "it's all in the book!", and "Well i havent gotten that error before." , and ... Wow, Drigovas, I must heartily thank you for that explanation, really cleared things up!   ;  Yep, education for programming really does get that bad. Sorry to hear about your experience.   