Thread: A quick question

Originally Posted by medievalelks

... as they defeat the purpose of namespaces in the first place.

I don't think that's true.
A namespace was designed to be able to organize data and functions better, not hide them away from each other so you can use the same name for different functions.
In other words, it simply allows you to organize data. Say it's a string function, put it in namespace Strings.
Theoretically, you should be able to import them directly into the global namespace just because namespaces are only organizing names to group functions.
The problems shows up when you multiple functions with the same name, which is why it's to be avoided.

Myself I tend to use full names just to show that this is a string function, for example.
It also allows me to remove certain stuff from the function name, such as instead of SplitString, it can be named Split because it's in the Strings namespace.

At the risk of turning this into a "my expert is bigger than yours" contest, search groups.google.com and you'll see comments by Andrew Koenig and Bjarne Stroustrup that argue against such liberal use of using directives, as they defeat the purpose of namespaces in the first place.

"Infinite are the arguments of mages."
- Vetch, from A Wizard of Earthsea, by Ursula le Guin

Anyway, opinions certainly differ on the matter.

That is precisely what I was saying in the first place.

I happen to take the same stance as you do (Sutter and Alexandrescu's stance + only use within a local scope), but it is fun to play Devil's Advocate, when one of the "devils" is chair of the C++ Standards committee

EDIT:

A namespace was designed to be able to organize data and functions better.

I think all four experts quoted on this page disagree and believe that namespaces are designed merely to manage names, not organise data and functions (which would be the purposes of classes, methinks).

Originally Posted by laserlight

I think all four experts quoted on this page disagree and believe that namespaces are designed merely to manage names, not organise data and functions (which would be the purposes of classes, methinks).

It's how I see it anyway. I always try to organize my code library into namespaces to make it look more ala .NET.
Functions are properly grouped into proper namespaces, making it easier to distinguish the purpose of functions and avoid making too long or repeatable names.

Originally Posted by medievalelks

Right, and by putting "using namespace x;" at the top of all your source files, you've essentially put x's names right back into the global namespace. Putting them at function scope, however, introduces less risk. using declarations (like "using std::string") is even less risky.

That wasn't my point. They are categorized, but that shouldn't mean you have to explicitly mention the category names when using the functions. You can simple tell the compiler "Hey, I want to use this category, can you fix it for me, please?" and then just use the functions.
The only drawback is that it introduces name conflicts, which is why it should be avoided.
But I don't see any wrong with the using directive in itself.

Right, and by putting "using namespace x;" at the top of all your source files, you've essentially put x's names right back into the global namespace.

Almost, since one can still fully qualify names.

Putting them at function scope, however, introduces less risk.

I do not think it introduces less risk (you still do not have control over what names might be introduced), but rather it makes it easier to diagnose a name collision.

using declarations (like "using std::string") is even less risky.

To avoid Sutter and Alexandrescu's counterexample, I think this must only be done within a local, not namespace, scope; but having a bunch of using declarations at the start of a function body can be as tiresome as fully qualifying the names, so I tend to use them only when the name is used many times, or simply use a local using directive.