El requerimiento proviene de las reglas de decadencia de tipo de C++ y la necesidad de selección de eliminador en tiempo de compilación. Cuando se pasa un tipo de arreglo a una plantilla, se decae a un puntero, eliminando la información de extensión del arreglo que distinguiría entre la eliminación escalar (delete) y la eliminación de arreglos (delete[]). std::unique_ptr resuelve esto a través de la especialización parcial de plantilla: la plantilla principal std::unique_ptr<T> utiliza std::default_delete<T> invocando delete escalar, mientras que std::unique_ptr<T[]> instancia std::default_delete<T[]> que invoca delete[]. Esta sintaxis explícita asegura que el compilador genere el código de destrucción correcto sin introspección de tipo en tiempo de ejecución o sobrecarga.
Contexto: Un motor de procesamiento de audio de baja latencia recibe búferes de muestras PCM de una API de controlador de hardware que devuelve float* asignados a través de new float[buffer_size]. Estos búferes deben pasar a través de una cadena de filtros de procesamiento de señales digitales mientras mantienen estrictas restricciones de tiempo real y seguridad contra excepciones.
Problema: El equipo necesitaba una solución de puntero inteligente que proporcionara seguridad RAII para estos arreglos de estilo C sin introducir la sobrecarga de seguimiento de tamaño/capacidad de std::vector, lo que violaría los requisitos de alineación de línea de caché para operaciones SIMD. Es crucial que usar delete escalar en memoria asignada para arreglos corrompiera el montón y causara un fallo en la pipeline de audio.
Puntero crudo con eliminación manual. Este enfoque utilizó punteros desnudos float* con llamados explícitos a delete[] en cada ruta de salida. Pros: Cero sobrecarga de abstracción y compatibilidad directa con la API de hardware. Contras: No seguro para excepciones; si un filtro lanzaba durante el procesamiento, el búfer se filtraba, y mantener la lógica de eliminación correcta a través de veinte diferentes etapas de filtro se volvía insostenible. Rechazado debido a riesgos de confiabilidad en producción.
Contenedor std::vector<float>. Envolver los búferes en std::vector proporcionó gestión automática de memoria y seguimiento de tamaño. Pros: Seguridad contra excepciones y disponibilidad de comprobación de límites. Contras: std::vector almacena implícitamente punteros de capacidad (típicamente 24 bytes de sobrecarga), lo que rompió los contratos de alineación de DMA de tamaño fijo con el hardware de audio. Además, std::vector asume propiedad mutable y potencial reubicación, en conflicto con el grupo de búfers fijo del controlador.
Especialización std::unique_ptr<float[]>. Esta solución empleó std::unique_ptr<float[]> que instancia automáticamente std::default_delete<float[]>. Pros: Cero sobrecarga (el tamaño es igual a un puntero), invocación garantizada de delete[], semánticas movibles para transferencias eficientes de cadenas de filtros y prevención de copias en tiempo de compilación. Contras: Pierde información de tamaño en tiempo de ejecución requiriendo seguimiento paralelo, y std::make_unique<float[]>(size) inicializa en valor los elementos, lo que puede ser innecesario para tipos POD.
Decisión y resultado. Seleccionamos std::unique_ptr<float[]> combinado con una vista ligera tipo span para el seguimiento de tamaño. Esto proporcionó seguridad contra excepciones sin violar las restricciones de alineación del hardware. El sistema procesó flujos de audio durante meses sin fugas de memoria, y la especialización de arreglo explícita detectó un error crítico durante la compilación donde un desarrollador intentó std::unique_ptr<float> con new de arreglo, forzando la sintaxis correcta antes de tiempo de ejecución.
**¿Por qué std::unique_ptr<Base[]> rechaza la inicialización desde new Derived[N] cuando std::unique_ptr<Derived> se convierte en std::unique_ptr<Base>?
Los tipos de arreglo exhiben un comportamiento no covariante a diferencia de los punteros simples. Mientras que Derived* se convierte implícitamente en Base* a través del ajuste de puntero, Derived[] no puede convertirse en Base[] porque la aritmética de indexación de arreglos depende del tamaño del tipo estático; acceder al elemento i en una vista de Base[] de Derived[] calcularía offsets de bytes incorrectos. Por lo tanto, la especialización de arreglo de std::unique_ptr elimina explícitamente los constructores de conversión entre diferentes tipos de arreglo para prevenir el acceso a memoria desalineada, mientras que la versión escalar permite la conversión (requiriendo destructores virtuales para seguridad).
¿Cómo inicializa std::make_unique<T[]>(n) los elementos en comparación con std::make_unique<T>(args...), y por qué esto limita su aplicabilidad?
La sobrecarga de arreglo std::make_unique<T[]>(n) realiza la inicialización en valor de todos los n elementos, que inicializa en cero escalars o construye por defecto objetos. Esto difiere de la forma escalar que reenvía argumentos al constructor de T. Esta distinción impide usar std::make_unique para arreglos de tipos no constructibles por defecto, ya que no se pueden pasar argumentos de constructor para elementos individuales. Los candidatos a menudo intentan std::make_unique<NonDefaultConstructible[]>(5, args), lo que no compila, forzando ya sea bucles manuales o el uso de std::vector con emplacemente.
¿Qué comportamiento indefinido se manifiesta cuando std::unique_ptr<T (escalar) maneja memoria de new T[N], y por qué los compiladores permanecen en silencio?
El std::unique_ptr escalar utiliza std::default_delete<T>, que llama a delete (eliminar escalar). Cuando se aplica a memoria asignada de arreglo de new T[N], esto constituye una desalineación que resulta en comportamiento indefinido; normalmente libera solo la memoria del primer elemento o corrompe los metadatos del asignador de montones. Los compiladores no advierten porque el parámetro de plantilla T decae; new T[N] devuelve T*, y el sistema de tipos pierde la distinción de arreglo en el punto de construcción de std::unique_ptr. Este modo de falla silenciosa es precisamente la razón por la que std::unique_ptr<T[]> existe como una alternativa segura de tipo distinta.