Considere el siguiente constructor que inicializa la variable miembro x_ usando una lista de inicialización: Fred::Fred(): x_ (lo_que_sea) { } El beneficio de hacerlo es mejorar el rendimiento. Por ejemplo, si la expresión lo_que_sea es del mismo tipo que la variable miembro x_, el resultado de la expresión es asignado directamente a x_ -el compilador no hace una copia separada del objeto. Incluso si los tipos no son los mismos, el compilador suele ser capaz de hacer un mejor trabajo con listas de inicialización que con las asignaciones.
La otra manera (ineficiente) de declarar constructores es a través de asignación, por ejemplo: Fred::Fred () {x_ = lo_que_sea;} En este caso la expresión lo_que_sea hace que se cree un objeto temporal, y este objeto temporal es pasado al objeto x_ mediante el operador de asignación. Luego, ese objeto temporal es destruido despues del punto y coma (;). Eso es ineficiente.
Como si eso no fuera suficiente, hay otra fuente de ineficiencia cuando se utiliza asignación en un constructor: el objeto miembro estará completamente "construido" por su constructor por defecto, y esto podría, por ejemplo, asignar una cierta cantidad predeterminada de memoria o abrir algún archivo por defecto. Todo este trabajo podría ser en vano si el cualquier expresión y/o operador de asignación hace que el objeto cierre el archivo y/o libere la memoria (por ejemplo, si el constructor por defecto no asignó suficientemente memoria o si abre el archivo incorrecto).
Conclusión: Todas las cosas en igualdad de condiciones, el código se ejecutará más rápido si se utilizan listas de inicialización en lugar de asignación.
Nota: No hay diferencia de rendimiento si el tipo de dato x_ es cierto tipo de dato incorporado o tipo intrínseco de dato, como int, char * o float. Pero incluso en estos casos, prefiero establecer los datos miembro en la lista de inicialización en lugar de la asignación, para que sea consistente. Otro argumento similar en favor del uso de las listas de inicialización, incluso para los tipos de datos incorporados/intrínsecos: const no estáticos y referencias no estáticas de variables miembro no se pueden asignarles un valor en el constructor, por lo que la simetría tiene sentido para inicializar todo en la lista de inicialización.
Ahora para las excepciones. Todas las reglas tienen excepciones, hay un par de excepciones a las reglas de "listas de inicialización". En el fondo es usar el sentido común: si es menos costoso para el procesador, mejor, más rápido, etc., mejor no usarlos, por todos los medios, no los use. Esto puede ocurrir cuando la clase tiene dos constructores que necesitan inicializar los datos miembro del objeto this en diferentes etapas. O puede ocurrir cuando dos miembros de datos son auto-referenciados. O cuando un dato miembro necesita una referencia al objeto this, y quiere evitar una advertencia del compilador sobre el uso de la palabra clave this antes de la llave ({) con el que comienza el cuerpo del constructor (cuando su compilador, emite esta advertencia en particular). O cuando lo que necesita es hacer un if/throw en una variable (parámetro global, etc) antes de usar esa variable para inicializar uno de sus miembros de this. Esta lista no es exhaustiva, por favor no me escriba pidiéndome que añada otro "O cuando ...". El punto es simplemente este: usar el sentido común.
<< Regresar a Constructores
Tomado de C++ FAQ Lite, traducido por ivancp
...
