2010-07-06 9 views
6

¿Hay algún mecanismo en D (D2) para obligar a compilar el código durante una compilación de versión?Compila el código para la compilación de versión en D

En C, es posible que tenga algo así como

#ifndef NDEBUG 
/*Something that will only run in a debug build*/ 
#endif 

sé que D tiene

debug(mymodule) { 
    //Do something 
} 

Pero esto requiere que el usuario pase -debug para cada módulo para activarlo.

Estoy buscando un mecanismo global que siempre ejecute el código en una compilación normal, pero compílelo cuando pase el indicador de liberación. Sé que algunas incorporaciones tienen esta capacidad (por ejemplo, afirmar), pero ¿hay alguna forma de que el código de usuario también lo haga?

+1

Creo que parte del problema es que '' debug' y -release' no tienen nada que ver unos con otros en D. '-release' implica que se está compilando una versión de lanzamiento e inhabilita varias comprobaciones (como aserciones). '-debug' habilita las instrucciones de depuración. Como tal, podría argumentar que no hay realmente un "modo de depuración" en D. Tiene modo de liberación y modo sin liberación con la capacidad de habilitar sentencias de depuración en cualquier modo. No creo que '-release' se suponga que realmente cambie la semántica de tu código como' -debug', por lo que es probable que no puedas hacer lo que intentas hacer. –

+0

No estoy buscando cambiar la semántica para la compilación de lanzamiento. Solo busco la mejor manera de agregar cheques, impresiones, etc. adicionales en una compilación no liberada que estará siempre activa durante el desarrollo. Lo veo como algo para darle a un desarrollador que rastree problemas más rápidamente. Las comprobaciones y advertencias adicionales pueden darles una pista sobre los módulos que deberían habilitar -debug on. – JRM

+1

He dado una respuesta, pero de alguna manera, me siento mal por eso. Recomiendo solo usar -debug cuando devolve y 'debug {// ...}'. Es mejor hacer que sea fácil cometer errores al enviar, que al soltar, en mi humilde opinión. – 0scar

Respuesta

15

Existe una noción global de depuración. Sólo tiene que escribir:

debug { 
    ... code ... 
} 
+1

Sabía que tenía que haber algo simple como esto. El Lenguaje de programación D solo mencionaba la depuración específica del módulo, por lo que no me había dado cuenta de que también había una global. Ahora puedo usar debug {...} para la depuración básica y depurar (mymodule) {...} para agregar una depuración más detallada. – JRM

+1

Exactamente. Disculpas por la omisión. He agregado una errata en su nombre aquí: http://www.erdani.com/tdpl/errata/ –

1

Si no se encuentra ninguna respuesta mejor, un hackaround como esto debería funcionar: bool debugMode() { bool res; assert(!!(res = true)); return res; }

+1

No veo cómo funciona eso. – BCS

+2

Eso es asignación dentro de la afirmación. En el modo de lanzamiento, la afirmación y su contenido se compilan. Por lo tanto, la asignación solo tiene lugar en compilaciones no liberables. –

+2

OP está buscando una solución de tiempo de compilación y assert nunca aparece en CTFE. – BCS

3

dmd -release -version=dist module.d

y

version(dist) {} else { 
    int i = 9; 
} 

mejor que se me ocurre.

[Actualización]

personalmente, creo que la respuesta anterior es "malo". La solución anterior introduciría una lógica demasiado compleja en el proceso de lanzamiento, que creo que debería ser directa y predecible. Yo recomendaría simplemente usar -debug y debug{ //... }. Incluso si siente que puede olvidarse de agregar el indicador de depuración cuando está compilando (¡solo está envileciendo!) Los errores son baratos. Los errores que lo convierten en el lanzamiento son peores.

+0

No es tan ideal como esperaba, ya que debe recordar especificar el indicador de conversión, pero esos detalles probablemente puedan ocultarse al usuario final dentro del sistema de compilación, por lo que será suficiente. – JRM

+0

Gracias BCS para la corrección. – 0scar

Cuestiones relacionadas