Back to General and Gameplay Programming

[Debate] Using namespace should be avoided ?

General and Gameplay Programming Programming

Started by Alundra February 03, 2016 02:54 PM

15 comments, last by Bearhugger 8 years, 2 months ago

17,596

February 04, 2016 02:16 AM

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() {};

Sean Middleditch – Game Systems Engineer – Join my team!

Khatharr

8,814

February 04, 2016 03:29 AM

Never in headers.

Prefer scoping it.

Pefer:

using std::string;

over

using namespace std;

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

Servant of the Lord

33,739

February 04, 2016 04:02 AM

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.

BitMaster

8,652

February 04, 2016 07:30 AM

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.

Ryan_001

3,477

February 04, 2016 02:55 PM

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.

coope

372

February 05, 2016 05:28 PM

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?

Bearhugger

1,276

February 13, 2016 04:55 AM

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.

[Debate] Using namespace should be avoided ?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

[Debate] Using namespace should be avoided ?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines