Why do people hate "using namespace std;" even though it makes your code cleaner? You can even still specify "std: :" when using something from the standard library, so what's the issue?
The whole idea behind namespaces is to avoid name collisions, and keep related names separate.
As soon as you start pulling in an entire namespace with a using directive, you are defeating the purpose of namespaces. Doing so puts absolutely everything defined in that namespace into the global namespace.
While this is not a big deal in the trivial examples you find in books, courses, and online, in real-world code it can and does lead to serious name conflict problems. This is why it's important to understand what the implications are and to avoid getting into the habit of pulling an entire namespace into the global namespace.
Consider a C++ project that makes use of two third-party commercial C++ libraries. Each library was created independently, and the source code is out of our control. Only the header files and binaries available. Each library defines everything in it's own uniquely-named namespace. This is as it should be. Now, there are some classes and other entities that have the same names in the two libraries. If they were all defined in the global namespace, and not in their own respective namespaces, we would have no way of overcoming the resulting name conflicts. But because the two libraries use separate namespaces, we can use both libraries without running into name conflicts.
But, if we were to pull both namespaces into the global namespace with a using directive, we would run into name conflicts. Doing so effectively "turns off" the namespace feature and its benefits for all namespaces pulled into the global namespace.
Of course, doing so also means that your own source code can't use any of the names already defined in these namespaces, which means it's easy to define something that conflicts with something in those namespaces. But you have control of your own source code, and could choose different names to avoid the conflict. However, choosing different names to avoid conflicts can lead to names that are inconsistent and not the best names for entities in your own code…which can reduce the readability, maintainability, and usability of your code.
If you're not careful, and depending on the settings of your tools, you can even end up trying to do one thing, and actually doing another. This can lead to confusing compile-time errors and unexpected runtime behaviors. Both make the development process less productive and the resulting software potentially less reliable.
Finally, cluttering up the global namespace with hundreds or thousands of names can lead to compilation inefficiency. This might not be an issue for small, trivial projects, it but it can be very significant in large, real-world projects.
Bottom line: A using directive that pulls an entire namespace into the global namespace does not make your code "cleaner." In real-world projects, it can quickly lead to name conflicts, awkward naming of entities in your own code, less readable/maintainable/usable code, less productive development, less reliable behavior, and inefficient compilation.
The best approach is to pull in only those names you actually need, via a using directive, or to fully-qualify the names where they're used in the code.
Perhaps "hate" is not the right sentiment here. "Strongly discouraged" and typically "forbidden" in real-world production code are probably more in line with reality. Virtually every C++ coding standard used by my clients, employers, and colleagues, disallows the using directive for pulling in an entire namespace in production code.
The whole idea behind namespaces is to avoid name collisions, and keep related names separate.
As soon as you start pulling in an entire namespace with a using directive, you are defeating the purpose of namespaces. Doing so puts absolutely everything defined in that namespace into the global namespace.
While this is not a big deal in the trivial examples you find in books, courses, and online, in real-world code it can and does lead to serious name conflict problems. This is why it's important to understand what the implications are and to avoid getting into the habit of pulling an entire namespace into the global namespace.
Consider a C++ project that makes use of two third-party commercial C++ libraries. Each library was created independently, and the source code is out of our control. Only the header files and binaries available. Each library defines everything in it's own uniquely-named namespace. This is as it should be. Now, there are some classes and other entities that have the same names in the two libraries. If they were all defined in the global namespace, and not in their own respective namespaces, we would have no way of overcoming the resulting name conflicts. But because the two libraries use separate namespaces, we can use both libraries without running into name conflicts.
But, if we were to pull both namespaces into the global namespace with a using directive, we would run into name conflicts. Doing so effectively "turns off" the namespace feature and its benefits for all namespaces pulled into the global namespace.
Of course, doing so also means that your own source code can't use any of the names already defined in these namespaces, which means it's easy to define something that conflicts with something in those namespaces. But you have control of your own source code, and could choose different names to avoid the conflict. However, choosing different names to avoid conflicts can lead to names that are inconsistent and not the best names for entities in your own code…which can reduce the readability, maintainability, and usability of your code.
If you're not careful, and depending on the settings of your tools, you can even end up trying to do one thing, and actually doing another. This can lead to confusing compile-time errors and unexpected runtime behaviors. Both make the development process less productive and the resulting software potentially less reliable.
Finally, cluttering up the global namespace with hundreds or thousands of names can lead to compilation inefficiency. This might not be an issue for small, trivial projects, it but it can be very significant in large, real-world projects.
Bottom line: A using directive that pulls an entire namespace into the global namespace does not make your code "cleaner." In real-world projects, it can quickly lead to name conflicts, awkward naming of entities in your own code, less readable/maintainable/usable code, less productive development, less reliable behavior, and inefficient compilation.
The best approach is to pull in only those names you actually need, via a using directive, or to fully-qualify the names where they're used in the code.
Perhaps "hate" is not the right sentiment here. "Strongly discouraged" and typically "forbidden" in real-world production code are probably more in line with reality. Virtually every C++ coding standard used by my clients, employers, and colleagues, disallows the using directive for pulling in an entire namespace in production code.
No comments:
Post a Comment