programacion - Argumento predeterminado vs sobrecargas en C++

programacion con funciones c++

Question

Por ejemplo, en lugar de

void shared_ptr::reset() noexcept;
template <typename Y>
void shared_ptr::reset(Y* ptr);

uno puede pensar en

template <typename Y = T>
void shared_ptr::reset(Y* ptr = nullptr);

Creo que la diferencia de rendimiento es despreciable aquí, y la segunda versión es más concisa. ¿Hay alguna razón específica por la cual el estándar de C ++ sea el primero?

Se ha formulado la misma pregunta para el idioma de Kotlin, y se prefiere el argumento predeterminado allí.

Actualizar:

std::unique_ptr::reset() sigue el diseño del argumento predeterminado (vea here ). Así que creo que la razón por la cual std::shared_ptr::reset() usa sobrecargas es porque tienen diferentes especificaciones de excepción.

Answer 1

Hay una diferencia fundamental entre una sobrecarga y un puntero predeterminado:

• la sobrecarga es autónoma: el código de la biblioteca es completamente independiente del contexto de llamada.
• el parámetro predeterminado no es autónomo, sino que depende de la declaración utilizada en el contexto de la llamada. Se puede redefinir en un ámbito dado con una declaración simple (por ejemplo, un valor predeterminado diferente o ya no hay un valor predeterminado).

Hablando semánticamente, el valor predeterminado es un atajo incrustado en el código de llamada, mientras que la sobrecarga es un significado incrustado en el código llamado.

Answer 2

La diferencia crucial, es que las dos operaciones, de hecho, no son semánticamente iguales.

El primero significa dejar el shared_ptr sin un objeto gestionado. El segundo está destinado a tener el puntero gestionar otro objeto. Esa es una distinción importante. Implementarlo en una sola función significaría que esencialmente tendremos una función que realice dos operaciones diferentes.

Además, cada operación puede tener diferentes restricciones en los tipos en cuestión. Si los volcamos en una función, entonces "ambas ramas" tendrán que satisfacer las mismas restricciones, y eso es innecesariamente restrictivo. C ++ 17 y constexpr if mitigan, pero esas funciones se especificaron antes de que se cerrara.

En última instancia, creo que este diseño está en línea con el consejo de Scott Meyers. Si el argumento predeterminado te hace hacer algo semánticamente diferente, probablemente debería ser otra sobrecarga.

De acuerdo, para abordar su edición. Sí, las especificaciones de excepción son diferentes. Pero como mencioné anteriormente, la razón por la que pueden ser diferentes es que las funciones están haciendo cosas diferentes. La semántica de los miembros de reset requiere esto:

void reset() noexcept;

Efectos : Equivalente a shared_ptr().swap(*this) .

template<class Y> void reset(Y* p);

Efectos : Equivalente a shared_ptr(p).swap(*this) .

No hay una gran noticia de última hora allí. Cada función tiene el efecto de construir un nuevo shared_ptr con el argumento dado (o falta del mismo), y el intercambio. Entonces, ¿qué hacen los constructores shared_ptr ? Según una sección anterior , hacen esto:

constexpr shared_ptr() noexcept;

Efectos : construye un objeto shared_ptr vacío.
Condiciones posteriores : use_count() == 0 && get() == nullptr .

template<class Y> explicit shared_ptr(Y* p);

Postcondiciones : use_count() == 1 && get() == p . Emite : bad_alloc , o una excepción definida por la implementación cuando no se pudo obtener un recurso que no sea la memoria

Tenga en cuenta las diferentes condiciones de publicación en el uso de puntero. Eso significa que la segunda sobrecarga debe tener en cuenta cualquier contabilidad interna. Y muy probablemente asigne almacenamiento para ello. Los dos constructores sobrecargados hacen cosas diferentes, y como dije anteriormente, esa es una sugerencia sólida para separarlos en diferentes funciones. El hecho de que se pueda obtener una garantía de excepción más fuerte es una prueba más de la solidez de esa elección de diseño.

Y finalmente, ¿por qué unique_ptr tiene una sola sobrecarga para ambas acciones? Porque el valor predeterminado no cambia la semántica. Solo tiene que hacer un seguimiento del nuevo valor del puntero. El hecho de que el valor sea nulo (ya sea por el argumento predeterminado o no) no cambia el comportamiento de la función drásticamente. Una sola sobrecarga es por lo tanto sana.

Answer 3

Si a menudo está restableciendo a nullptr precisamente en lugar de un nuevo valor, la función separada void shared_ptr::reset() noexcept; tendrá una ventaja de espacio, ya que puede usar una función para todos los tipos Y , en lugar de tener una función específica que tome un tipo Y para cada tipo de Y Otra ventaja de espacio es que la implementación sin un argumento no necesita un argumento pasado a la función.

Por supuesto, tampoco importa mucho si la función se llama muchas veces.

También hay una diferencia en el comportamiento de excepción, que puede ser muy importante, y creo que esta es la motivación de por qué el estándar tiene múltiples declaraciones de esta función.

Answer 4

Si bien las opciones de diseño de las otras respuestas son todas válidas, asumen una cosa que no se aplica completamente aquí: ¡Equivalencia semántica!

void shared_ptr::reset() noexcept;
                      // ^^^^^^^^
template <typename Y>
void shared_ptr::reset(Y* ptr);

La primera sobrecarga es noexcept , mientras que la segunda sobrecarga no lo es. No hay manera de decidir la noexcept función del valor de tiempo de ejecución del argumento, por lo que se necesitan las diferentes sobrecargas.

Parte de la información de fondo sobre el motivo de las diferentes especificaciones de noexcept : reset() no se lanza, ya que se supone que el destructor del objeto previamente contenido no se lanza. Pero la segunda sobrecarga podría necesitar además asignar un nuevo bloque de control para el estado del puntero compartido, que lanzará std::bad_alloc si la asignación falla. (Y el reset ting a un nullptr se puede hacer sin asignar un bloque de control).