2012-06-06 12 views
13

Sé que las aserciones se pueden habilitar/deshabilitar en el tiempo de ejecución para la depuración y la producción, respectivamente. Sin embargo, encontré que las aserciones también aumentan el tamaño del binario generado (alrededor de 100-200 bytes en el ejemplo a continuación).Compilación sin aserciones

En C y C++, podemos hacer esto en tiempo de compilación teniendo #define NDEBUG antes de #include <assert.h>.

¿Hay alguna manera para que el compilador Java haga esto automáticamente? Me gustaría dejarlos en el código fuente para depuración más adelante. Pero tampoco quiero que el binario resultante sea más grande de lo necesario (tenemos un límite de tamaño como requisito de diseño).

código C:

//#define NDEBUG 
#include <assert.h> 

int main(void) { 
    assert(0); // +200 bytes without NDEBUG, 0 with NDEBUG 
    return 0; 
} 

código Java:.

public class Test { 
    public static void main(String[] args) { 
     assert(System.nanoTime()==0); // increases binary size by about 200 bytes 
    } 
} 

En respuesta a bn de respuesta:

public class Test2 { 
    public static final boolean assertions = false; 

    public static void main(String[] args) { 
     if(assertions) { 
      assert(System.nanoTime()==0); 
     } 
    } 
} 

EDIT: De hecho, parece para mí que esta habilitación/deshabilitación es un compile-tim más útil e característica que en tiempo de ejecución. Quiero decir, ¿cuántos usuarios finales los habilitarán? En cuanto a un programador se refiere durante el proceso de depuración, es probable que recompile el código de todos modos.

+0

Eso no prueba que cada afirmación tenga un costo de 200 bytes, solo que sí. – EJP

+1

@EJP: Seguro.Lo que quise decir es que hay un aumento no despreciable causado por aseveraciones como un todo. La cantidad exacta ciertamente depende de la complejidad de la declaración. – tskuzzy

+1

Si te molestas con tales cosas, estás con el idioma equivocado. – lvella

Respuesta

2

Personalmente no haría lo siguiente debido a la complejidad añadida al código fuente pero javac genera el mismo código intermedio exacto para main en los dos fragmentos siguientes:

condicional afirma

class C { 
    public final static boolean assertions = false; 

    public static void main(String[] args) { 
     if(assertions) { 
      assert(System.nanoTime()==0); 
     } 
    } 
} 

sin afirma

class C { 
    public static void main(String[] args) { 
    } 
} 

código compilado

public static void main(java.lang.String[]); 
    Code: 
     0: return   
    LineNumberTable: 
     line 3: 0 

EDITAR

De hecho, me parece que esta activación/desactivación es una característica en tiempo de compilación más útil que el tiempo de gestión. Quiero decir, ¿cuántos usuarios finales los habilitarán ?

No es el usuario final quien lo habilita, es la asistencia al cliente la que le indica al usuario final que lo habilite. Desearía que estuvieran habilitados, no deshabilitados, por defecto.

+0

¡Perfecto gracias! Estoy de acuerdo en que no es una solución muy elegante pero responde a mi pregunta. – tskuzzy

+0

Parece que si coloca su variable 'public final static static boolean assertions = false;' en una clase separada, de modo que pueda usar las afirmaciones sobre su código y simplemente cambiar la bandera en un lugar, necesitará recompilar la totalidad fuente si eso se cambia (y eso es deseable, ya que quiere borrar la variable de su código compilado). – lvella

+0

@Ivella esto se debe a que el compilador incluye finales públicos estáticos. –

4

Esto no es posible como un paso de compilación incorporado. Sin embargo, puede hacerlo agregando bloques condicionales alrededor de sus afirmaciones.

Consulte el artículo "Removing all Trace of Assertions from Class Files" para obtener más información.

+0

Suena como una buena idea, pero en realidad aumentó el binario aún más en otros 50 bytes. – tskuzzy

+0

Eso no tiene mucho sentido ya que el compilador debería eliminar las declaraciones por completo ya que ahora no está disponible. – Robin

+2

@Robin si OP usa 'final' reducirá el tamaño. –

Cuestiones relacionadas