   Std::
  Does the namespace "Std::" mean "standard"?If so, if it's the standard, why don't they just let you type it without the "std::" in front of it?  I mean, the standard would mean, that what it should assume you want if you say "string" or whatever.  I find the std:: not only is more typing work, but also lets it look less clear.If a modern C++ compiler is supposed to only recognise "std::string" but not "string", but just "string" isn't used for anything at all, why can't they just decide to make it the standard to type "string" if you want a string, like in even more modern programming languages (python, ...)And, where's the logic reasoning?  a cosine is standard too, yet here you can just say "cos" and not "std::cos".  And "int" is the standard for integer but you don't have to type "std::int"?[edited by - Boops on February 19, 2004 8:25:00 PM]
  std:: is a namespace.  Namespaces are useful because they prevent name collisions, two variables with the same name in the same scope.  Just type:using std::cout;orusing namespace std;and then you don''t have to put std:: in front of the namespace members.  Read more about namespaces and you will understand why they are important. ;quote:Original post by Boops  Does "Std::" mean "standard"?Yup. Well, lowercase it does.quote:If so, if it''s the standard, why don''t they just let you type it without the "std::" in front of it?For two reasons:1 (the little reason): to clearly identify standard library classes and functions from user-defined library classes and functions.2 (the big reason): To prevent the standard library classes from getting in your way.Let''s say that you don''t like the standard library''s string class. (Many people don''t; most of them have stupid reasons for it, but the bloating of the interface is a legitimate concern.) So instead of using the std::string class, you want to write your own. You COULD intentionally call it "my_string" or "alt_string" or something, to avoid a collision. But this is dumb, because it implies that the class represents something different than what it actually does: a plain old run-of-the-mill string. Or you could just not include the <string> header, but that''s tricky, because some other header might include it for you. So that''s unsafe. (Incidentally, this is why the practice of putting using namespace std; into a header file is a bad idea and rarely done.)Instead, by placing the std stuff into its own namespace, the language guarantees that you don''t have to worry about any standard classes that you don''t want to worry about. And even if some other component elsewhere in your application decides it will use std::strings internally, your portion won''t be affected by this.quote:If a modern C++ compiler is supposed to only recognise "std::string" but not "string", but just "string" isn''t used for anything at all, why can''t they just decide to make it the standard to type "string" if you want a string, like in even more modern programming languages (python, ...)By putting using std::string; in your code, you can. In this way, the individual programmer can decide whether he wants string in his global namespace.quote:And, where''s the logic reasoning?  a cosine is standard too, yet here you can just say "cos" and not "std::cos".That''s a bug in Visual Studio, not a feature of the language. If you include <cmath> like you''re supposed to, it''ll go in std.quote:And "int" is the standard for integer but you don''t have to type "std::int"?int is necessarily a built-in type, not a part of the standard library. There''s no getting around using it.   "Sneftel is correct, if rather vulgar." --Flarelocke ;quote:Original post by Anonymous Poster    std:: is a namespace.  Namespaces are useful because they prevent name collisions, two variables with the same name in the same scope.  Just type:using std::cout;orusing namespace std;and then you don't have to put std:: in front of the namespace members.  Read more about namespaces and you will understand why they are important.   Yes, yes, I know, my point is, who's gonna use "cout", "string", ... for anything else than their standard meanings?  Those things are so well known that name collisions would be pretty rare, as rare as a name collision with "int".Or from another point of view, why didn't they also put "int", "class", etc... in that namespace to prevent name collisions with those?What made them decide which things required "std" and which ones not?Is it possible that this phenomenom proves that C++ is getting old?  I mean, they could as well have chosen to make an update to C++ where "string" would be turned into a built-in type with much more possibilities and easier use, so that there wouldn't even be a need for custom string classes anymore, but I guess historical reasons prevented this. [edited by - Boops on February 19, 2004 8:36:50 PM];quote:Original post by Boops   Yes, yes, I know, my point is, who's gonna use "cout", "string", ... for anything else than their standard meanings?  Those things are so well known that name collisions would be pretty rare, as rare as a name collision with "int".If MFC didn't put a C in front of all their classes and capitalize the following letter, there would be a major collision right there. So there's one good example. Other examples of identifiers that commonly collide: "vector", "map", "iota".quote:What made them decide which things required "std" and which ones not?Built-in keywords are the only things not in std, because they're keywords, and that would obviously cause problems (imagine if the scope resolution operator was in std).quote:Is it possible that this phenomenom proves that C++ is getting old? You seem to be really intent on advancing this opinion, which makes me think that you might not actually be as interested in having your questions answered as answering them yourself. But I'll give you the benefit of the doubt.   "Sneftel is correct, if rather vulgar." --Flarelocke   [edited by - sneftel on February 19, 2004 9:08:58 PM];  The reason string isn't a built in type is because it is not a native type. The processors do have instructions to do some very limited operations on strings, but many of the common operations are not part of the instruction set and must thus be programmed. As stated previously, people can and do choose to make their own string class and call it string, and being able to do so is a good thing IMO. The more choices a programmer has, the more efficiently he/she can solve whatever problems need to be solved (which is why I like Lisp).   [edited by - extrarius on February 19, 2004 8:43:11 PM];  pretty much the same reason why you need to #include <stdio.h> to print a string. ;quote:Original post by alnite  pretty much the same reason why you need to #include <stdio.h> to print a string.   by now you should do #include <cstdio>    ;  0wned ;quote:Original post by DerAnged  by now you should do #include <cstdio>I know that, but the reason stays the same. 