c++ - utilizo - inicializacion de valores pseudocodigo

¿Qué beneficio hay en dejar que una variable se deje sin inicializar?

Question

En muchos idiomas, puede declarar una variable y usarla antes de inicializarla.

Por ejemplo, en C ++, puede escribir un fragmento como:

int x;
cout << x;

Por supuesto, esto devolvería resultados impredecibles (bueno, a menos que supiera cómo su programa estaba mapeando la memoria), pero mi pregunta es, ¿por qué este comportamiento es permitido por los compiladores?

¿Hay alguna aplicación o eficiencia que resulte de permitir el uso de memoria no inicializada?

editar : Se me ocurrió que dejar la inicialización al usuario minimizaría las escrituras para los medios de memoria que tienen vidas útiles limitadas (ciclos de escritura). Solo un ejemplo específico bajo el encabezado de "rendimiento" antes mencionado. Gracias.

Answer 1

Algunas API están diseñadas para devolver datos a través de variables pasadas, por ejemplo:

bool ok;
int x = convert_to_int(some_string, &ok);

Puede establecer el valor de ''ok'' dentro de la función, por lo que inicializarlo es un desperdicio.

(No defiendo este estilo de API).

Answer 2

Algunos idiomas tienen valores predeterminados para algunos tipos de variables. Dicho esto, dudo que haya beneficios de rendimiento en ningún idioma para no inicializarlos explícitamente. Sin embargo, los inconvenientes son:

• La posibilidad de que se deba inicializar y sin que se haga se corre el riesgo de un bloqueo
• Valores imprevistos
• Falta de claridad y propósito para otros programadores

Mi sugerencia siempre es inicializar sus variables y la consistencia se amortizará sola.

Answer 3

Dependiendo del tamaño de la variable, dejar el valor sin inicializar en nombre del rendimiento puede considerarse una micro-optimización. Relativamente pocos programas (en comparación con la amplia gama de tipos de software que existen) se verían negativamente afectados por los dos o tres ciclos adicionales necesarios para cargar un doble; sin embargo, suponiendo que la variable fuera bastante grande, probablemente sea una buena idea retrasar la inicialización hasta que se requiera una inicialización abundantemente clara.

Answer 4

La excusa más antigua en programación: ¡mejora el rendimiento!

editar: lee tus comentarios y estoy de acuerdo: hace años, el foco en el rendimiento estaba en la cantidad de ciclos de CPU. Mi primer compilador de C era C tradicional (el anterior a ANSI C) y permitía compilar todo tipo de abominaciones. En estos tiempos modernos, el rendimiento se trata de la cantidad de quejas de los clientes. Cuando les digo a los nuevos graduados contratamos: "No me importa qué tan rápido el programa da una respuesta incorrecta". Use todas las herramientas de desarrollo y compiladores modernos, escriba menos errores y todos puedan irse a casa a tiempo.

Answer 5

La respuesta corta es que, para casos más complicados, el compilador puede no ser capaz de determinar si una variable se usa antes de la inicialización o no.

p.ej.

int x;
if (external_function() == 2) {
x = 42;
} else if (another_function() == 3) {
x = 49;
}
yet_another_function( &x );
cout << x; // Is this a use-before-definition?

Los buenos compiladores emitirán un mensaje de advertencia si detectan un error de uso probable antes de la inicialización, pero para casos complejos, especialmente en el caso de varias unidades de compilación, el compilador no tiene forma de saberlo.

En cuanto a si un lenguaje debe permitir el concepto de variables no inicializadas, esa es otra cuestión. C # es un poco inusual al definir cada variable como inicializada con un valor predeterminado. La mayoría de los lenguajes (C ++ / C / BCPL / FORTRAN / Assembler / ...) le dejan al programador si la inicialización es apropiada. Los buenos compiladores a veces pueden detectar inicializaciones innecesarias y eliminarlas, pero esto no es un hecho. Los compiladores para hardware más oscuro tienden a tener menos esfuerzo puesto en la optimización (que es la parte más difícil de la escritura del compilador), por lo que los lenguajes dirigidos a dicho hardware tienden a no requerir la generación innecesaria de código.

Answer 6

Mis pensamientos (y he estado equivocado antes, solo pregúntale a mi esposa) son que es simplemente un remanente de encarnaciones anteriores del lenguaje.

Las primeras versiones de C no te permitían declarar las variables en cualquier lugar que quisieras en una función, tenían que estar en la parte superior (o tal vez al comienzo de un bloque, es difícil recordarlo porque rara vez lo hago). hoy en día).

Además, tiene el deseo comprensible de establecer una variable solo cuando sabe lo que debería ser. No tiene sentido inicializar una variable para algo si lo siguiente que va a hacer con ella es simplemente sobrescribir ese valor (de ahí viene la gente de rendimiento).

Es por eso que es necesario permitir las variables no inicializadas, aunque todavía no debe usarlas antes de inicializarlas, y los buenos compiladores tienen advertencias para informarle al respecto.

En C ++ (y encarnaciones posteriores de C) donde puedes crear tu variable en cualquier lugar de una función, realmente deberías crearla e inicializarla al mismo tiempo. Pero eso no fue posible desde el principio. Tuviste que usar algo como:

int fn(void) {
int x, y;
/* Do some stuff to set y */
x = y + 2;
/* Do some more stuff */
}

Hoy en día, optaría por:

int fn(void) {
int y;
/* Do some stuff to set y */
int x = y + 2;
/* Do some more stuff */
}

Answer 7

Quizás en algunos casos, es más rápido dejar la memoria sin inicializar hasta que se necesite (por ejemplo, si regresa de una función antes de usar una variable). Normalmente inicializo todo de todos modos, dudo que haga una diferencia real en el rendimiento. El compilador tendrá su propia manera de optimizar las inicializaciones inútiles, estoy seguro.

Answer 8

para el estilo de bucle

int i;
for(i=0;i<something;++i){
.......
}
do something with i

y preferiría que el bucle for se viera como for(init;condition;inc)

aquí hay uno con una necesidad absoluta

bool b;
do{
....
b = g();
....
}while(!b);

propiedad horizontal de pantalla horizontal con nombres largos anidados

alcance más duradero para la visibilidad de depuración

muy ocasionalmente rendimiento