Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 218 — #256
✐
Capítulo 7. Sobrecarga de funciones y argumentos por defecto
s2.print(cout);
} ///:~
Todo lo que puede hacer con esta clase es crear un MyString, concatenar texto
e imprimir a un ostream. La clase sólo contiene un puntero a un Mem, pero note
la diferencia entre el constructor por defecto, que pone el puntero a cero, y el segundo
constructor, que crea un Mem y copia los datos dentro del mismo. La ventaja
del constructor por defecto es que puede crear, por ejemplo, un array grande de objetos
MyString vacíos con pocos recursos, pues el tamaño de cada objeto es sólo
un puntero y la única sobrecarga en el rendimiento del constructor por defecto es
el de asignarlo a cero. El coste de un MyString sólo empieza a aumentar cuando
concatena datos; en ese momento el objeto Mem se crea si no ha sido creado todavía.
Sin embargo, si utiliza el constructor por defecto y nunca concatena ningún dato, la
llamada al destructor todavía es segura porque cuando se llama a delete con un
puntero a cero, el compilador no hace nada para no causar problemas.
Si mira los dos constructores, en principio, podría parecer que son candidatos para
utilizar argumentos por defecto. Sin embargo, si elimina el constructor por defecto
y escribe el constructor que queda con un argumento por defecto:
MyString(char* str = "");
todo funcionará correctamente, pero perderá la eficacia anterior pues siempre se
creará el objeto Mem. Para volver a tener la misma eficacia de antes, ha de modificar
el constructor:
MyString::MyString(char* str) {
if (!*str) { // Apunta a un string ívaco
buf = 0;
return;
}
buf = new Mem(strlen(str) + 1);
strcpy((char*)buf->pointer(), str);
}
Esto significa, en efecto, que el valor por defecto es un caso que ha de tratarse separadamente
de un valor que no lo es. Aunque parece algo inocente con un pequeño
constructor como éste, en general esta práctica puede causar problemas. Si tiene que
tratar por separado el valor por defecto en vez de tratarlo como un valor ordinario,
debería ser una pista para que al final se implementen dos funciones diferentes dentro
de una función: una versión para el caso normal y otra para el caso por defecto.
Podría partirlo en dos cuerpos de función diferentes y dejar que el compilador elija.
Esto resulta en un ligero (pero normalmente invisible) incremento de la eficacia porque
el argumento extra no se pasa y por tanto el código extra debido a la condición
condición no se ejecuta. Más importante es que está manteniendo el código en dos
funciones separadas en vez de combinarlas en una utilizando argumentos por defecto,
lo que resultará en un mantenimiento más sencillo, sobre todo si las funciones
son largas.
Por otro lado, considere la clase Mem. Si mira las definiciones de los dos constructores
y las dos funciones pointer(), puede ver que la utilización de argumentos
por defecto en ambos casos no causará que los métodos cambien. Así, la clase podría
ser fácilmente:
218
✐
✐
✐
✐