Sign in to follow this  

[Debate] Using namespace should be avoided ?

This topic is 670 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I think it depends on the situation.

 

You should never use it inside a .h file in my opinion.

Code readability goes down a bit by not using it, but it is more clear what classes belong to what namespaces, so maybe that compensates for it again.

 

If your own engine uses only one core lib for example it is perfectly fine to do "using namespace CoreLib" inside your .cpp files in my eyes.

If however you later plan to add support for another library that happens to have the same class name, you have to explicitly name that one.

 

I personally prefer not to use "using namespace", as then you are always safe (unless there is a lib with the same namespace name lol).

 

I think generally it should be avoided, but in some cases it is fine I think.

Edited by Buckshag

Share this post


Link to post
Share on other sites

using namespace has little to no way of being disabled once it is declared. Which is why at header level can be a PITA.

At .cpp file level it sounds more sane. But if you try "Unity builds" to speed up compilation, using namespace at .cpp file level comes back to bite you. Which makes "using namespace" more friendly at an enclosed scope, e.g.:

void myFunc( int a )
{
     using namespace std; //Only available at myFunc level.
}

 

Typing std is not a big deal, so I try to avoid it as much as possible. Furthermore it "using" pollutes autocomplete.

 

There are legitimate cases where it's appropriate, but use with discretion, with care.

Share this post


Link to post
Share on other sites

Assuming that nobody uses "usign namespace" in headers,I don't like(and use) it because :

- Eventual collision. This usually doesn't happen.

- Searchinng won't work that well with something form the namespace.
- the header declaration does not match the cpp definition of a function that uses type form the namespace example:
Header:

class foo{
void boo(std::string& s);
}

Cpp:

using namespace std;
void foo::boo(string& s) { .. }

This this basically breaks the "code searching". Additionally it make it a little bit harder to change/move the code. 

This issue will be resolved when we have modules in C++. Until then we shouldn't pretend that this is Java/C#(namespaces work like a charm there).

 

- other things that I cannot remember.
 

Furthermore it "using" pollutes autocomplete.

 

Edited by imoogiBG

Share this post


Link to post
Share on other sites


using namespace has little to no way of being disabled once it is declared. Which is why at header level can be a PITA.

That's my problem with it as well.

 

Do not ever use it in a header file. That would get you called out quick at a code review around here. 

 

Also, using a full namespace is bad because it pulls in everything. If you want to pull in a few specific functions or values that is fine, but the whole namespace is generally overkill.

 

In your own CPP file you might be able to get away with it, but generally not recommended around here. Specifying which library or subsystem you are pulling your types from is generally better for those who come after than the few keystrokes saved by a using statement. The vast majority of the code base specify their namespaces.  Sometimes that isn't the case, but generally we discourage it.

Share this post


Link to post
Share on other sites


If you want to pull in a few specific functions or values that is fine, but the whole namespace is generally overkill.

 

This.

 

I've found in my own code I tend to do this, but even then I try to keep it at function scope.

Share this post


Link to post
Share on other sites

It's not always bad...

 

I use it in my codebase, even in headers, but ONLY within the scope of another namespace, never in the global namespace, and only when it is clear that the imported namespace is a strong dependency of the enclosing namespace. In my case, all of the code is part of the same suite of libraries which are meant to interact and depend on the same base code, so I allow it to avoid literally thousands of verbose explicit namespace qualifiers in header files. The tradeoff is worth it in this case, I think.

 

e.g.

EngineConfig.h:

#include "Graphics.h"
#include "Physics.h"
#include "Sound.h"
namespace engine {
using namespace graphics;
using namespace physics;
using namespace sound;
};

In most cases I prefer importing just the needed classes, but once the import list grows beyond 5-10 classes from the same namespace, I tend to import the entire namespace instead if it makes sense.

Edited by Aressera

Share this post


Link to post
Share on other sites
I tend to use it in some very specific circumstances in file scope in cpps, mostly for small self-contained libraries (where I feel comfortable being lazy) and private implementation namespaces, e.g.
 
// header
namespace _impl {
  struct internal {};
}
_impl::internal thing();

// source
#include "header"
using namespace _impl;
internal thing() { ... };
The only real risk you run into is if you're doing the blob build stuff or you end up including new headers you didn't expect, but if it's small self-contained code... who cares. If you run into a problem, fix it then. There are more important things to worry about.


A lot of people forget that you can use a namespace alias, which is handy if your only concern is the length of the namespace.
 
namespace x = some::really::verbose::name;

// now equivalent
some::really::verbose::name foo();
x::type foo() {};
Edited by SeanMiddleditch

Share this post


Link to post
Share on other sites

For small namespaces, I don't use them at all.

 

"std::vector" is preferable for me than "vector", because I also have other kinds of vectors (for example).

 

For larger namespaces, like my own project's Engine::Graphics::QuadBatch, I occasionally use "using namespace Engine::Graphics;" at file level, but usually only within that same subsystem (i.e. only within the Engine::Graphics subsystem), but I do use them at function level if that function is getting overly verbose. It's not a habit, but an exception, because I'd prefer the namespace stays visible so I know at a glance what subsystem it's from.

 

Like others, I think "using namespace" is terrible in headers. However, there are exceptions to most rules, and I think an exception for this rule, depending on the project, might be std::placeholders. I wouldn't be opposed to "using namespace std::placeholders;" within a major header, but I'm glad that it's within a namespace by default.

Share this post


Link to post
Share on other sites

Like others, I think "using namespace" is terrible in headers. However, there are exceptions to most rules, and I think an exception for this rule, depending on the project, might be std::placeholders. I wouldn't be opposed to "using namespace std::placeholders;" within a major header, but I'm glad that it's within a namespace by default.


Actually, placeholders are a bad example for that. First, you should not really need them nowadays since lambdas can do what they do while avoiding some pitfalls of std::bind (there was a thread recently with some surprising gotchas regarding std::bind). Even if you needed them you would most likely only need them at function scope as well.

A better example would be the string literals under std::literals though.

Still, namespaces like this are explicitly designed to be used somewhere (even global-ish) since they contain an extremely limited number of symbols. Unlike the whole std, which contains everything including several templated kitchen sinks.

Share this post


Link to post
Share on other sites

Like others, I think "using namespace" is terrible in headers. However, there are exceptions to most rules, and I think an exception for this rule, depending on the project, might be std::placeholders. I wouldn't be opposed to "using namespace std::placeholders;" within a major header, but I'm glad that it's within a namespace by default.


Actually, placeholders are a bad example for that. First, you should not really need them nowadays since lambdas can do what they do while avoiding some pitfalls of std::bind (there was a thread recently with some surprising gotchas regarding std::bind). Even if you needed them you would most likely only need them at function scope as well.

A better example would be the string literals under std::literals though.

Still, namespaces like this are explicitly designed to be used somewhere (even global-ish) since they contain an extremely limited number of symbols. Unlike the whole std, which contains everything including several templated kitchen sinks.

I have the feeling that was more an example than an endorsement of std::placeholders.

Share this post


Link to post
Share on other sites

I am of the opinion that one should avoid~ `using namespace std;` and the using namespaces should used in simple situations.

Simple in the sense that there are few inclusions, and no file dependencies tied to where it is used. So in my experience that means when I define something like `namespace GameAssets{...}` I only include it if I don't define custom assets to use instead of those available within the namespace. Or an even simpler example, I declare `namespace logger{...}` Then in the .cpp for that header I include the namespace. If I go to use the logger I use its namespace only where its components are used, so somewhere like `myalgorithm.cpp`.

 

 


First, you should not really need them nowadays since lambdas can do what they do while avoiding some pitfalls of std::bind (there was a thread recently with some surprising gotchas regarding std::bind).

 

Can anybody link this thread?

Share this post


Link to post
Share on other sites

In source files I think it is OK, but some people frown it because of a couple of corner cases where the ambiguous symbol is both legal AND compiles. It may have some merit, I don't know what kind of code other people are working with, but personally I don't care about those potential issues. I don't remember the last time I had an ambiguous symbol actually compile due to a `using namespace` clause with any code I've worked on, and I'd rather save myself the redundant prefixing and deal with whatever happens if it goes wrong. (If ever.) I dunno, it may be because I PascalCase both my method names and class names, so that doesn't leave a lot of symbols to clash with the standard library, which has most of the names my symbols would clash. (ie: vector<> vs Vector<>.)

 

Either way, it's not something I feel strongly about. I won't really care if the organization I work for bans the `using namespace` clause tomorrow.

 

In header files though, it is poison. Don't ever put a using namespace clause in a header. Gets me on my bad side.

Edited by Bearhugger

Share this post


Link to post
Share on other sites

This topic is 670 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this