2010-03-05 31 views
28

Tengo un proyecto de prueba de unidad basado en UnitTest ++. Yo suelo poner un punto de interrupción a la última línea del código para que el que pueda inspeccionar la consola cuando una de las pruebas falla:Visual Studio: ¿puede ser un punto de interrupción llamado desde el código?

n = UnitTest::RunAllTests(); 
    if (n != 0) 
    { 
    // place breakpoint here  
    return n; 
    } 
    return n; 

Pero tengo que vuelva a introducirla cada vez que Check-Out el código de nuevo de SVN. ¿Es posible colocar un tanto el punto de interrupción por el compilador ?:

 n = UnitTest::RunAllTests(); 
     if (n != 0) 
     { 
     // place breakpoint here  
#ifdef __MSVC__ 
     @!!!$$$??___BREAKPOINT; 
#endif 
     return n; 
     } 
     return n; 
+0

¿Pueden cambiar la Question- ¿Título? Esto no es solo un problema de Visual Studio, sino que también es interesante para otros compiladores. – MaBe

Respuesta

50

Utilice __debugbreak() intrinsic (requiere la inclusión de <intrin.h>).

El uso de __debugbreak() es preferible a escribir directamente __asm { int 3 } ya que no se permite el ensamblaje en línea al compilar el código para la arquitectura x64.

Y para el registro, en Linux y Mac, con GCC, estoy usando __builtin_trap().

+1

Tal vez me falta algo, pero es '__debugbreak()' - sin subrayado en el medio. – NPS

+0

de hecho! gracias por informar el error tipográfico –

+0

Gracias! Esto funciona para mingw también. – MaBe

0

¿Cómo sobre el uso de un método de depuración o de seguimiento a la salida de la información de la consola. Ese puede ser un mejor enfoque que confiar en puntos de corte.

+0

El marco UnitTest ++ realiza la salida. Inserto declaraciones como CHECK (pi <4); y si pi es 31, el marco imprime el error. Hay como 500 pruebas y el número está creciendo. Por lo general, no fallan. – danatel

0

¿Con qué frecuencia revisa el proyecto desde SVN? Esto es algo que solo hago una vez por proyecto o cuando reconstruyo mi PC.

Si también registra los archivos del proyecto, los puntos de interrupción deben almacenarse en los archivos del proyecto.

Creo que está en el archivo .suo. También podría poner eso bajo control SVN si quisiera, aunque prefiero no hacerlo.

+0

Siempre que sea posible, asegúrese de que todos los archivos nuevos se hayan agregado antes de la confirmación y que no falten las dependencias. También es bueno tener directorios antiguos de compilación en el disco para tener acceso rápido a las versiones anteriores de los binarios. – danatel

+0

Buen punto. También hacemos compilaciones de prueba de humo y eso no se me ocurrió. – codenheim

18
DebugBreak(void) 

De Winbase.h.

MSDN

+1

Me gustaría agregar esta [cita de MSDN] (https://msdn.microsoft.com/en-us/library/ea9yy3ey.aspx) con respecto a la diferencia entre 'DebugBreak' y' __debugbreak': _Porque DebugBreak es una llamar a una función del sistema, los símbolos de depuración del sistema deben estar instalados para garantizar que se muestre la información correcta de la pila de llamadas después del corte. De lo contrario, la información de la pila de llamadas mostrada por el depurador puede estar desactivada en un cuadro. Si utiliza __debugbreak, los símbolos no son obligatorios. –

7

Usted podría utilizar esto en C o C++

__asm 
{ 
    int 3 
} 
+1

solo funciona para x86, ya que el compilador no le permite escribir ensambles en línea para x64 –

+0

+1 Devuelve recuerdos. – Robert

3

Si está utilizando VC6 (sí, anticuado, pero todavía en uso en algunos lugares/proyectos), DebugBreak() funcionará pero puede terminan en una ubicación oscura y profunda con las DLL de Windows, desde donde tienes que volver a subir la pila en tu código.

Es por eso que estoy usando ASSERT() en MFC o assert() en código "estándar".

Su ejemplo sería el siguiente:

n = UnitTest::RunAllTests(); 
ASSERT(n == 0); 
//assert(n == 0); 
return n; 

Si usted no necesita un resultado y lo quiere sólo para la depuración, también se puede hacer

if(0 != UnitTest::RunAllTests()) 
{ 
    ASSERT(FALSE); 
    //assert(false); 
} 
Cuestiones relacionadas