Me han dicho por otros, que la escritura using namespace std en el código es incorrecto, y que yo debería usar std::cout y std::cin directamente en su lugar.

¿Por qué es using namespace std se considera una mala práctica? Es ineficiente o no riesgo de declarar ambigua variables (variables que comparten el mismo nombre que una función en std espacio de nombres)? Hace impacto en el rendimiento?

No olvide que usted puede hacer: «using std::cout;» lo que significa que usted no tiene que tipo std::cout, pero no traen la totalidad del espacio de nombres std al mismo tiempo.
pagado nerd google-styleguide.googlecode.com/svn/trunk/… enlace no funciona. Se ve como nuevo enlace google.github.io/styleguide/cppguide.html#Other_C++_Features
Es particularmente malo para el uso de ‘using namespace std’ en el ámbito de archivo en los archivos de encabezado. Uso en archivos de código fuente (*.cpp) en el ámbito de archivo después de todo incluye no es tan malo, ya que su efecto se limita a una sola unidad de traducción. Incluso es menos problemático el uso dentro de las funciones o clases, debido a que su efecto se limita a la función o ámbito de la clase.
Yo podría desalentar el uso de el uso de la directiva, pero para los espacios de nombres específicos como std::literals::chrono_literals, Poco::Data:Keywords,Poco::Units y cosas que tratan los literales o la legibilidad de los trucos. Cada vez que está en el encabezado o archivos de implementación. Podría estar bien en el ámbito de la función supongo, pero aparte de literales y esas cosas, que no es útil.
No tiene nada que ver con el espacio de nombres std en particular. Mi énfasis estaba destinado a ser en «en el ámbito de archivo en los archivos de encabezado». Para ponerlo como un consejo: no usar «el uso de espacio de nombres» (sexual o de otro tipo) en el ámbito de archivo en los archivos de encabezado. Está bien que se utilice en la aplicación archivos. Lo siento por la ambigüedad.

OriginalEl autor akbiggs | 2009-09-21

30 Comentarios

  1. 1836

    Esto no está relacionado con el rendimiento. Pero considere esto: usted está utilizando dos bibliotecas llamado Foo y Bar:

    using namespace foo;
    using namespace bar;

    Todo funciona bien, puede llamar a Blah() de Foo y Quux() de la Barra sin problemas. Pero un día de actualizar a una nueva versión de Foo 2.0, que ahora ofrece una función llamada Quux(). Ahora tienes un conflicto: Tanto Foo 2.0 y la Barra de importación Quux() en su espacio de nombres global. Esto va a tomar un poco de esfuerzo para corregir, especialmente si los parámetros de la función de suceder para que coincida.

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

    Siempre me ha gustado el de Python «importar big_honkin_name como bhn» así que usted puede simplemente utilizar «bhn.algo» en lugar de «big_honkin_name.algo», que en realidad reduce la tipificación. ¿C++ tiene algo como eso?
    espacio de nombres io = boost::sistema de archivos;
    Creo que es exagerar las cosas para decir que es «un poco de esfuerzo para corregir». No tendrás ningún instancias de la nueva foo::Quux tan sólo eliminar la ambigüedad de todos sus usos actuales con barra::Quux.
    Haría cualquier persona sensata crear una biblioteca con los tipos de cuyo nombre no calificado chocan con los tipos de ets?
    El problema con #define es que no se limita a los espacios de nombres, pero pisotea toda la base de código. Un espacio de nombres de alias es lo que quieres.

    OriginalEl autor Greg Hewgill

  2. 1197

    Estoy de acuerdo con todo Greg escribió, pero me gustaría añadir: puede incluso empeorar de Greg dijo!

    Biblioteca de Foo 2.0 podría introducir una función, Quux(), que es una forma inequívoca mejor para algunos de sus llamadas a Quux() de la bar::Quux() su código de llamada durante años. Luego de su código compila, pero en silencio llama a la función equivocada y no dios-sabe-qué. Eso es casi tan malo como las cosas se pueden conseguir.

    Tenga en cuenta que el std tiene un montón de espacio de nombres de identificadores, muchos de los cuales son muy comunes (creo list, sort, string, iterator, etc.) que son muy propensos a aparecer en otro código, demasiado.

    Si tenemos en cuenta que esta raro: No se una pregunta aquí en Stack Overflow, donde casi exactamente esto ocurrió (mal función llamada debido a que omite std:: prefijo) sobre la mitad de un año después de que me dio esta respuesta. Aquí es otra, más reciente ejemplo de una pregunta.
    Así que este es un problema real.


    Éste es uno de los puntos de datos: hace muchos, Muchos años, yo también solía resulta molesto tener que prefijo de todo, desde la biblioteca estándar con std::. Entonces yo trabajaba en un proyecto en el que se decidió en el principio de que tanto using directivas y declaraciones están prohibidas, excepto para la función de los ámbitos. ¿Adivinen qué? Tomó la mayoría de nosotros muy pocas semanas para que se acostumbre a escribir el prefijo, y después de un par de semanas más que la mayoría de nosotros, incluso de acuerdo en que realmente hizo el código más legible. Hay una razón para eso: Si te gusta más cortos o más largos de la prosa es subjetiva, pero los prefijos objetivamente añadir la claridad en el código. No sólo el compilador, sino que, también, resulta más fácil ver que el identificador se refiere.

    En una década, que el proyecto creció a tener varios millones de líneas de código. Desde estas discusiones surgen una y otra vez, una vez fui curioso cómo a menudo el (permitido) la función de alcance using en realidad fue utilizado en el proyecto. Yo grep había las fuentes para ella y sólo encontró uno o dos docenas de lugares donde se utiliza. A mí esto indica que, una vez probado, de que los desarrolladores no encontrar std:: bastante doloroso para emplear el uso de directivas incluso una vez cada 100 kLoC incluso cuando no se le permite ser utilizado.


    Línea de base: Explícitamente el prefijo de todo no hacer daño, tarda muy poco en acostumbrarse, y tiene ventajas objetivas. En particular, hace que el código sea más fácil de interpretar por el compilador y por los lectores humanos — y que probablemente debería ser el principal objetivo a la hora de escribir código.

    No perjudicar significativamente la densidad de código que usted puede empacar en una sola línea. Usted termina de escribir su código en un muy de largo aliento modo, lo que reduce la legibilidad. Personalmente, creo que la más corta (pero no demasiado corto) código tiende a ser más legible (ya que hay menos cosas para leer, y menos cosas para distraerse).
    Supongo que se perdió en los viejos tiempos antes de C++ estándar string clase, y aparentemente cada biblioteca tiene su propio. Decirle lo que: vamos a seguir escribiendo nuestro código con std::, y puede ejecutar nuestro código a través de grep -v std:: | vim cuando usted está navegando en él. O usted puede enseñar a su editor que std:: es una palabra clave que es el color de la misma como el color de fondo. Lo que funciona.
    No creo que std:: es perjudicial en absoluto. Se lleva muy importante de la información (es decir, «lo que viene después es parte de la biblioteca estándar», y es todavía bastante corto y compacto prefijo. La mayoría de las veces, no es ningún problema en absoluto. A veces, usted tiene un par de líneas de código en el que usted necesita para referirse a los símbolos específicos en el std un montón de espacio de nombres y, a continuación, un using declaración en ese ámbito determinado resuelve el problema muy bien. Pero en el caso general, no es ruido, proporciona valiosa información además para la eliminación de ambigüedades.
    Cada vez que veo std::, sé que va a ser de std:: sin tener que pensar en ello. Si veo string o list o map por sí mismos, me pregunto un poco.
    Buena suerte a escribir una geometría de la biblioteca sin nombrar algo vector, transform o distance. Y esos son sólo algunos ejemplos de los muchos muchos nombres comunes se utiliza en la biblioteca estándar. Lo que sugiere no hacer uso de ellas de miedo o de una opinión parcial del espacio de nombres de la característica que es una parte integral de C++ es más bien contraproducente.

    OriginalEl autor sbi

  3. 328

    El problema con poner using namespace en el encabezado de los archivos de las clases, es que obliga a cualquier persona que quiera utilizar sus clases (incluyendo su archivos de cabecera) a ser también » uso » (es decir, ver todo en) aquellos otros espacios de nombres.

    Sin embargo, usted puede sentirse libre para poner una instrucción de uso en su (privado) *.archivos cpp.


    Tenga en cuenta que algunas personas no estén de acuerdo con mi diciendo «sentirse libre» como este, porque a pesar de una instrucción en un archivo cpp es mejor que en un encabezado (porque no afecta a la gente que incluir el archivo de encabezado), que creo que todavía no buena (ya que según el código podría hacer que la implementación de la clase más difícil de mantener). Este FAQ tema dice,

    El uso de-la directiva existe para el legado de código C++ y para facilitar la transición a los espacios de nombres, pero probablemente usted no debe utilizar sobre una base regular, al menos no en su nuevo código de C++.

    El FAQ sugiere dos alternativas:

    • Un uso declaración:

      using std::cout; //a using-declaration lets you use cout without qualification
      cout << "Values:";
    • Simplemente escribiendo el std::

      std::cout << "Values:";
    Que es menos malo para ponerlo en una .archivo cpp que en un encabezado, pero el problema se mantiene la misma para el mantenimiento. Es correr el riesgo de que dos funciones con el mismo nombre se chocan cuando el código/la biblioteca/el estándar de C++ se modificó.
    ¿Has probado de todo esto? Debido a que la directiva using namespace no se trasladan a otro archivo. (GCC 4.8+)
    LLVM versión 7.0.2 (clang-700.1.81)» se propaga using namespace std; de encabezado del archivo de origen, y he comprobado que GCC no. Así al menos tener el «uso» de la directiva en el encabezado, es arriesgado.
    Usted realmente no debe decirle a la gente a «sentirse libre» con el uso de espacio de nombres std en una .archivo cpp. @Étienne es correcto.
    Estás haciendo un argumento epistemológico. Son libres porque no nos corresponde a nosotros a prohibir? O no son libres porque tiene negativo reprecussions que se debe considerar y tener cuidado? Yo diría que la opción 2. De todos modos, no debería «sentirse libre», incluso si son «libres» para hacerlo.

    OriginalEl autor ChrisW

  4. 209

    Hace poco me encontré con una queja acerca de Visual Estudio 2010. Resultó que casi todos los archivos de origen tenido estas dos líneas:

    using namespace std;
    using namespace boost;

    Un montón de Impulsar características de entrar en el C++0x estándar, y Visual Estudio 2010 tiene un montón de C++0x características, así que de repente estos programas no eran de la compilación.

    Por lo tanto, evitando using namespace X; es una forma de planificación para el futuro, una forma de asegurarse de que un cambio en las bibliotecas y/o archivos de cabecera en uso no se va a romper un programa.

    Este. Impulsar y sexual, tener un mucho de superposición – especialmente debido a que C++11.
    Yo hice eso una vez y aprendido una lección de la manera difícil. Ahora, yo nunca uso using fuera de la definición de una función y rara vez uso using namespace a todos.

    OriginalEl autor David Thornley

  5. 172

    Versión corta: no uso global uso de declaraciones o de las directivas en los archivos de encabezado. Siéntase libre de utilizar en la aplicación archivos. Aquí es lo que Herb Sutter y Andrei Alexandrescu tienen que decir acerca de este tema en C++ Estándares De Codificación (negrita, por el énfasis es mío):

    Resumen

    Espacio de nombres se utilizan para su comodidad, no para los que infligen a los demás: Nunca se escribe mediante declaración o mediante el uso de la directiva antes de una directiva #include.

    Corolario: En los archivos de encabezado, no escriba en el espacio de nombres de nivel mediante directivas o el uso de declaraciones; por el contrario, explícitamente espacio de nombres a calificar a todos los nombres. (La segunda regla se sigue de la primera, porque encabezados nunca se puede saber lo que otros encabezado #incluye podrían aparecer después de ellos.)

    Discusión

    En breve: Se puede y debe utilizar el espacio de nombres mediante declaraciones y directivas abundantemente en su implementación archivos después de directivas #include y se sienten bien acerca de ello. A pesar de las repetidas afirmaciones en contrario, el espacio de nombres mediante declaraciones y directivas no están mal, y no anule el propósito de espacios de nombres. Más bien, ellos son lo que hacen que los espacios de nombres utilizable.

    Triste que este cuerdo orientación es tan enterrado bajo equivocadas respuestas.
    Sólo uno más del programador de opinión aquí, pero aunque estoy de acuerdo 100% con la afirmación de que la palabra using nunca debe aparecer en un encabezado, yo no estoy tan convencido acerca de la licencia libre para colocar using namespace xyz; en cualquier lugar en el código, especialmente si xyz es std. Yo uso el using std::vector; forma, ya que sólo tira de un solo elemento del espacio de nombres en el seudo-ámbito global, por lo tanto conduce a mucho menos riesgo de una colisión.
    Carreras en Órbita, por supuesto, tiene derecho a su opinión. Habría sido más útil si ha habido algún intento de explicación de por qué usted no está de acuerdo con las recomendaciones dadas en esta respuesta. Sobre todo sería interesante para entender lo que es el punto de los espacios de nombres si » con » ellos, es malo? ¿Por qué no sólo el nombre de las cosas std_cout en lugar de std::cout … los creadores de C++/espacio de nombres debe haber tenido alguna idea de cuando se molestó en crear.
    No hay necesidad – la mayoría de las otras respuestas dan las mismas razones que yo. También, por favor no dude en nota el «:)» I anexa a mi comentario! Y que no me digan los espacios de nombres son malos.
    Sí, me di cuenta de que 🙂 pero la OMI la mayoría de la respuesta (que van en contra de este sabio consejo) son equivocadas (no es que no me hizo ninguna de las estadísticas de lo que es la mayoría). Si usted está de acuerdo que el espacio de nombres ‘no está mal’, a continuación, usted podría decir donde usted piensa que son apropiados si usted no está de acuerdo con esta respuesta?

    OriginalEl autor mattnewport

  6. 108

    Uno no debería usar la directiva en el ámbito global, especialmente en los encabezados. Sin embargo, hay situaciones en las que es apropiada, incluso en un archivo de encabezado:

    template <typename FloatType> 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 explícita de calificación (std::sin, std::cos…)
    porque es más corta y tiene la capacidad de trabajar con el usuario define los tipos de punto flotante (a través del Argumento de la Búsqueda Dependiente).

    Yo lo siento, pero estoy totalmente en desacuerdo con esto.
    No hay ninguna otra manera de llamar a userlib::cos(userlib::superint). Cada función tiene un uso.
    Por supuesto que hay. using std::cos; , using std::sin, etc. El problema es que aunque cualquier bien diseñado userlib va a tener su sin y cos dentro de su propio espacio de nombres, así que este realmente no te ayuda. (A menos que haya un using namespace userlib antes de esta plantilla y eso es tan malo como using namespace std — y el alcance no es limitada.) Además, la única función como esta que veo cada vez que esto suceda es swap, y en esos casos yo recomiendo la creación de una plantilla de especialización de std::swap y evitar todo el problema.
    template<typename T> void swap(MyContainer<T>&, MyContainer<T>&) (No hay ninguna plantilla de función parcial de especialización (FTPS), así que a veces es necesario recurrir a una sobrecarga en su lugar.
    Tu (7-veces-upvoted!) comentario equivocado — la situación que usted describe es exactamente lo ADL ha sido diseñado para cubrir. Brevemente, si x tiene uno o más espacios de nombres asociados» (por ejemplo, si se define en namespace userlib), a continuación, cualquier llamada a la función que se parece a cos(x) se asimismo look en esos espacios de nombres — sin cualquier using namespace userlib; de antemano de ser necesario. Zan Lince es correcto (y C++ en la búsqueda del nombre es bizantino…)

    OriginalEl autor robson3.14

  7. 84

    No lo uso a nivel mundial

    Se considera «malo» sólo cuando utilizado en todo el mundo. Porque:

    • Que el desorden en el espacio de nombres de la programación en.
    • Los lectores tendrán dificultad para ver donde un identificador en particular proviene de, al utilizar muchos using namespace xyz.
    • Todo lo que es verdadero para otros los lectores de su código fuente es aún más cierto para la más frecuente lector de: a ti mismo. Volver en un año o dos y echar un vistazo…
    • Si solamente hablamos de using namespace std no puede ser consciente de todas las cosas que agarrar — y cuando se agrega otra #include o trasladarse a un nuevo C++ versión en la que se puede obtener el nombre de los conflictos que no eran conscientes de.

    Puede utilizar localmente

    Seguir adelante y utilizar de forma local (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, hubo un modismo — código repetitivo — para la implementación de un swap función para sus clases. Se sugirió que en realidad el uso de 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 el mágico siguiente:

    • El compilador elegir el std::swap para value_, es decir,void std::swap(int, int).
    • Si usted tiene una sobrecarga void swap(Child&, Child&) implementado el compilador va a elegir.
    • Si usted no tener que sobrecargar el compilador utilizará void std::swap(Child&,Child&) y probar su mejor intercambio de estos.

    Con C++11 no hay ninguna razón para usar este patrón. La aplicación de std::swap fue cambiado a encontrar una posible sobrecarga y elegir.

    «La aplicación de std::swap fue cambiado a encontrar una posible sobrecarga y elegir.» – ¿Qué? Está usted seguro de eso? Si bien es cierto que la prestación de una costumbre swap en primer lugar no es muy importante en C++11, ya que el std::swap sí es más flexible (se utiliza mover la semántica). Pero std::swap automáticamente eligiendo su propio personalizado de intercambio, que es absolutamente nuevo para mí (y yo no me lo creo).
    Yo creo que sí, sí. He leído esto en MANERA alguna parte. Siempre podemos pedir Howardél debe saber. Yo soy excavación y excavación ahora…
    Incluso en el swap caso, la más clara (y afortunadamente más común) modismo es escribir using std::swap; en lugar de using namespace std;. El más específico de lenguaje tiene menos efectos secundarios y por lo tanto hace el código más fácil de mantener.
    La frase final es malo. En C++11 de la Std Intercambiar Dos Paso fue oficialmente beato como la derecho para llamar a swap, y en varios otros lugares en el estándar se cambió a decir que ellos llaman swap como que (N. B. como se indicó anteriormente, using std::swap es el camino correcto, no using namespace std). Pero std::swap sí fue enfático no cambiado a encontrar en algún otro swap y uso. Si std::swap se llama, entonces std::swap utilizados.
    Puede ser más sensato justo el tipo de using std::swap localmente a pesar de que, para reducir el espacio de nombres local, mientras que al mismo tiempo la creación de auto-documentar el código. Ustedes son raramente interesados en todo el espacio de nombres std, por lo que acaba de salir de escoger las piezas que usted está interesado en.

    OriginalEl autor towi

  8. 72

    Si importa el derecho archivos de encabezado de repente tienen nombres como hex, , más o cuenta en el ámbito global. Esto puede ser sorprendente, si no son conscientes de que std:: contiene estos nombres. Si usted también trate de usar estos nombres localmente puede llevar a cierta confusión.

    Si todas las cosas estándar es en su propio espacio de nombres que usted no tiene que preocuparse acerca de las colisiones de nombres con su código o de otras bibliotecas.

    +1 por no hablar de distance. todavía prefiero no calificados de nombres donde prácticamente posibilidad, ya que aumenta la legibilidad para mí. además, creo que el hecho de que por lo general no cumplen con los requisitos de las cosas en el discurso oral, y que están dispuestos a pasar tiempo en la resolución de posibles ambigüedades, significa que tiene valor para ser capaz de entender lo que uno está hablando de sin cualificación, y aplicado al código fuente que significa que está estructurado de tal manera que es claro que de lo que se trata, incluso sin titulación.
    Para ser justos, sin embargo, usted no tiene la mayoría de esos si no se incluyen <iomanip>. Aún así, buen punto.

    OriginalEl autor sth

  9. 37

    Programadores experimentados utilizar lo que soluciona sus problemas y evitar lo que crea nuevos problemas, y evitar el encabezado de nivel de archivo directivas using por esta razón exacta.

    Programadores experimentados tratar de evitar también la cualificación completa de nombres dentro de sus archivos de origen. Una menor razón de esto es que no es elegante para escribir más código cuando menos código es suficiente a menos que existan buenas razones. Una razón importante para esto es la desactivación de la búsqueda dependiente de argumentos (ADL).

    ¿Cuáles son estos buenas razones? A veces los programadores explícitamente que desee desactivar la ADL, otras veces se desea desambiguar.

    Por lo que los siguientes son OK:

    1. Función del nivel de uso de directivas y el uso de declaraciones dentro de las funciones de’ implementaciones
    2. Del archivo de origen a nivel de uso de declaraciones dentro de los archivos de origen
    3. (A veces) del archivo de origen a nivel de directivas using
    Definir la «elegancia».

    OriginalEl autor Alexander Poluektov

  10. 36

    Otra razón es la sorpresa.

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

    Creo que lo que es este cout? Es normal cout? Es algo especial?

    Es una broma? Yo realmente no se puede decir. Si no, entonces yo personalmente haría suponer que es el normal ‘cout’ a menos que usted no confía en el código ya que de lo contrario sería un más ALLÁ de la IMPORTANTE código de olor, de la OMI. … Y si no se confía en el código, entonces ¿por qué estás usando en el primer lugar? Tenga en cuenta que no estoy diciendo que «la CONFIANZA de Todo!!» pero esto también me parece un poco descabellada si usted es, decir, tratar con algunos conocidos de la biblioteca de GitHub o algo.
    cout es un mal ejemplo porque todo el mundo lo reconoce. Pero imagino que future la situación financiera en la aplicación. Es un contrato para comprar o vender algo en una fecha determinada? No, No es así. Si el código de dicho std::future que no sería tan fácil de confundir.
    tal vez un poco de mal ejemplo, hay por lo menos cuatro diferentes bibliotecas que han cout. Puede ser «es el estándar de la biblioteca? libstdc++? stl? algo más?» Y no, no todo el mundo sabe std::cout, al menos de manera inherente, de 6, de 7 de nuevos trabajadores que recibimos no. Debido a que los planes de estudio de la educación no uso de esas en la educación. Tengo para ahuyentar printfs. O depura() – a partir de Qt.

    OriginalEl autor Martin Beckett

  11. 35

    Estoy de acuerdo en que no debe utilizarse en todo el mundo, pero no es tan malo para utilizar localmente, como en un namespace. He aquí un ejemplo de «El Lenguaje de Programació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, hemos resuelto el potencial de nombre de enfrentamientos y ambigüedades derivadas de su composición.

    Nombres explícitamente declarado allí (incluyendo los nombres de los declarados por el uso de declaraciones como His_lib::String) tienen prioridad sobre los nombres accesible en otro ámbito mediante una directiva (using namespace Her_lib).

    OriginalEl autor Oleksiy

  12. 24

    También considero que es una mala práctica. Por qué? Sólo un día pensé que la función de un espacio de nombres es dividir las cosas así que no debería estropear con tirar todo en una bolsa.
    Sin embargo, si utilizo a menudo ‘cout’ y ‘cin’, escribo: using std::cout; using std::cin; en el archivo cpp (nunca en el archivo de encabezado a medida que se propaga con #include). Creo que nadie cuerdo nunca el nombre de un arroyo cout o cin. 😉

    Eso es un local con la declaración de, una cosa muy diferente de un con la directiva.

    OriginalEl autor Yelonek

  13. 19

    Es todo acerca de la gestión de la complejidad. Utilizando el espacio de nombres se tire de las cosas en que usted no quiere, y lo que, posiblemente, hacer que sea más difícil para depurar (digo posiblemente). Usar std:: por todo el lugar es más difícil de leer (más de texto y todo eso).

    Caballos para los cursos de gestionar su complejidad cómo mejor puede y se sienten capaces.

    OriginalEl autor Preet Sangha

  14. 19

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

    Ahora tomar un millón de código de la línea de base, que no es especialmente grande, y estás en busca de un error, lo que significa que usted sabe que hay una línea en este de un millón de líneas que no hace lo que se supone que debe hacer. cout << 1; podía leer un static int nombre cout, desplazamiento a la izquierda un poco, y bote el resultado. Buscando un bug, yo tendría que ver eso. Se puede ver cómo yo realmente prefiero ver std::cout?

    Es una de esas cosas que parecen una muy buena idea si usted es un maestro, y nunca tuve que escribir y mantener cualquier código para vivir. Me encanta ver el código en el que (1) yo sé lo que hace; y, (2) estoy seguro de que la escritura de la persona que sabía lo que se hace.

    ¿Cómo saber «std::cout << 1» no es la lectura de un static int nombre cout en el espacio de nombres std cambio por uno y tirar resultado? También, ¿cómo saber qué «<<» no 😉 ??? … parece que esta respuesta no es buen punto de datos para evitar el ‘uso’.
    Si alguien ha redefinido std::cout que ser un número entero, entonces el problema no es técnico, sino social, alguien lo tiene para ti. (y probablemente, usted debe también comprobar todos los encabezados por cosas como #define true false, etc)
    Cuando veo cout sé que es std::cout, siempre. Si estoy equivocado, es problema de la persona que escribió este código, no a mí 🙂

    OriginalEl autor gnasher729

  15. 16
    1. que usted necesita para ser capaz de leer el código escrito por personas que tienen un estilo diferente y las mejores prácticas de las opiniones de usted.

    2. Si sólo está utilizando cout, nadie se confunde. Pero cuando usted tiene un montón de espacios de nombres volando a su alrededor y se ve que esta clase y usted no está seguro exactamente lo que hace, tener el espacio de nombres explícitos actúa como un comentario de tipo. Usted puede ver a primera vista, ‘oh, esto es un sistema de ficheros de la operación’ o ‘es haciendo otras cosas de la red’.

    OriginalEl autor Dustin Getz

  16. 16

    El uso de muchos de los espacios de nombres al mismo tiempo es, obviamente, una receta para el desastre, pero usando un poco de espacio de nombres std y solo espacio de nombres std no es un gran problema, en mi opinión, debido a la redefinición sólo puede producirse por su propio código…

    Por lo que sólo consideran las funciones de la reserva de nombres como «int» o «de clase» y que es.

    La gente debería dejar de ser tan puntual. Su maestro fue a la derecha a lo largo de todos. Sólo el uso de UN espacio de nombres; que es el punto entero de la utilización de espacios de nombres en el primer lugar. Usted no debe usar más de una al mismo tiempo. A menos que es su propio. Así que, de nuevo, la redefinición no va a suceder.

    La creación de colisiones no es tan difícil – cadenas cortas como min, end y less aparecen en la std:: espacio de nombres. Pero es más, ahora que std:: tiene miles de símbolos en ella, es útil para que el lector sepa donde un nuevo símbolo que no sepa viene.
    El espacio de nombres std existe porque la gente, ya sea a usted, a sus colegas, o a la gente de la escritura de middleware que usted use, no siempre son sabios acerca de poner funciones en el interior de los espacios de nombres. Por lo tanto usted puede importar todos std:: y nada más, aunque siguen invocando una colisión entre, digamos, std::min y algún otro legado ::min() desde antes de la época cuando estaba en el ets.

    OriginalEl autor user2645752

  17. 15

    Considerar

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

    Tenga en cuenta que este es un simple ejemplo, si usted tiene archivos con 20 incluye y otras importaciones vas a tener un montón de dependencias para ir a través de averiguar el problema. Lo peor de todo es que usted puede conseguir relacionado los errores en los otros módulos, dependiendo de las definiciones que están en conflicto.

    No es horrible, pero te ahorrará dolores de cabeza por no usarlo en los archivos de cabecera o el espacio de nombres global. Es probablemente bueno para hacerlo en un número limitado de ámbitos pero nunca he tenido un problema de tipificación de la extra de 5 caracteres para aclarar donde mis funciones están viniendo.

    OriginalEl autor Ron Warholic

  18. 10

    Un espacio de nombres es el nombre de un ámbito. Los espacios de nombres se utilizan para agrupar los relacionados con las declaraciones y mantener separados
    artículos separados. Por ejemplo, dos por separado las bibliotecas pueden utilizar el mismo nombre para referirse a las diferentes
    artículos, pero un usuario puede utilizar tanto:

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

    La repetición de un nombre de espacio de nombres puede ser una distracción para ambos lectores y escritores. Por consiguiente, es posible
    para el estado que los nombres de un espacio de nombres particular están disponibles sin el expreso de la calificación. Por ejemplo:

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

    Espacios de nombres proporciona una poderosa herramienta para la gestión de las diferentes bibliotecas y de las diferentes versiones de
    código. En particular, ofrecen al programador alternativas de cómo explícito a hacer una referencia a un no locales
    nombre.

    Fuente : Una Visión general del Lenguaje de Programación C++
    por Bjarne Stroustrup

    Muy interesante que esta respuesta que se basa en la orientación de ningún otro que Bjarne Stroustrup ha ganado -2… chico Bjarne debe haber sido un pobre y sin experiencia, programador cuando introdujo esta función en C++
    Consulte this.

    OriginalEl autor Rohan Singh

  19. 10

    Un ejemplo concreto para aclarar la cuestión. Imagina que tienes una situación donde usted tiene 2 bibliotecas, foo y bar, cada uno con su propio espacio de nombres:

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

    Ahora digamos que usted use foo y bar junto en su propio programa, como sigue:

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

    A este punto, todo está bien. Cuando ejecuta el programa es ‘algo’. Pero después de actualizar de la barra y digamos que ha cambiado a ser como:

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

    En este punto, usted obtendrá un error del compilador:

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

    Así que usted necesitará hacer un poco de mantenimiento para aclarar que ‘un’ significado (es decir,foo::a). Eso es probablemente indeseables, pero, afortunadamente, es bastante fácil (sólo tiene que añadir foo:: en frente de todas las llamadas a a que el compilador de marcas como ambiguo).

    Pero imaginar un escenario alternativo donde la barra cambiado en lugar de mirar como este lugar:

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

    En este punto de su llamada a a(42) de repente se une a bar::a en lugar de foo::a y en lugar de hacer ‘algo’ que hace ‘algo completamente diferente». Ninguna advertencia del compilador o nada. El programa sólo en silencio comienza a hacer algo completamente diferente que antes.

    Cuando se utiliza un espacio de nombres se arriesga a que un escenario como este, que es por qué la gente se siente incómodo el uso de espacios de nombres. La más cosas en un espacio de nombres que el mayor es el riesgo de conflicto, por lo que la gente podría ser aún más incómodo using namespace std (debido a la cantidad de cosas en ese espacio de nombres) de otros espacios de nombres.

    En última instancia, este es un trade-off entre writability vs confiabilidad y mantenibilidad. La legibilidad de mayo factor que también, pero yo podía ver los argumentos para que ir de cualquier manera. Normalmente yo diría que la fiabilidad y la mantenibilidad son más importantes, pero en este caso tendrás constantemente pagar el writability costo bastante rara, la confiabilidad y la mantenibilidad del impacto. El ‘mejor’ trade-off va a determinar en su proyecto y sus prioridades.

    OriginalEl autor Kevin

  20. 8

    Un ejemplo donde using namespace std lanza complilation de error debido a la ambigüedad del conde, que es también una función en el algoritmo de la biblioteca.

    #include <iostream>
    
    using namespace std;
    
    int count = 1;
    int main() {
        cout<<count<<endl;
    }
    ::count: problema resuelto. Por lo general, usted tendrá más cosas de las ets nombres de espacios que de otra parte, ergo mantenimiento de la directiva using namespace puede ahorrar a escribir.
    El verdadero problema aquí es que C++ todavía tiene espacio de nombres-menos globales. Esto, y el hecho de que ‘esto’ está implícita en los métodos, la causa de tantos errores y problemas que yo no los puedo ni contar, incluso, con el derecho de ‘count’ variable. 😉

    OriginalEl autor Nithin

  21. 8

    Estoy de acuerdo con los otros aquí, pero quisiera abordar las preocupaciones con respecto a la legibilidad – usted puede evitar todo eso por el simple uso de las definiciones de tipos en la parte superior de su archivo, la función o la declaración de la clase.

    Normalmente yo uso en mi declaración de la clase como métodos en una clase tienden a tratar con similares tipos de datos (los miembros) y un typedef es una oportunidad para asignar un nombre que tenga sentido en el contexto de la clase. Esta realidad ayuda a mejorar la legibilidad en las definiciones de los métodos de la clase.

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

    y en la implementación:

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

    frente a:

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

    o:

    //cpp
    std::vector<std::string> File::ReadLines()
    {
        std::vector<std::string> lines;
        //get them...
        return lines;
    }
    Sólo un menor comentario, mientras que el typedef es útil me gustaría considerar la posibilidad de hacer una clase que representa las Líneas en lugar de usar typedef.

    OriginalEl autor Carl

  22. 7

    «¿Por qué es » using namespace std;’ se considera una mala práctica en C++?»

    Lo puse al revés: ¿por Qué escribe 5 extra caracteres se considera engorroso por algunos?

    Considerar por ejemplo, escribir una pieza de numérico de software, ¿por qué me podría incluso considerar la posibilidad de contaminar mi espacio de nombres global por corte general «std::vector» a «vector» cuando «vector» es uno de los problema de dominio de los conceptos más importantes?

    No es sólo 5 extra caracteres; sus 5 extra de caracteres cada vez que hace referencia a cualquier tipo de objeto en la biblioteca estándar. Lo cual, si estás usando el estándar de la biblioteca de mucho, será a menudo. Así que es más realista de miles de caracteres en un tamaño decente programa. Es de suponer que el ‘uso’ de la directiva se agregó a la lengua de modo que pueda ser utilizado de…
    No 5 extra caracteres en cada ocasión, es de 5 caracteres y probablemente un par de clics de ratón para tirar abajo un menú y hacer un Buscar y Reemplazar en el editor de su elección.
    La legibilidad. cout << hex << setw(4) << i << endl; es más fácil de leer que std::cout << std::hex << std::setw(4) << i << std::endl;
    Y aún peor: std::map<std::string,std::pair<std::string,std::string>> es horrible en comparación con map<string,pair<string,string>>.
    Es una buena práctica es typedef sus contenedores STL de todos modos, así std:: realmente no importa. Y C++11 nos trajo la palabra clave auto que hace las cosas aún más fácil cuando, por ejemplo, el uso de iteradores.

    OriginalEl autor Solkar

  23. 6

    No creo que sea necesariamente mala práctica en todas las condiciones, pero debe tener cuidado cuando se utiliza. Si usted está escribiendo una biblioteca, usted probablemente debería utilizar el ámbito de la resolución de los operadores con el espacio de nombres para mantener su biblioteca de tienen fricciones con otras bibliotecas. Para el nivel de aplicación del código, no veo nada de malo con ello.

    OriginalEl autor Dr. Watson

  24. 5

    Para responder a tu pregunta yo lo veo de esta manera prácticamente: un montón de programadores (no todos) invocar el espacio de nombres std. Por lo tanto, uno debe estar en el hábito de NO usar cosas que influyen, o utilizar los mismos nombres como lo es en el espacio de nombres std. Que es una gran cantidad concedida, pero no tanto en comparación con el número de posibles coherente palabras y seudónimos que puede venir para arriba con estrictamente hablando.

    Me refiero a realmente… diciendo: «no confíe en este estar presente» es sólo la configuración a confiar en ella NO está presente. Usted está constantemente va a tener problemas de endeudamiento de los fragmentos de código y constantemente la reparación de ellos. Sólo mantén tus definidos por el usuario y cosas prestadas de alcance limitado como debería ser y ser MUY parco con globals (honestamente globals debería ser casi siempre un último recurso para fines de «compilar ahora, la cordura, más tarde»). Realmente creo que es un mal consejo de su maestro porque el uso de la ets de trabajo para ambos «cout» y «std::cout», pero NO mediante sexual, sólo funcionará para «std::cout». No siempre va a ser lo suficientemente afortunado como para escribir tu propio código.

    NOTA: no se centran demasiado en los temas de eficiencia hasta que, de hecho, aprender un poco acerca de cómo los compiladores de trabajo. Con un poco de experiencia de codificación usted no tiene que aprender mucho acerca de ellos antes de que te das cuenta de lo mucho que son capaces de generalizar un buen código en algo simple. Tan simple como que si usted escribió toda la cosa, en C. un Buen código es tan complejo como tiene que ser.

    Teniendo en cuenta cómo muchos de folk parecen percatarse de útiles funciones de biblioteca estándar (la reinvención de las cosas de <algorithm>, por ejemplo), me parece un poco de un tramo a imaginar que la misma gente de forma fiable puede evitar esos identificadores. Mirar a través de su propio código y me diga que usted nunca tendrá una variable o una función llamada count. O distance, o log, destroy, launch, visit, beta, sample, messages, clamp, erase, copy, modulus, left, etc. Por no hablar de todos los identificadores aún no std que se rompa el código C++35 sale…

    OriginalEl autor Noneyo Getit

  25. 5

    Estoy de acuerdo con otros – se está pidiendo el nombre de los enfrentamientos, las ambigüedades y, a continuación, el hecho es que es menos explícito. Mientras puedo ver el uso de using, mi preferencia personal es el límite. También me gustaría considerar la posibilidad de ser lo que algunos otros señalaron:

    Si quieres encontrar un nombre de función que puede ser un nombre bastante común, pero sólo desea encontrar en el std espacio de nombres (o a la inversa – desea cambiar todas las llamadas que NO están en el espacio de nombres std, espacio de nombres X, …), entonces ¿cómo se propone usted hacer esto? Se podría escribir un programa para hacerlo, pero ¿no sería mejor dedicar tiempo a trabajar en el proyecto en sí, en vez de escribir un programa para mantener su proyecto?

    Personalmente creo que en realidad no les importa el std:: prefijo. Me gusta el look que más que no tener. No sé si es porque es explícita y me dice: «esta no es mi código… estoy usando la librería estándar» o si es otra cosa, pero creo que se ve mejor. Este puede ser extraña dado que lo único que he conseguido recientemente en C++ (utilizado y todavía hacer C y de otros idiomas durante mucho más tiempo y C es mi idioma favorito de todos los tiempos, justo encima de la asamblea).

    Hay otra cosa aunque es algo relacionado con el anterior y lo que otros señalan. Mientras que esto podría ser una mala práctica, a veces me reserva std::name para la biblioteca estándar de versión y el nombre para el programa específico de la aplicación. Sí, de hecho, esto podría morder y morder duro, pero todo se viene abajo para que comencé este proyecto desde el principio, y yo soy el único programador. Ejemplo: yo sobrecarga std::string y llamar string. He útil adiciones. Yo lo hice en parte debido a mi C y Unix (Linux) tendencia hacia nombres en minúsculas.

    Además de eso, usted puede tener espacio de nombres de alias. Aquí es un ejemplo de los que es útil que puede que no hayan sido mencionados. Yo uso el C++11 y específicamente con libstdc++. Bien, no tiene completa std::regex de apoyo. Seguro que compila pero lanza una excepción a lo largo de las líneas de tratarse de un error en el programador. Pero es la falta de la aplicación. Así que aquí está cómo lo resolví. Instalar Boost regex, enlace. Entonces, hago la siguiente, de modo que cuando libstdc++ ha implementado completamente, sólo tengo que quitar este bloque y el código sigue siendo el mismo:

    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;  
    }

    No voy a discutir sobre si que es una mala idea o no. Yo sin embargo, argumentan que la mantiene limpia para MI proyecto y al mismo tiempo hace que sea más específica: la Verdad tengo que usar el Boost, PERO lo estoy usando como libstdc++ llegará a tener. Sí, a partir de su propio proyecto y empezar con una norma (…) al principio va un largo camino en ayudar con el mantenimiento, desarrollo y todo lo relacionado con el proyecto!

    Edición:

    Ahora que tengo tiempo, solo para aclarar algo. Yo en realidad no creo que sea una buena idea usar un nombre de una clase/lo que sea en la STL deliberadamente y, más específicamente, en lugar de. La cadena es la excepción (ignorar la primera, arriba, o de segunda aquí, juego de palabras, si usted debe) para mí, como no me gusta la idea de ‘Cadena’. Como es que aún soy muy sesgada hacia C y sesgada en contra de C++. Ahorradores de detalles, mucho de lo que yo trabajo se ajusta más C (pero fue un buen ejercicio y una buena manera para hacerme una. aprender otro idioma y b. trate de no ser menos sesgada en contra de objeto/clases/etc que es, quizás, mejor dicho como menos cerrados de mente, menos arrogante, más tolerante.). Pero lo que ES útil es lo que algunos ya han sugerido: yo en realidad uso de la lista (es bastante genérica, ¿no es así ?), sort (lo mismo), a nombre de dos que podrían causar un nombre de choque si yo fuera a hacer using namespace std; para ese fin, prefiero estar específico, en el control y sabiendo que si tengo la intención de ser el estándar de uso, a continuación, voy a tener que especificarlo. Puesto simplemente: no asumiendo permitido.

    Y como para tomar Impulso del regex parte de std. Yo que para el futuro de la integración y, de nuevo, admito plenamente este es el sesgo – creo que no es tan feo como boost::regex:: ... de Hecho, eso es otra cosa para mí. Hay muchas cosas en C++ que todavía me tienen que aceptar plenamente en la mira y métodos (otro ejemplo: variadic plantillas versus var args [aunque admito variadic las plantillas son muy útiles!]). Incluso aquellos que acepto fue difícil Y todavía tengo problemas con ellos.

    OriginalEl autor

  26. 5

    No empeorar su software o rendimiento de los proyectos, la inclusión del espacio de nombres en el comienzo de su código fuente no está mal. La inclusión de la using namespace std instrucción varía de acuerdo a sus necesidades y la forma en que se desarrolla el software o proyecto.

    La namespace std contiene el estándar de C++ las funciones y variables. Este espacio de nombres es útil cuando a menudo iba a utilizar el estándar de C++ funciones.

    Como se menciona en este página:

    La instrucción using namespace std es generalmente considerado malo
    en la práctica. La alternativa a esta norma es especificar el
    espacio de nombres para el que el identificador pertenece usando el operador de ámbito(::)
    cada vez que declarar un tipo.

    Y ver esta opinión:

    Hay ningún problema en usar «using namespace std» en el archivo de origen
    cuando usted hace uso intensivo del espacio de nombres y la certeza de que
    nada va a chocar.

    Algunas personas han dicho que es una mala práctica de incluir el using namespace std en los archivos de origen porque se está invocando a partir de ese espacio de nombres de todas las funciones y variables. Cuando se desea definir una nueva función con el mismo nombre que otra de las funciones contenidas en el namespace std sobrecargar la función y podría producir problemas debido a compilar o ejecutar. No va a compilar o ejecutar como usted espera.

    Como se menciona en este página:

    Aunque la declaración que nos salva de escribir std:: siempre
    queremos acceso a una clase o tipo definido en el espacio de nombres std,
    las importaciones de la totalidad del espacio de nombres std en el espacio de nombres actual
    de el programa. Tomemos un par de ejemplos para entender el porqué de esta
    podría no ser una buena cosa

    Ahora en una etapa posterior de desarrollo, queremos usar otra versión de
    cout que es la medida implementada en algunos de biblioteca llamado «foo» (para
    ejemplo)

    Observa cómo hay una ambigüedad, a la que la biblioteca hace cout punto a?
    El compilador puede detectar esto y no compilar el programa. En el peor de los
    caso, el programa todavía puede compilar pero llame a la función equivocada, ya que
    nunca hemos especificado para que el identificador de espacio de nombres pertenecían.

    OriginalEl autor CryogenicNeo

  27. 4

    Con incompetente importados identificadores externo necesitará de herramientas de búsqueda como grep para averiguar dónde identificadores declarados. Esto hace que el razonamiento sobre el programa de corrección más difícil.

    OriginalEl autor August Karlstrom

  28. 4

    Depende de dónde se encuentra. Si es un encabezado común, entonces usted está disminuyendo el valor del espacio de nombres mediante la fusión en el espacio de nombres global. Tenga en cuenta que esta podría ser una buena manera de hacer que el módulo globales.

    OriginalEl autor MathGladiator

  29. 4

    De mis experiencias, si usted tiene varias bibliotecas que utiliza decir, cout, pero para un propósito diferente, usted puede utilizar el mal cout.

    Por ejemplo, si yo escriba, using namespace std; y using namespace otherlib; y el tipo sólo cout (que pasa a ser en ambos), en lugar de std::cout (o 'otherlib::cout'), puede utilizar el equivocado, y obtener errores, es mucho más eficaz y eficiente en el uso de std::cout.

    OriginalEl autor Engine Dev

  30. 4

    Esta es una mala práctica, a menudo conocido como el espacio de nombres global de la contaminación. Los problemas pueden ocurrir cuando hay más de un espacio de nombres tiene el mismo nombre de la función con la firma, entonces será ambigua para el compilador para decidir que una llamada y todo esto puede ser evitado cuando se especifica el espacio de nombres con su llamada a la función como std::cout . Espero que esto ayude. 🙂

    OriginalEl autor adn.911

Dejar respuesta

Please enter your comment!
Please enter your name here