¿Por qué “usar el espacio de nombres estándar” se considera una mala práctica?

Otros me han dicho que escribir en el código using namespace std es incorrecto, y que debería usar std::cout y std::cin directamente en su lugar.

¿Por qué el using namespace std considera una mala práctica? ¿Es ineficiente o corre el riesgo de declarar variables ambiguas (variables que comparten el mismo nombre como una función en el std nombres std )? ¿Afecta el rendimiento?

    Esto no está relacionado con el rendimiento en absoluto. Pero considere esto: está utilizando dos bibliotecas llamadas Foo y Bar:

     using namespace foo; using namespace bar; 

    Todo funciona bien, puedes llamar a Blah() desde Foo y Quux() desde Bar sin problemas. Pero un día se actualiza a una nueva versión de Foo 2.0, que ahora ofrece una función llamada Quux() . Ahora tiene un conflicto: tanto Foo 2.0 como Bar importan Quux() en su espacio de nombres global. Esto requerirá un esfuerzo para solucionarlo, especialmente si los parámetros de la función coinciden.

    Si hubiera usado foo::Blah() y bar::Quux() , entonces la introducción de foo::Quux() habría sido un no evento.

    Estoy de acuerdo con todo lo que escribió Greg , pero me gustaría añadir: ¡puede incluso empeorar más de lo que dijo Greg!

    Library Foo 2.0 podría introducir una función, Quux() , que es una coincidencia inequívocamente mejor para algunas de sus llamadas a Quux() que la bar::Quux() su código llamó durante años. Entonces su código aún se comstack , pero llama silenciosamente la función incorrecta y sabe Dios qué. Eso es casi tan malo como pueden ser las cosas.

    Tenga en cuenta que el std nombres std tiene toneladas de identificadores, muchos de los cuales son muy comunes ( list pensamientos, sort , string , iterator , etc.) que es muy probable que también aparezcan en otros códigos.

    Si considera que esto es poco probable: Hubo una pregunta aquí en Stack Overflow donde exactamente sucedió esto (función incorrecta llamada debido a std:: prefijo omitido) antes de medio año después de dar esta respuesta. Aquí hay otro ejemplo más reciente de tal pregunta. Entonces este es un problema real.


    Aquí hay un punto de datos más: hace muchos, muchos años, también solía encontrar molesto tener que prefijar todo de la biblioteca estándar con std:: . Luego trabajé en un proyecto en el que se decidió desde el principio que tanto el using directivas como las declaraciones están prohibidas a excepción de los ámbitos funcionales. ¿Adivina qué? Nos tomó a la mayoría de nosotros pocas semanas acostumbrarnos a escribir el prefijo, y después de unas semanas más, la mayoría de nosotros incluso estuvo de acuerdo en que realmente hacía el código más legible . Hay una razón para eso: si le gusta la prosa más corta o más larga es subjetiva, pero los prefijos añaden claridad al código de forma objetiva. No solo el comstackdor, sino también usted, le resulta más fácil ver a qué identificador se hace referencia.

    En una década, ese proyecto creció hasta tener varios millones de líneas de código. Dado que estas discusiones surgen una y otra vez, una vez me di cuenta de la frecuencia using que se usaba el using scope de la función (permitido) en el proyecto. Aprecié las fonts y solo encontré una o dos docenas de lugares donde se usó. Para mí, esto indica que, una vez probados, los desarrolladores no encuentran std:: suficientemente doloroso para emplear el uso de directivas incluso una vez cada 100 kLoC, incluso donde se permitió su uso.


    En pocas palabras: prefijar explícitamente todo no causa ningún daño, toma muy poco tiempo para acostumbrarse y tiene ventajas objetivas. En particular, hace que el código sea más fácil de interpretar por el comstackdor y por los lectores humanos, y ese debería ser probablemente el objective principal al escribir el código.

    Creo que es malo ponerlo en los archivos de encabezado de tus clases: porque estarías obligando a cualquiera que quiera usar tus clases (al incluir tus archivos de encabezado) a que también ‘usen’ (es decir, vean todo) esos otros espacios de nombres .

    Sin embargo, puede usar una statement de uso en sus archivos (privados) * .cpp.


    Tenga en cuenta que algunas personas no están de acuerdo con que diga “siéntase libre” de esta manera, porque aunque una sentencia using en un archivo cpp es mejor que en un encabezado (porque no afecta a las personas que incluyen su archivo de encabezado), piensan que todavía está no es bueno (porque dependiendo del código podría hacer que la implementación de la clase sea más difícil de mantener). Este tema de Preguntas frecuentes dice:

    La directiva using existe para el código heredado de C ++ y para facilitar la transición a los espacios de nombres, pero es probable que no deba usarla de manera regular, al menos no en su nuevo código de C ++.

    Sugiere dos alternativas:

    • Una statement de uso:

       using std::cout; // a using-declaration lets you use cout without qualification cout < < "Values:"; 
    • Superarlo y simplemente escribir std ::

       std::cout < < "Values:"; 

    Recientemente me encontré con una queja sobre Visual Studio 2010 . Resultó que casi todos los archivos fuente tenían estas dos líneas:

     using namespace std; using namespace boost; 

    Muchas de las características de Boost van al estándar C ++ 0x, y Visual Studio 2010 tiene muchas características C ++ 0x, por lo que de repente estos progtwigs no se estaban comstackndo.

    Por lo tanto, evite using namespace X; es una forma de protección contra el futuro, una forma de asegurarse de que un cambio en las bibliotecas y / o archivos de encabezado en uso no rompa un progtwig.

    Versión corta: no use declaraciones o directivas globales en archivos de encabezado. Siéntase libre de usarlos en archivos de implementación. Esto es lo que Herb Sutter y Andrei Alexandrescu tienen que decir sobre este tema en los Estándares de Codificación de C ++ (negándose a dar énfasis es mío):

    Resumen

    Los usos del espacio de nombres son para su conveniencia, no para que inflija a otros: nunca escriba una statement de uso o una directiva de uso antes de una directiva #include.

    Corolario: en archivos de encabezado, no escriba el nivel de espacio de nombres usando directivas o usando declaraciones; en su lugar, califica explícitamente el nombre del espacio de nombres de todos los nombres. (La segunda regla se sigue de la primera, porque los encabezados nunca pueden saber qué otro header #includes podría aparecer después de ellos).

    Discusión

    En resumen: puede y debe usar el espacio de nombres usando declaraciones y directivas generosamente en sus archivos de implementación después de las directivas #include y sentirse bien al respecto. A pesar de las afirmaciones repetidas de lo contrario, el espacio de nombres que usa declaraciones y directivas no son malas y no anulan el propósito de los espacios de nombres. Más bien, son lo que hace que los espacios de nombres sean utilizables .

    No se debe usar el uso de directivas en el scope global, especialmente en los encabezados. Sin embargo, hay situaciones en las que es apropiado incluso en un archivo de encabezado:

     template  inline FloatType compute_something(FloatType x) { using namespace std; //no problem since scope is limited return exp(x) * (sin(x) - cos(x * 2) + sin(x * 3) - cos(x * 4)); } 

    Esto es mejor que la calificación explícita ( std::sin , std::cos …) porque es más corta y tiene la capacidad de trabajar con tipos de coma flotante definidos por el usuario (a través de Argument Dependent Lookup).

    No lo uses globalmente

    Se considera “malo” solo cuando se usa globalmente . Porque:

    • Abarrotas el espacio de nombres en el que estás progtwigndo.
    • Los lectores tendrán dificultades para ver de dónde viene un identificador en particular, cuando usas muchos using namespace xyz .
    • Lo que sea cierto para otros lectores de su código fuente es aún más cierto para el lector más frecuente: usted mismo. Vuelve dentro de uno o dos años y eche un vistazo …
    • Si solo habla sobre using namespace std es posible que no tenga en cuenta todas las cosas que capta, y cuando agrega otro #include o pasa a una nueva revisión de C ++, puede obtener conflictos de nombres de los que no tenía conocimiento.

    Puedes usarlo localmente

    Adelante y úsalo localmente (casi) libremente. Esto, por supuesto, evita la repetición de std:: – y la repetición también es mala.

    Un modismo para usarlo localmente

    En C ++ 03 había una frase idiomática (código repetitivo) para implementar una función de swap para sus clases. Se sugirió que realmente utilizas un local using namespace std , o al menos using std::swap :

     class Thing { int value_; Child child_; public: // ... friend void swap(Thing &a, Thing &b); }; void swap(Thing &a, Thing &b) { using namespace std; // make `std::swap` available // swap all members swap(a.value_, b.value_); // `std::stwap(int, int)` swap(a.child_, b.child_); // `swap(Child&,Child&)` or `std::swap(...)` } 

    Esto hace la siguiente magia:

    • El comstackdor elegirá std::swap para value_ , es decir, void std::swap(int, int) .
    • Si tiene implementado un void swap(Child&, Child&) sobrecarga void swap(Child&, Child&) , el comstackdor lo elegirá.
    • Si no tiene esa sobrecarga, el comstackdor usará void std::swap(Child&,Child&) y hará su mejor intercambio.

    Con C ++ 11 no hay razón para usar este patrón más. La implementación de std::swap se cambió para encontrar una posible sobrecarga y elegirla.

    Si importa los archivos de encabezado correctos, de repente tiene nombres como hex , left , plus o count en su scope global. Esto podría sorprender si no sabe que std:: contiene estos nombres. Si también intentas usar estos nombres localmente, puede provocar cierta confusión.

    Si todo lo estándar está en su propio espacio de nombres, no tiene que preocuparse por las colisiones de nombres con su código u otras bibliotecas.

    Los progtwigdores experimentados utilizan lo que resuelve sus problemas y evitan lo que crea nuevos problemas, y evitan las directivas de uso de nivel de archivo de encabezado por esta razón exacta.

    Los progtwigdores experimentados también intentan evitar la calificación completa de los nombres dentro de sus archivos fuente. Una razón menor para esto es que no es elegante escribir más código cuando menos código es suficiente a menos que haya buenas razones . Una razón importante para esto es desactivar la búsqueda dependiente de argumentos (ADL).

    ¿Cuáles son estas buenas razones ? A veces los progtwigdores explícitamente quieren desactivar ADL, otras veces quieren desambiguar.

    Entonces lo siguiente está bien:

    1. Directrices de uso de nivel de función y declaraciones de uso dentro de implementaciones de funciones
    2. Source-file-level using-declarations dentro de los archivos fuente
    3. (Algunas veces) source-file-level using-directives

    Estoy de acuerdo en que no se debe usar globalmente, pero no es tan malo usarlo localmente, como en un namespace . Aquí hay un ejemplo de “El lenguaje de progtwigción C ++” :

     namespace My_lib { using namespace His_lib; // everything from His_lib using namespace Her_lib; // everything from Her_lib using His_lib::String; // resolve potential clash in favor of His_lib using Her_lib::Vector; // resolve potential clash in favor of Her_lib } 

    En este ejemplo, resolvimos posibles conflictos de nombres y ambigüedades que surgen de su composición.

    Los nombres declarados explícitamente allí (incluidos los nombres declarados mediante declaraciones-uso como His_lib::String ) tienen prioridad sobre los nombres a los que se hace accesible en otro ámbito mediante una directiva- using namespace Her_lib ( using namespace Her_lib ).

    Otra razón es sorpresa.

    Si veo cout < < blah , en lugar de std::cout < < blah

    Creo que ¿qué es esto cout ? ¿Es la cout normal? ¿Es algo especial?

    También lo considero una mala práctica. ¿Por qué? Solo un día pensé que la función de un espacio de nombres es dividir las cosas, así que no debería estropearlo al tirar todo en una sola bolsa global. Sin embargo, si uso a menudo ‘cout’ y ‘cin’, escribo: using std::cout; using std::cin; using std::cout; using std::cin; en el archivo cpp (nunca en el archivo de encabezado, ya que se propaga con #include ). Creo que nadie en su sano nombre alguna vez nombrará a un cout o cin . 😉

    Es bueno ver el código y saber lo que hace. Si veo std::cout , sé que es la secuencia de cout de la biblioteca std . Si veo cout entonces no lo sé. Podría ser la secuencia de cout de la biblioteca std . O podría haber un int cout = 0; diez líneas más arriba en la misma función. O una variable static llamada cout en ese archivo. Podría ser cualquier cosa.

    Ahora tome una base de código de millones de líneas, que no es particularmente grande, y está buscando un error, lo que significa que sabe que hay una línea en este millón de líneas que no hace lo que se supone que debe hacer. cout < < 1; podría leer una static int llamada cout , desplazarla a la izquierda en un bit, y descartar el resultado. Buscando un error, tendría que verificarlo. ¿Puedes ver cómo realmente realmente prefiero ver std::cout ?

    Es una de estas cosas que parece una muy buena idea si usted es un maestro y nunca tuvo que escribir y mantener ningún código para ganarse la vida. Me encanta ver código donde (1) sé lo que hace; y, (2) estoy seguro de que la persona que lo escribió sabía lo que hace.

    Se trata de gestionar la complejidad. Usar el espacio de nombres hará que entren cosas que no quieres, y posiblemente dificulte la depuración (digo posiblemente). Usar std :: en todas partes es más difícil de leer (más texto y todo eso).

    Caballos para cursos: gestione su complejidad de la mejor manera que pueda y siéntase capaz.

    1. debe poder leer el código escrito por personas que tienen diferentes opiniones de estilo y mejores prácticas que usted.

    2. Si solo estás usando cout, nadie se confunde. Pero cuando tienes muchos espacios de nombres volando alrededor y ves esta clase y no estás exactamente seguro de lo que hace, tener el espacio de nombres explícito actúa como un tipo de comentario. Puede ver a primera vista, ‘oh, esto es una operación de sistema de archivos’ o ‘eso está haciendo cosas de red’.

    Usar muchos espacios de nombres al mismo tiempo es obviamente una receta para el desastre, pero usar el espacio de nombres JUST std y el espacio de nombres std no es tan grande en mi opinión, porque la redefinición solo puede ocurrir con tu propio código …

    Así que simplemente considérelos funciones como nombres reservados como “int” o “clase” y eso es todo.

    La gente debería dejar de ser tan anal sobre eso. Tu maestro tenía razón todo el tiempo. Solo usa UN espacio de nombre; ese es el objective de usar espacios de nombres en primer lugar. No debes usar más de uno al mismo tiempo. A menos que sea tuyo. Entonces, de nuevo, la redefinición no sucederá.

    Considerar

     // myHeader.h #include  using namespace std; // someoneElses.cpp/h #include "myHeader.h" class stringstream { // uh oh }; 

    Tenga en cuenta que este es un ejemplo simple, si tiene archivos con 20 inclusiones y otras importaciones, tendrá que lidiar con un montón de dependencias para resolver el problema. Lo peor es que puede obtener errores no relacionados en otros módulos según las definiciones que entren en conflicto.

    No es horrible, pero te ahorrarás dolores de cabeza al no usarlo en archivos de encabezado o en el espacio de nombres global. Probablemente sea correcto hacerlo en ámbitos muy limitados, pero nunca he tenido problemas escribiendo los 5 caracteres adicionales para aclarar de dónde vienen mis funciones.

    Un ejemplo concreto para aclarar la preocupación. Imagine que tiene una situación en la que tiene 2 bibliotecas, foo y barra, cada una con su propio espacio de nombres:

     namespace foo { void a(float) { /* does something */ } } namespace bar { ... } 

    Ahora digamos que usa foo y barra juntos en su propio progtwig de la siguiente manera:

     using namespace foo; using namespace bar; void main() { a(42); } 

    En este punto todo está bien. Cuando ejecuta su progtwig, ‘hace algo’. Pero más tarde actualiza la barra y digamos que ha cambiado para ser así:

     namespace bar { void a(float) { /* does something completely different */ } } 

    At this point you’ll get a compiler error:

     using namespace foo; using namespace bar; void main() { a(42); // error: call to 'a' is ambiguous, should be foo::a(42) } 

    So you’ll need to do some maintenance to clarify which ‘a’ you meant (ie foo::a ). That’s probably undesirable, but fortunately it is pretty easy (just add foo:: in front of all calls to a that the compiler marks as ambiguous).

    But imagine an alternative scenario where bar changed instead to look like this instead:

     namespace bar { void a(int) { /* does something completely different */ } } 

    At this point your call to a(42) suddenly binds to bar::a instead of foo::a and instead of doing ‘something’ it does ‘something completely different’. No compiler warning or anything. Your program just silently starts doing something complete different than before.

    When you use a namespace you’re risking a scenario like this, which is why people are uncomfortable using namespaces. The more things in a namespace the greater the risk of conflict, so people might be even more uncomfortable using namespace std (due to the number of things in that namespace) than other namespaces.

    Ultimately this is a trade-off between writability vs reliability/maintainability. Readability may factor in also, but I could see arguments for that going either way. Normally I would say reliability and maintainability are more important, but in this case you’ll constantly pay the writability cost for an fairly rare reliability/maintainability impact. The ‘best’ trade-off will determine on your project and your priorities.

    A namespace is a named scope. Namespaces are used to group related declarations and to keep separate items separate. For example, two separately developed libraries may use the same name to refer to different items, but a user can still use both:

     namespace Mylib{ template class Stack{ /* ... */ }; / / ... } namespace Yourlib{ class Stack{ /* ... */ }; / / ... } void f(int max) { Mylib: :Stack s1(max) ; / / use my stack Yourlib: :Stack s2(max) ; / / use your stack / / ... } 

    Repeating a namespace name can be a distraction for both readers and writers. Consequently, it is possible to state that names from a particular namespace are available without explicit qualification. Por ejemplo:

     void f(int max) { using namespace Mylib; / / make names from Mylib accessible Stack s1(max) ; / / use my stack Yourlib: :Stack s2(max) ; / / use your stack / / ... } 

    Namespaces provide a powerful tool for the management of different libraries and of different versions of code. In particular, they offer the programmer alternatives of how explicit to make a reference to a nonlocal name.

    Source : An Overview of the C++ Programming Language by Bjarne Stroustrup

    I agree with the others here, but would like to address the concerns regarding readability – you can avoid all of that by simply using typedefs at the top of your file, function or class declaration.

    I usually use it in my class declaration as methods in a class tend to deal with similar data types (the members) and a typedef is an opportunity to assign a name that is meaningful in the context of the class. This actually aids readability in the definitions of the class methods.

     //header class File { typedef std::vector Lines; Lines ReadLines(); } 

    and in the implementation:

     //cpp Lines File::ReadLines() { Lines lines; //get them... return lines; } 

    as opposed to:

     //cpp vector File::ReadLines() { vector lines; //get them... return lines; } 

    o:

     //cpp std::vector File::ReadLines() { std::vector lines; //get them... return lines; } 

    An example where using namespace std throws complilation error because of the ambiguity of count, which is also a function in algorithm library.

     #include  using namespace std; int count = 1; int main() { cout<  

    I do not think it is necessarily bad practice under all conditions, but you need to be careful when you use it. If you’re writing a library, you probably should use the scope resolution operators with the namespace to keep your library from butting heads with other libraries. For application level code, I don’t see anything wrong with it.

    “Why is ‘using namespace std;’ considered a bad practice in C++?”

    I put it the other way around: Why is typing 5 extra chars is considered cumbersome by some?

    Consider eg writing a piece of numerical software, why would I even consider polluting my global namespace by cutting general “std::vector” down to “vector” when “vector” is one of the problem domain’s most important concepts?

    With unqualified imported identifiers you need external search tools like grep to find out where identifiers are declared. This makes reasoning about program correctness harder.

    To answer your question I look at it this way practically: a lot of programmers (not all) invoke namespace std. Therefore one should be in the habit of NOT using things that impinge or use the same names as what is in the namespace std. That is a great deal granted, but not so much compared to the number of possible coherent words and pseudonyms that can be come up with strictly speaking.

    I mean really… saying “don’t rely on this being present” is just setting you up to rely on it NOT being present. You are constantly going to have issues borrowing code snippets and constantly repairing them. Just keep your user-defined and borrowed stuff in limited scope as they should be and be VERY sparing with globals (honestly globals should almost always be a last resort for purposes of “compile now, sanity later”). Truly I think it is bad advice from your teacher because using std will work for both “cout” and “std::cout” but NOT using std will only work for “std::cout”. You will not always be fortunate enough to write all your own code.

    NOTE: Don’t focus too much on efficiency issues until you actually learn a little about how compilers work. With a little experience coding you don’t have to learn that much about them before you realize how much they are able to generalize good code into something something simple. Every bit as simple as if you wrote the whole thing in C. Good code is only as complex as it needs to be.

    It depends on where it is located. If it is a common header, then you are diminishing the value of the namespace by merging it into the global namespace. Keep in mind, this could be a neat way of making module globals.

    From my experiences, if you have multiple libraries that uses say, cout , but for a different purpose you may use the wrong cout .

    For example, if I type in, using namespace std; and using namespace otherlib; and type just cout (which happens to be in both), rather than std::cout (or 'otherlib::cout' ), you might use the wrong one, and get errors, it’s much more effective and efficient to use std::cout .

    This is a bad practice, often known as global namespace pollution. Problems may occur when more than one namespace has the same function name with signature, then it will be ambiguous for the compiler to decide which one to call and this all can be avoided when you are specifying the namespace with your function call like std::cout . Espero que esto ayude. 🙂

    I agree with others – it is asking for name clashes, ambiguities and then the fact is it is less explicit. While I can see the use of using , my personal preference is to limit it. I would also strongly consider what some others pointed out:

    If you want to find a function name that might be a fairly common name, but you only want to find it in the std namespace (or the reverse – you want to change all calls that are NOT in namespace std , namespace X , …), then how do you propose to do this? You could write a program to do it but wouldn’t it be better to spend time working on your project itself rather than writing a program to maintain your project?

    Personally I actually don’t mind the std:: prefix. I like the look more than not having it. I don’t know if that is because it is explicit and says to me “this isn’t my code… I am using the standard library” or if it is something else, but I think it looks nicer. This might be odd given that I only recently got into C++ (used and still do C and other languages for much longer and C is my favourite language of all time, right above assembly).

    There is one other thing although it is somewhat related to the above and what others point out. While this might be bad practise, I sometimes reserve std::name for standard library version and name for program-specific implementation. Yes indeed this could bite you and bite you hard but it all comes down to that I started this project from scratch and I’m the only programmer for it. Example: I overload std::string and call it string . I have helpful additions. I did it in part because of my C and Unix (+ Linux) tendency towards lower-case names.

    Besides that, you can have namespace aliases. Here is an example of where it is useful that might not have been referred to. I use the C++11 standard and specifically with libstdc++. Well, it doesn’t have complete std::regex support. Sure it compiles but it throws an exception along the lines of it being an error on the programmer’s end. But it is lack of implementation. Así que aquí está cómo lo resolví. Install Boost’s regex, link it in. Then, I do the following so that when libstdc++ has it implemented entirely, I need only remove this block and the code remains the same:

     namespace std { using boost::regex; using boost::regex_error; using boost::regex_replace; using boost::regex_search; using boost::regex_match; using boost::smatch; namespace regex_constants = boost::regex_constants; } 

    I won’t argue on whether that is a bad idea or not. I will however argue that it keeps it clean for MY project and at the same time makes it specific: True I have to use Boost BUT I’m using it like the libstdc++ will eventually have it. Yes, starting your own project and starting with a standard (…) at the very beginning goes a very long way with helping maintenance, development and everything involved with the project!

    Editar:
    Now that I have time, just to clarify something. I don’t actually think it is a good idea to use a name of a class/whatever in the STL deliberately and more specifically in place of. The string is the exception (ignore the first, above, or second here, pun if you must) for me as I didn’t like the idea of ‘String’. As it is, I am still very biased towards C and biased against C++. Sparing details, much of what I work on fits C more (but it was a good exercise and a good way to make myself a. learn another language and b. try not be less biased against object/classes/etc which is maybe better stated as less closed-minded, less arrogant, more accepting.). But what IS useful is what some already suggested: I do indeed use list (it is fairly generic, is it not ?), sort (same thing) to name two that would cause a name clash if I were to do using namespace std; and so to that end I prefer being specific, in control and knowing that if I intend it to be the standard use then I will have to specify it. Put simply: no assuming allowed.

    And as for making Boost’s regex part of std . I do that for future integration and – again, I admit fully this is bias – I don’t think it is as ugly as boost::regex:: ... Indeed that is another thing for me. There are many things in C++ that I still have yet to come to fully accept in looks and methods (another example: variadic templates versus var args [though I admit variadic templates are very very useful!]). Even those that I do accept it was difficult AND I still have issues with them.

    It doesn’t make worse your software or project performance, the inclusion of the namespace at the beginning of your source code isn’t bad. The inclusion of the using namespace std instruction varies according to your needs and the way you are developing the software or project.

    The namespace std contains the C++ standard functions and variables. This namespace is useful when you often would use the C++ standard functions.

    As is mentioned in this page :

    The statement using namespace std is generally considered bad practice. The alternative to this statement is to specify the namespace to which the identifier belongs using the scope operator(::) each time we declare a type.

    And see this opinion :

    There is no problem using “using namespace std” in your source file when you make heavy use of the namespace and know for sure that nothing will collide.

    Some people had said that is a bad practice to include the using namespace std in your source files because you’re invoking from that namespace all the functions and variables. When you would like to define a new function with the same name as another function contained in the namespace std you would overload the function and it could produce problems due to compile or execute. It will not compile or executing as you expect.

    As is mentioned in this page :

    Although the statement saves us from typing std:: whenever we wish to access a class or type defined in the std namespace, it imports the entirety of the std namespace into the current namespace of the program. Let us take a few examples to understand why this might not be such a good thing

    Now at a later stage of development, we wish to use another version of cout that is custom implemented in some library called “foo” (for example)

    Notice how there is an ambiguity, to which library does cout point to? The compiler may detect this and not compile the program. In the worst case, the program may still compile but call the wrong function, since we never specified to which namespace the identifier belonged.