Just wondering what general thoughts there are regarding the pros and cons
of using namespace NameSpace; vs NameSpace::Method

Such as, are there any performance gains with one or the other etc...?

The using directive pulls in every visible name from the namespace while the namespace qualified name is visible only for that single use of only that name. Obviously if your goal is to avoid naming collisions in multiple namespaces, a using directive is the worst possible choice and a qualified name is the best possible choice.

However, that doesn't mean qualified names are always better. It's fairly obviously that qualified names are more verbose. You can also limit the scope of the using directive. The following is much less likely to clash names than a using directive at file scope:

void foo()
{
    using namespace NameSpace;

    ...
}

Finally, there's a third choice in the using declaration:

using NameSpace::Method;

This is something of a combination of a using directive and a qualified name in that you're only pulling in that single name, but you're doing so for all uses of the name after the declaration rather than just a single use.

Such as, are there any performance gains with one or the other etc...?

Don't concern yourself over performance here. If there's a difference, it'll be negligible and limited to compile time.

Thanks for input, my main concern was that of runtime performance.

Unless you have very good reason, I'd say disregard performance in general and code for clarity. Don't go out of your way to use inefficient constructs, of course, but also don't go out of your way to optimize your code without plenty of runtime evidence that it's too slow and a cost to benefit justification for making it faster.

Too many people worry about performance when it makes no sense to do so. A few examples I see among the inexperienced are:

  • Worrying about the performance of individual expressions. Chances are very good that you're not working in an environment where replacing multiplication with shifting, or modulo with bitwise AND, will make one whit of difference.

  • Optimizing CPU bound operations when the program is IO bound. It doesn't matter how fast your search algorithm is if the program spends 99% of its time waiting for user input or displaying output. Optimize the perceived performance to the user in interactive programs, because that's where it matters.

  • Worrying about imaginary performance problems. This thread is one such example. For some reason you interpreted name qualification as a threat to runtime performance, which is completely nonsensical to those who understand how it works under the hood.

Well I never interpreted anything really, I just wanted to find out because I had
no idea.

Main part of my project is to capture and parse all incoming and outgoing network
traffic on the fly. Do you think that merits a performance concern?

Main part of my project is to capture and parse all incoming and outgoing network
traffic on the fly. Do you think that merits a performance concern?

Not until you have tested your program and realize that your code is not able to keep up with the data rates. Only then, can you start investigating what performance problems might be the cause of it. That's what deceptikon means by not optimizing prematurely.

Main part of my project is to capture and parse all incoming and outgoing network traffic on the fly. Do you think that merits a performance concern?

It certainly does. Bursts in network traffic are difficult to predict and difficult to simulate with any kind of accuracy.

Nevertheless, performance is a design constraint, never a design goal.

And it has to be addressed by using high level architectural and algorithmic decisions - for example, in this case, by using techniques like adaptive buffering.

Returning to the original topic:

Just wondering what general thoughts there are regarding the pros and cons of using namespace NameSpace;

You might find this dicussion on using namespace std ; interesting:
http://www.cplusplus.com/forum/general/72248/

This article has been dead for over six months. Start a new discussion instead.