¿El mejor nivel de advertencia del comstackdor para los comstackdores C / C ++?

¿Qué nivel de advertencia del comstackdor recomiendas para diferentes comstackdores de C / C ++?

gcc yg ++ le permitirán salirse con la suya en el nivel predeterminado. El mejor nivel de advertencia para mí es ‘-Wall’. Y siempre trato de eliminar corregir el código de las advertencias que genera. (Incluso los tontos sobre el uso de paréntesis para las reglas de precedencia lógica o decir que realmente quiero decir ‘if (x = y)’)

¿Cuáles son sus niveles favoritos para los diferentes comstackdores, como Sun CC, aCC (HPUX?), Visual Studio, Intel?

Editar:

Solo quería señalar que no uso “-Werror” (pero sí entiendo su utilidad) en gcc / g ++ porque, uso:

 # advertencia "esta es una nota para mí"

en algunos lugares en mi código. ¿Comprenden todos los comstackdores la macro #warning?

Este es un conjunto de indicadores extraparanoicos que estoy usando para el código C ++:

-g -O -Wall -Weffc++ -pedantic \ -pedantic-errors -Wextra -Waggregate-return -Wcast-align \ -Wcast-qual -Wchar-subscripts -Wcomment -Wconversion \ -Wdisabled-optimization \ -Werror -Wfloat-equal -Wformat -Wformat=2 \ -Wformat-nonliteral -Wformat-security \ -Wformat-y2k \ -Wimplicit -Wimport -Winit-self -Winline \ -Winvalid-pch \ -Wunsafe-loop-optimizations -Wlong-long -Wmissing-braces \ -Wmissing-field-initializers -Wmissing-format-attribute \ -Wmissing-include-dirs -Wmissing-noreturn \ -Wpacked -Wpadded -Wparentheses -Wpointer-arith \ -Wredundant-decls -Wreturn-type \ -Wsequence-point -Wshadow -Wsign-compare -Wstack-protector \ -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default \ -Wswitch-enum -Wtrigraphs -Wuninitialized \ -Wunknown-pragmas -Wunreachable-code -Wunused \ -Wunused-function -Wunused-label -Wunused-parameter \ -Wunused-value -Wunused-variable -Wvariadic-macros \ -Wvolatile-register-var -Wwrite-strings 

Eso debería darte algo para empezar. Dependiendo de un proyecto, es posible que deba atenuarlo para no recibir advertencias provenientes de bibliotecas de terceros (que por lo general son bastante descuidadas al ser libre de advertencias). Por ejemplo, el código Boost vectorial / matriz hará que g ++ emita mucho de ruido.

Una mejor forma de manejar estos casos es escribir un contenedor alrededor de g ++ que todavía use advertencias ajustadas al máximo, pero que le permita a uno evitar que se vean para archivos / números de línea específicos. Escribí tal herramienta hace mucho tiempo y la lanzaré una vez que tenga tiempo para limpiarla.

En Visual C ++, utilizo /W4 y /WX (trate las advertencias como errores).

VC también tiene /Wall , pero es incompatible con los encabezados estándar.

Elijo tratar las advertencias como errores, porque eso me obliga a solucionarlos. Corrijo todas las advertencias, incluso si eso significa agregar #pragma para ignorar la advertencia; de esa manera, afirmo explícitamente que soy consciente de la advertencia (para que otros desarrolladores no me envíen un correo electrónico al respecto).

Creo que VC también es compatible

 #pragma message ("note to self") 

Pero a medida que el sistema crece y crece, y obtienes una creación nocturna de 30 desarrolladores trabajando simultáneamente, lleva días leer todas las notas para ti mismo, incluso en esa cantidad ese yo no va a hacer nada más que leer y finalmente ir a romper bajo el estrés no ser capaz de mantenerse al día y tener que renunciar …

No, realmente, la cantidad de advertencias crecerá rápidamente si las permite, y no podrá detectar las realmente importantes (variables no inicializadas, este puntero utilizado en el constructor, …).

Es por eso que trato de tratar las advertencias como errores: la mayoría de las veces, el comstackdor tiene razón al advertirme, y si no lo está, lo doy en el código y lo antepongo

 #pragma warning ( push ) #pragma warning ( 4191 : disable ) // violent code, properly documented #pragma warning ( pop ) 

Acabo de leer que tienen una warning ( N : suppress ) pragma, también.

-Wall a usar -Wall (porque todo el mundo -Wall errores, nadie es perfecto), pero no uso -Werror (trata las advertencias como errores) porque de vez en cuando gcc advierte sobre cosas que de todos modos son correctas (falsos positivos).

Estoy de acuerdo con litb para usar siempre -Wall. Además, si quiere asegurarse de que su código sea compatible también puede usar -pedantic. Otra advertencia que puede ser útil si está manipulando uniones y estructuras en el nivel de bytes es -Wpadded.

Hago todo el desarrollo con Advertencia a medida que los errores se activan.

Como todavía desarrollo en VC6 tengo un montón de # pragma en mi código (4786 principalmente).

Hay una buena lista de opciones para GCC aquí: http://mces.blogspot.com/2008/12/year-end-cleaning-ie-on-warning-options.htm . -Wall no habilita todas las advertencias posibles, y algunas tienen que estar habilitadas explícitamente.

Me gustan los prototipos de pared y estrictos, así como las definiciones de funciones implícitas. Los errores en esos pueden ser muy útiles. También hay -Wextra que recogerá todo tipo de cosas, como las que pretendías ser condicionales, pero que accidentalmente escribieron como enunciados:

 if (something); classic_way_to_leak_memory(); 

En los sistemas tipo Unix, debe obedecer las preferencias ENV del usuario … para que lo que vean e informen sea completamente diferente de lo que necesitan 🙂

También soy un demonio de los tipos, así que tiendo a establecer -Fno-strict-aliasing también, a menos que el usuario lo quiera. La gestión de memoria segura en el clásico C es difícil de lograr de lo contrario.

En GCC, prefiero usar -Wall -Wextra -Wwrite-strings -Werror , y también especificar un estándar con std= . Qué estándar depende del proyecto: principalmente sobre qué tan portátil debe ser.

La razón por la que utilizo -Werror es que las advertencias son inaceptables (para mí) incluso si no representan un error real. Prefiero trabajar con lo que sea que haya causado la advertencia, que tener que ignorar las advertencias cada vez que compilo por el rest de mi vida. Una vez que permite las advertencias en la comstackción, es demasiado fácil perder una que no estaba allí la última vez.

Por supuesto, cuando se trata de código de terceros, a veces no puede deshacerse de las advertencias. Luego decidiría caso por caso si relajar las opciones -W , eliminar -Werror y escribir un script para verificar que solo ocurran las advertencias, o tal vez modificar el código de terceros (ya sea para “arreglarlo”) la advertencia o desactivarlo con pragmas si es posible).

En Visual CI use / w3. Encuentro que w4 arroja demasiado ruido (muchos de ellos de las librerías de MS) para revisar cada comstackción. Las advertencias adicionales son muy menores y hasta ahora no han sido la causa de un error.

nadie ha mencionado aún el comstackdor de Intel:

https://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-D060680A-1A18-4574-8291-5C74E6E31335.htm

-w3 es bastante hablador, entonces sugeriría -w2

También me gusta comprobar todas las advertencias posibles que dan el comstackdor en mi proyecto. Desafortunadamente, la respuesta sobre el comstackdor Intel C ++ no fue muy informativa para mí (el enlace está muerto). Hice mi propia investigación.

Como utilizo Qt 5 y qmake tengo un nivel de advertencia predefinido -w1 . No puedo hacer nada con eso. Pero esto no es todo e ICC tiene más claves:

 -Wcomment -Weffc++ -Wextra-tokens -Wformat -Winline // don't use, show only for example -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnon-virtual-dtor -Wp64 -Wpointer-arith -Wremarks -Wreturn-type -Wsign-compare -Wstrict-aliasing -Wstrict-prototypes -Wtrigraphs -Wuninitialized -Wunknown-pragmas -Wunused-variable 

Más sobre todas las llaves .

También quiero agregar que, a diferencia de GCC, ICC produce varias advertencias para una clave, por ejemplo, clave -Weffc ++ . En caso de que solo desee ver varias advertencias de todas las listas use la tecla -wd .

Desactivo: -wd1418,2012,2015,2017,2022,2013 . Y las advertencias -WD1572,873,2259,2261 se desactivaron en qmake de forma predeterminada.

Uso PCH y encuentro muy molesto ver en los mensajes de Qt Creator sobre el uso de un archivo PCH como un error. Para deshabilitar, use -Wno-pch-messages .

Para desactivar la advertencia en el código, uso:

 #if defined(Q_CC_INTEL) #pragma warning( push ) #pragma warning( disable: 2021 ) #endif // some code #if defined(Q_CC_INTEL) #pragma warning( pop ) #endif 

Gracias a todos por sus respuestas. Ha pasado un tiempo desde que utilicé algo más que gcc / g ++. Los que he tenido que usar hace mucho tiempo son

 -fmessage-length = 0 (ya que g ++ tenía un feo hábito de mensajes de salto de línea)

 -No estoy en desuso (ya que trabajé en una base de código preexistente al espacio de nombres estándar)

Recuerdo que (hace al menos 5 años) cualquier cosa por encima del nivel de advertencia predeterminado en el comstackdor Sun Workshop CC era demasiado. También creo que esto puede haber sido cierto para el comstackdor de Intel. No he estado al día con comstackdores non gnu por un tiempo.

Los comstackdores de GCC se vuelven más estrictos con cada nueva versión. Use el -ansi para producir advertencias por violaciones de la interpretación más estricta de los estándares de lenguaje ANSI. Suele ser algo que funciona en el comstackdor actual, pero puede producir errores en la próxima versión o en otros comstackdores. Esa bandera lo ayudará a evitar tener que portar su código cada vez que cambie comstackdores / versiones.