using namespace std; <-- is evil?
-
I've heard many people say that using "using namespace std" in your programs is a bad idea. I see it in all the books I read through though .. I assume it's just because they're examples though. I'm going to assume the reasoning is that you don't want to include anything your not going to be using .. and possible conflictions with other functions??? I've started to change all my code from: using namespace std; to: using std::vector; using std::deque; using std::cout; ... I am finding that the list of using ... get's quite long, hehe. But is this the right way to go? Or is it simply better to just use "using namespace std" Travis D. Mathison --- --- After three days without programming, life becomes meaningless ...
-
I've heard many people say that using "using namespace std" in your programs is a bad idea. I see it in all the books I read through though .. I assume it's just because they're examples though. I'm going to assume the reasoning is that you don't want to include anything your not going to be using .. and possible conflictions with other functions??? I've started to change all my code from: using namespace std; to: using std::vector; using std::deque; using std::cout; ... I am finding that the list of using ... get's quite long, hehe. But is this the right way to go? Or is it simply better to just use "using namespace std" Travis D. Mathison --- --- After three days without programming, life becomes meaningless ...
I don't use using at all. That way you know where each and every function comes from. Otherwise they're just global functions. Consider when you use a C++ object it's usually object.method() or object->method() and not "declare some global and then call method()".**
Todd Smith
CPUA 0x007 ... shaken not stirred
**
-
I've heard many people say that using "using namespace std" in your programs is a bad idea. I see it in all the books I read through though .. I assume it's just because they're examples though. I'm going to assume the reasoning is that you don't want to include anything your not going to be using .. and possible conflictions with other functions??? I've started to change all my code from: using namespace std; to: using std::vector; using std::deque; using std::cout; ... I am finding that the list of using ... get's quite long, hehe. But is this the right way to go? Or is it simply better to just use "using namespace std" Travis D. Mathison --- --- After three days without programming, life becomes meaningless ...
If you want to use them, go right ahead. However, there are some cases where I wouldn't use them at ALL. Never ever ever ever ever. (Atleast in the global scope) If you are creating a library to be used by others, NEVER expect that there has been a using issued. Never issue one yourself (excluding the rare case where you are adding namespaces to an existing library where you don't want to break existing code). Always reference the classes fully (i.e. std::vector). The idea is that your library should never have any side effects during compilation. Issuing a using might cause other strange problems not expected by the user of your class library. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
I've heard many people say that using "using namespace std" in your programs is a bad idea. I see it in all the books I read through though .. I assume it's just because they're examples though. I'm going to assume the reasoning is that you don't want to include anything your not going to be using .. and possible conflictions with other functions??? I've started to change all my code from: using namespace std; to: using std::vector; using std::deque; using std::cout; ... I am finding that the list of using ... get's quite long, hehe. But is this the right way to go? Or is it simply better to just use "using namespace std" Travis D. Mathison --- --- After three days without programming, life becomes meaningless ...
Ok, thank you both for the insight.. perhaps I shall consider using the full std:: in my code instead of "using blah". ;) ;) ;) Travis D. Mathison --- --- After three days without programming, life becomes meaningless ...
-
I've heard many people say that using "using namespace std" in your programs is a bad idea. I see it in all the books I read through though .. I assume it's just because they're examples though. I'm going to assume the reasoning is that you don't want to include anything your not going to be using .. and possible conflictions with other functions??? I've started to change all my code from: using namespace std; to: using std::vector; using std::deque; using std::cout; ... I am finding that the list of using ... get's quite long, hehe. But is this the right way to go? Or is it simply better to just use "using namespace std" Travis D. Mathison --- --- After three days without programming, life becomes meaningless ...
-
That's why we use typedef's a lot (to save some keystrokes I guess?). For example:
typedef std::list<MyItem> CMyList;
Is this also an evil then?
This is also evil, because it makes your code illegible to people who don't have your typedefs commited to memory. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
-
This is also evil, because it makes your code illegible to people who don't have your typedefs commited to memory. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
That is why I name my typedefs consistently and 99% of the time inside a class. typedef std::vector _vSomeClass; Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
That is why I name my typedefs consistently and 99% of the time inside a class. typedef std::vector _vSomeClass; Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
This is fine as far as it goes, although IMO it adds a level of abstraction that is unnecessary (i.e. I still need to translate this on the fly as I read the document, although what you've shown is quite intuitive. My personal opinion is that it is better for people to become accustomed to reading the only syntax that is never ambiguous. Most typedefs I've seen have used the vec/lst/map type prefixes, but created types like this mpi2v mpsz2w veci1 veci2 This stuff is just a nightmare. I agree that poor use of a language feature does not dismiss the feature entirely, and in writing STL docs for work I put forward typedef as an issue for personal preference, but also explained why my preference is to avoid it. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
-
This is fine as far as it goes, although IMO it adds a level of abstraction that is unnecessary (i.e. I still need to translate this on the fly as I read the document, although what you've shown is quite intuitive. My personal opinion is that it is better for people to become accustomed to reading the only syntax that is never ambiguous. Most typedefs I've seen have used the vec/lst/map type prefixes, but created types like this mpi2v mpsz2w veci1 veci2 This stuff is just a nightmare. I agree that poor use of a language feature does not dismiss the feature entirely, and in writing STL docs for work I put forward typedef as an issue for personal preference, but also explained why my preference is to avoid it. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
This is fine as far as it goes, although IMO it adds a level of abstraction that is unnecessary (i.e. I still need to translate this on the fly as I read the document, although what you've shown is quite intuitive. Which is the exact reasons I don't some of the more basic STL functions such as for_each. Let's just say I disagree with Scott Meyers on every point. Even he admits functions such as for_each can obscure code. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
This is fine as far as it goes, although IMO it adds a level of abstraction that is unnecessary (i.e. I still need to translate this on the fly as I read the document, although what you've shown is quite intuitive. Which is the exact reasons I don't some of the more basic STL functions such as for_each. Let's just say I disagree with Scott Meyers on every point. Even he admits functions such as for_each can obscure code. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
Tim Smith wrote: Let's just say I disagree with Scott Meyers on every point. On *every* point ? I believe he advocates the typedef's we are discussing, actually. Tim Smith wrote: Which is the exact reasons I don't some of the more basic STL functions such as for_each. I don't think for_each obscures code to the degree that typedefs do, and in both cases it obscures it for people other than the author. Personally I don't use for_each that much either, I think the main reason I've used it is to delete pointers in my destructor. It is also true that my use of STL has not needed too many algorithms. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
-
This is fine as far as it goes, although IMO it adds a level of abstraction that is unnecessary (i.e. I still need to translate this on the fly as I read the document, although what you've shown is quite intuitive. Which is the exact reasons I don't some of the more basic STL functions such as for_each. Let's just say I disagree with Scott Meyers on every point. Even he admits functions such as for_each can obscure code. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?