Ayudando a evitar la afirmación ... ¡siempre!

Question

En C y C++ assert es una rutina muy pesada muy, escribiendo un error en stdout y terminando el programa. En nuestra aplicación, hemos implementado un reemplazo mucho más robusto para assert y dado su propio macro. Se ha hecho todo lo posible para reemplazar assert con nuestra macro, sin embargo, todavía hay muchas maneras assert puede reintroducirse (por ejemplo, de bibliotecas internas de terceros, la inyección ingenuo, etc.)

¿Alguna sugerencia sobre cómo podemos reducir, limitar o incluso erradicar los usos de assert? La mejor respuesta será aquella que el compilador pueda captar para nosotros, de modo que no tengamos que cuidar la base de códigos tanto como lo hacemos actualmente.

Answer 1

No estoy seguro de que realmente entiendo el problema, en realidad. Las afirmaciones solo son costosas si se apagan, lo cual está bien de todos modos, ya que ahora se encuentra en una situación de excepción.

assert solo está habilitado en compilaciones de depuración, por lo tanto, utilice la compilación de lanzamiento de una biblioteca de terceros. Pero en realidad, las afirmaciones no deberían irse en todo momento.

Answer 2

El enfoque más obvio parece ser dar su propia versión de afirmar su propio nombre, ligeramente diferente de assert(). Luego puede buscar el texto, ver los mensajes del vinculador, etc., para la cadena literal "_assert" y sabe que tiene un problema cuando lo ve.

En mi propio código, siempre uso Assert(), que se expande a mi propia función que realiza una aserción, o se expande a ((void)0) para la compilación de lanzamiento. El compilador convertirá la expresión ((void)0) en nada, pero aún cuenta como una expresión. Por lo tanto

Assert(3 == x); 

se convertirá en

((void)0); 

y el punto y coma tiene un lugar a donde ir.

Por cierto, una vez trabajé en una aplicación de GUI donde la afirmación era un diálogo emergente modal GUI especial. Tuviste tres opciones: Ignorar, Ignorar para siempre o Romper. Ignore ignoraría la afirmación y seguiría funcionando. Ignorar para siempre establecería un indicador, y hasta que haya reiniciado el programa en el depurador, esa afirmación ya no se disparará. La ruptura permitiría que la afirmación entre en el depurador.

No recuerdo cómo garantizaban que cada afirmación tuviera su propia bandera. ¿Tal vez cuando escribiste la llamada a Assert() tuviste que especificar un entero único? Sería bueno si fuera más automático que eso. Estoy bastante seguro de que la implementación real era un poco de vector, y establecería el bit cuando elijas ignorar para siempre.

Answer 3

Encuentra assert en las cabeceras de la biblioteca (asumiendo que son archivos reales en el sistema de archivos) y sustituirla por una cosa no válida

// #define assert(condition) ... /* old definition */ 
#define assert(condition) ((condition) & "PLEASE DO NOT USE ASSERT" = 42) 

Answer 4

assert() es generalmente #define 'd ser ((void)0) for release code (#define NDEBUG), por lo hay sin gastos generales.

Al usar una versión de prueba, ¿está afectando el rendimiento general a su capacidad para que las pruebas sean realistas?

Answer 5

Si el código fuente está bajo su control:

#define NDEBUG 
// Before 
#include <assert.h> 
// Or other header that includes assert.h 

o el uso de encabezado precompilado o compilar opciones para definir NDEBUG.

Para los archivos binarios de terceros, utilice la versión de lanzamiento de los mismos.

Answer 6

Dependería (al menos en parte) de lo que está cambiando. Suponiendo que no le importe imprimir su mensaje normal, y sobre todo quiere deshacerse de él llamando al abort(), puede considerar dejar solo assert() y, en su lugar, definir su propia versión de abort().

En teoría, hacer eso no es portátil, pero en realidad, abort() es una función bastante normal en la biblioteca estándar, y si enlaza la suya en su lugar, obtiene su comportamiento. A veces (especialmente algunos vinculadores de Microsoft) tiene que hacer un poco de trabajo para que el enlazador coopere en el reemplazo de su abort() con el suyo, pero rara vez es muy difícil.

Answer 7

Puede ser útil mejorar la función de aserción incorporada (para proporcionar rastreos de pila, volcados de núcleo, quién sabe). En ese caso, si tiene problemas para que sus desarrolladores sigan los estándares que tenga (como "en lugar de assert() use SUPER_ASSERT()" o lo que sea), puede simplemente poner su propio encabezado assert.h en la ruta de inclusión antes del directorio de tiempo de ejecución del compilador de encabezados.

Eso garantizará que cualquier persona que use la macro estándar assert() obtendrá un error de compilación u obtendrá su funcionalidad de aserción (dependiendo de lo que tenga su encabezado assert.h).

Answer 8

Parece que se está perdiendo el hecho de que el código de terceros probablemente se haya escrito bajo la suposición de comportamiento "estándar" de assert. Es decir. el código espera que el programa finalice en una afirmación fallida. El código que sigue a la aserción normalmente no puede y no funcionará correctamente si la condición afirmada está rota. En 99 casos de cada 100, no funcionará en absoluto. En 99 casos de cada 100, simplemente se bloqueará, es decir, el programa terminará de todos modos.

para creer que reemplazando el comportamiento assert de código de terceros de alguna manera va a hacer el programa en vivo ya es ingenua en el mejor.

Answer 9

Creo que su pregunta es totalmente válida. Si ha implementado su propio manejo de errores, es posible que desee:

1. Activar siempre las afirmaciones incluso en compilaciones de versiones.
2. Implementa mejores informes de errores en caso de que se active una afirmación. Es posible que desee enviar informes de errores o escribir en archivos de registro.

Habiendo dicho eso, no veo ninguna solución que siempre funcione.

• Si tiene suerte, las bibliotecas de terceros utilizar macros afirmar que puede volver a definir por sí mismo siempre que el archivo de definición de esta macro tiene algún tipo de #pragma once o #ifndef __HEADERFILE_H__ #define __HEADERFILE_H__ disposición contra la inclusión múltiple. Incluye el archivo de cabecera por separado, redefinir ASSERT y estás bien.

• Si incluyen directamente assert.h o cassert, solo se puede parchar el código, supongo. Realice cambios mínimos de código, guarde los cambios como archivos de parche y cuando actualice la biblioteca, tenga la esperanza de que los parches aún funcionen. Agregue los parches al control de versiones.

Si esto no funciona, vuelva a plantear la cuestión si realmente necesita afirmaciones internas en bibliotecas de terceros. Solo se crean construcciones de lanzamiento, esto elimina las afirmaciones y agrega tus ASSERT para verificar la corrección dentro de tu código. Verifique la validez de los valores de devolución. Si se activa un ASSERT de este tipo, aún puede sumergirse en el código de terceros para ver qué causó el problema.

Answer 10

Creo que la pregunta es válida.

Mi propia afirmación se expande a asm ("int3") si se activa, lo que es equivalente a un punto de interrupción. También encontré que es mucho más útil para la depuración que una simple terminación.

Simplemente lo llamé "ASSERT()" en lugar del normal "assert()" y evité el uso de assert() en absoluto.