Extender una API existente: Uso argumento predeterminado o función de contenedor?

Question

Tengo un método existente (o función en general), que necesito crecer funcionalidad adicional, pero yo no quiero romper cualquier uso del método en la otra parte del código. Ejemplo:

int foo::bar(int x)
{
 // a whole lot of code here
 return 2 * x + 4;
}

se utiliza ampliamente en el código base. Ahora necesito para hacer la 4 en un parámetro, pero cualquier código que ya se llama foo :: bar aún debe recibir lo que espera. Debería ampliar y cambiar el nombre del método antiguo y lo envuelve en una nueva como

int foo::extended_bar(int x, int y)
{
 // ...
 return 2 * x + y;
}

int foo::bar(int x)
{
 return extended_bar(x,4);
}

o debería declarar un argumento por defecto en el archivo de cabecera como

int bar(int x, int y=4);

y simplemente extender la función

int foo::bar(int x, int y)
{
 // ...
 return 2 * x + y;
}

¿Cuáles son las ventajas y desventajas de cada variante?

Answer 1

lo general el uso de un función de contenedor (a través de la sobrecarga de la mayoría del tiempo) en lugar de parámetros por defecto.

La razón es que hay dos niveles de compatibilidad con versiones anteriores

1. Tener a nivel de fuente compatibilidad hacia atrás significa que usted tiene que volver a compilar el código de llamada sin cambios, ya que las nuevas firmas de función son compatibles con los antiguos. Este nivel se puede lograr con ambos; valores por defecto y envoltorios / sobrecarga.

2. Un nivel más fuerte es a nivel binario compatibilidad con versiones anteriores, que funciona incluso sin recompilación, por ejemplo, cuando usted no tiene acceso al código de llamada. Imagine que implementa la función en forma binaria, como en una DLL, etc. En tal caso, las firmas tienen el ser exactamente el mismo para que funcione, lo cual no es el caso para los valores por defecto - van a romper este nivel de compatibilidad .

Otra de las ventajas de funciones de contenedor es - si su aplicación tiene registro de ningún tipo - se puede volcar una advertencia en la función de edad que se convertirá en obsoleto en las versiones futuras y que se recomienda utilizar la nueva

Answer 2

Cuanto más tiempo utilizo C ++, menos me gusta parámetros de la función predeterminada. No puedo precisar ninguna razón específica para mi disgusto, pero me parece que si las uso, casi siempre termino la eliminación de ellos más tarde. Así que mi (subjetiva) voto va para la nueva función llamada -. El nombre podría por supuesto ser el mismo que el de la anterior

Answer 3

Yo personalmente creo que los comportamientos son implícitas (una de) las raíces de todos los males.

Todo lo que ofusca por un mantenedor o persona que llama la identidad del objetivo que se invoca debe tener una justificación muy fuerte, sobre todo si es parte de una API importante.

Por lo tanto, yo diría fuertemente en contra de la opción con el funcionamiento por defecto.

Además, yo creo que si una determinada función se puede activar con un número diferente de parámetros, entonces hay algo inherentemente diferente las dos versiones de la función o que están haciendo demasiado. La distinción, probablemente, debe estar en el nombre, y probablemente debería ser más significativo que "_extended"