C++11 introdujo std::unique_ptr y std::shared_ptr para reemplazar el inseguro std::auto_ptr. Ambos admiten desasignadores personalizados para gestionar recursos que no son de memoria, como manejadores de archivos o conexiones a bases de datos. Sin embargo, sus enfoques arquitectónicos difieren fundamentalmente debido a sus modelos de propiedad y requisitos de rendimiento.
std::unique_ptr implementa propiedad exclusiva y almacena su desasignador como parte de su tipo (el segundo parámetro de plantilla). Si el desasignador tiene estado, ocupa espacio dentro del objeto unique_ptr junto con el puntero gestionado. std::shared_ptr implementa propiedad compartida a través de un bloque de control asignado en el heap, donde el desasignador está borrado de tipo y se almacena por separado del objeto shared_ptr.
Esta diferencia arquitectónica conduce a características de tamaño distintas. Un std::unique_ptr con un desasignador sin estado ocupa exactamente el mismo espacio que un puntero crudo gracias a la Optimización de Base Vacía. Por el contrario, std::shared_ptr mantiene un tamaño constante (típicamente dos punteros) independientemente del tamaño o complejidad del desasignador, porque el desasignador reside en el bloque de control asignado por separado.
#include <memory> #include <cstdio> #include <iostream> struct FileDeleter { void operator()(FILE* fp) const { if (fp) std::fclose(fp); } }; struct StatefulDeleter { int flags = 0xDEAD; void operator()(FILE* fp) const { if (fp) std::fclose(fp); } }; int main() { // unique_ptr con desasignador sin estado: tamaño == tamaño del puntero (8 bytes en 64 bits) std::unique_ptr<FILE, FileDeleter> up(nullptr); // shared_ptr: tamaño constante (16 bytes) independientemente del desasignador std::shared_ptr<FILE> sp(nullptr, FileDeleter{}); std::cout << "Único (sin estado): " << sizeof(up) << " bytes "; std::cout << "Compartido (cualquier desasignador): " << sizeof(sp) << " bytes "; // unique_ptr con desasignador con estado: tamaño mayor (16 bytes: puntero + int + relleno) std::unique_ptr<FILE, StatefulDeleter> up2(nullptr, StatefulDeleter{}); std::shared_ptr<FILE> sp2(nullptr, StatefulDeleter{}); std::cout << "Único (con estado): " << sizeof(up2) << " bytes "; std::cout << "Compartido (con estado): " << sizeof(sp2) << " bytes "; }
Un equipo de desarrollo necesitaba gestionar manejadores de conexión a bases de datos heredadas (void*) devueltos por una API C. Estos manejadores requerían limpieza específica a través de db_disconnect() en lugar de delete. La aplicación creó miles de manejadores por segundo en bucles apretados, lo que hacía crítico el tamaño de la memoria y el rendimiento de asignación.
El primer enfoque considerado fue una clase envoltura RAII personalizada ConnectionGuard que almacenaba el manejador y llamaba a db_disconnect() en su destructor. Las ventajas incluían el control total sobre la interfaz y la capacidad de agregar métodos específicos de conexión. Las desventajas incluían un código de plantillas significativo para cada tipo de recurso, la reinvención de la semántica de punteros, y la incompatibilidad con los algoritmos de la biblioteca estándar diseñados para punteros inteligentes.
La segunda solución utilizó std::shared_ptr<void> con un desasignador lambda capturando la función de desconexión. Las ventajas incluían disponibilidad inmediata usando componentes estándar y la capacidad de compartir propiedad si fuera necesario. Las desventajas incluían la asignación obligatoria de heap para el bloque de control, la sobrecarga de conteo de referencia atómico inadecuada para la propiedad única de alta frecuencia, y un tamaño de objeto fijo de 16 bytes independientemente de la naturaleza ligera del manejador.
El tercer enfoque empleó std::unique_ptr<void, decltype(&db_disconnect)> con un desasignador de puntero a función, o preferiblemente un functor sin estado. Las ventajas incluían cero sobrecarga al usar functors sin estado gracias a la Optimización de Base Vacía (igualando el tamaño del puntero crudo de 8 bytes), sin asignaciones de heap y expresión perfecta de la semántica de propiedad exclusiva. Las desventajas incluían la verbosidad de la firma de tipo y la incapacidad de cambiar desasignadores en tiempo de ejecución.
El equipo seleccionó la tercera solución con un desasignador de functor sin estado. Esta elección eliminó completamente las asignaciones de heap, redujo el tamaño del envoltorio a 8 bytes y eliminó la sobrecarga de operaciones atómicas mientras mantenía la limpieza automática.
El resultado fue una reducción del 40% en el uso de memoria y mejoras significativas en la latencia del sistema de agrupamiento de conexiones, logrando seguridad ante excepciones sin comprometer el rendimiento.
¿Por qué std::unique_ptr requiere un tipo completo en el momento de la destrucción al usar el desasignador predeterminado, mientras que std::shared_ptr no?
Respuesta: std::unique_ptr con el desasignador predeterminado llama a delete en el puntero gestionado. El estándar de C++ requiere que delete en un puntero a T tenga T definido como un tipo completo para invocar el destructor y calcular el tamaño para la desasignación. Si el destructor de unique_ptr se instancia donde T solo está declarado por adelantado, la compilación falla. std::shared_ptr captura el desasignador (que sabe cómo destruir T) en el momento de construcción en el bloque de control. Dado que el desasignador está borrado de tipo y se almacena por separado, shared_ptr puede ser destruido más tarde donde T es incompleto. Esta distinción es crucial para el idiom Pimpl (Puntero a Implementación): shared_ptr permite ocultar detalles de implementación en archivos fuente, mientras que unique_ptr requiere tipos completos o desasignadores personalizados explícitos definidos donde la implementación es visible.
¿Por qué std::make_unique no admite desasignadores personalizados, y cuál es la alternativa recomendada?
Respuesta: std::make_unique (introducido en C++14) proporciona asignación segura ante excepciones pero solo devuelve std::unique_ptr<T> o std::unique_ptr<T[]>, que utilizan std::default_delete. La función no puede deducir el tipo de desasignador a partir de los argumentos porque el tipo del desasignador debe ser parte de la firma de plantilla de unique_ptr, y las funciones de fábrica no pueden deducir implícitamente tipos de desasignadores personalizados sin parámetros de plantilla explícitos. La alternativa recomendada es la construcción directa: std::unique_ptr<T, CustomDeleter>(new T(args), CustomDeleter{...}). Este enfoque especifica explícitamente el tipo de desasignador en la plantilla mientras permite una lógica de limpieza de recursos personalizada, aunque requiere manejo de excepciones manual o un orden de construcción cuidadoso para mantener las garantías de seguridad ante excepciones.
¿Cómo afecta la Optimización de Base Vacía el diseño de memoria de std::unique_ptr al usar desasignadores sin estado, y por qué esto no está disponible para std::shared_ptr?
Respuesta: std::unique_ptr hereda de su clase desasignadora cuando el desasignador es de tipo clase. Si el desasignador no contiene miembros de datos (sin estado), C++ aplica la Optimización de Base Vacía (EBO), permitiendo que el subobjeto de base vacío ocupe cero bytes. En consecuencia, sizeof(std::unique_ptr<T, StatelessDeleter>) es igual a sizeof(T*), logrando una abstracción sin sobrecarga. std::shared_ptr no puede utilizar EBO porque debe admitir el borrado de tipos: cualquier shared_ptr del mismo T debe tener el mismo tamaño independientemente del desasignador. Por lo tanto, shared_ptr almacena el desasignador en el bloque de control asignado en el heap en lugar de dentro del objeto shared_ptr. Este diseño permite la polimorfismo en tiempo de ejecución de los desasignadores, pero obliga a una asignación en el heap y evita la optimización del espacio de pila que disfruta unique_ptr.