NameSpace notarisk

I worry some people are getting a little too hung up on using namespaces as being dangerous to the point where they will avoid using them. Yes, there is a chance that the will be a name collision, but this is something that will be picked up at compile time so you can fix it before your program even runs. And all that entails is being more explicit with your function call. So instead of DoThis(), its Namespace1::DoThis(). Also, this doesn’t prevent you from using the rest of the namespace, so you don’t have to delete your using statements in your code the second you have a collision.

Namespaces also help so that you can have a program with multiple methods that all have the same name, as long as they’re in different namespaces. This is very useful so you don’t have to worry that somewhere deep in the program there is a similar method name, and have to come up with a ridiculously long or obscure name. So when naming a method, you only need to worry about the current namespace.

Using namespaces makes it easier to write your code and more importantly, easier to read. Use them. :slight_smile:

Here’s some sample code to play with:

#include <iostream>

namespace ns1
{
	void doThing()
	{
		std::cout << std::endl << "doing the thing from ns1";
	}

	void onlyNS1DoesThis()
	{
		std::cout << std::endl << "Only I, ns1, can accomplish this task";
	}
}

namespace ns2
{
	void doThing()
	{
		std::cout << std::endl << "this other thing done be ns2 /gasp";
	}

	void onlyNS2DoesThat()
	{
		std::cout << std::endl << "efficient and expedient";
	}
}


using namespace std;
using namespace ns1;
using namespace ns2;


int main()
{
	cout << "hello world";

	//doThing(); // compile time error

	ns1::doThing();
	ns2::doThing();

	onlyNS2DoesThat();
	onlyNS1DoesThis();

	cout << "\n\n~fin...";
	cin.get();

	return 0;
}

I think you are confused, namespaces are great. However using namespace x; is not so good and is discouraged. @sampattuzzi or @ben should probably make a note of this in the lecture as you’re not the first to make this mistake.

I stand corrected. The problem with the using statements comes up when its not easily changed. This occurs when adding new libraries, or when adding to a code base that is used by many people. So, its better to be explicit from the start so you don’t have to go back and fix.

You would also like your code to be free from this type of error so others can easily use your libraries if you chose to share.

Sorry for adding to the confusion.

Hi DanM can you explain more please why the original poster is confused. I thought his sample code looked like a very good example of how namespaces work, but as this is new for me, maybe I am also confused? Now you might not wish to use namespaces because you have no idea which namespace the particular routine came from, but I think that is just a matter of preference as the routine can only have come from one of the namespaces you have declared

Hi Dave. The problem isn’t with namespaces. It’s good to organize your code into namespaces as often as you can. What is frowned upon is the ‘using’ keyword.

//good
namespace MyNamespace
{
   //your code goes here
}


//potentially problematic code
using namespace SomeNameSpace;

OK so seems to me there is no confusion, just that some people frown on using the ‘using’ keyword, and also there would be no real problem because the compiler will not allow two unqualified functions in different declared namespaces with the same name, or that’s my current understanding.

@wagz2000 using has multiple uses and not just populating a namespace into the global space. So to be precise using namespace x; is discouraged not the using keyword.

@DaveS The problem arises when you use using namespace and unintentially cause conflicts in your code. For example your using a library called Foo and have the code

#include "somefooheader.h"
using namespace Foo;
int square(int n) { return n * n; }
int main()
{
    square(5);
    return 0;
}

And you’re happy and everything compiles, then later you need to #include "someotherfooheader.h" which also defines int square(int n) but does something completely different then you will get a compilation error since the function call is ambiguous, did you mean your square or Foo::square?

Which lecture do you reckon should be edited by me or @ben?

I would assume the lecture that this thread is tagged under “Using #include and namespaces”

The patch is uploading now. Let me know if it’s clearer. It should be 30 seconds from teh end of the video.

2 Likes