L'exigence découle des règles de décomposition de type de C++ et de la nécessité d'une sélection du destructeur à la compilation. Lorsqu'un type de tableau est passé à un modèle, il se décompose en un pointeur, supprimant les informations d'étendue du tableau qui distingueraient la désallocation scalaire (delete) de la désallocation de tableau (delete[]). std::unique_ptr résout cela par la spécialisation partielle des modèles : le modèle principal std::unique_ptr<T> utilise std::default_delete<T> invoquant le delete scalaire, tandis que std::unique_ptr<T[]> instancie std::default_delete<T[]> qui invoque delete[]. Cette syntaxe explicite garantit que le compilateur génère le code de destruction correct sans introspection de type à l'exécution ni surcharge.
Contexte : Un moteur de traitement audio à faible latence reçoit des tampons d'échantillons PCM d'une API de pilote matériel qui retourne float* alloué via new float[buffer_size]. Ces tampons doivent passer par une chaîne de filtres de traitement du signal numérique tout en maintenant des contraintes strictes en temps réel et la sécurité des exceptions.
Problème : L'équipe nécessitait une solution de pointeur intelligent qui offrait une sécurité RAII pour ces tableaux de style C sans introduire la surcharge de suivi de taille/capacité de std::vector, ce qui violerait les exigences d'alignement de cache pour les opérations SIMD. Critiquement, utiliser le delete scalaire sur de la mémoire allouée en tableau corromprait le tas et ferait planter le pipeline audio.
Pointeur brut avec suppression manuelle. Cette approche utilisait des pointeurs float* nus avec des appels explicites à delete[] dans chaque chemin de sortie. Avantages : aucune surcharge d'abstraction et compatibilité directe avec l'API matérielle. Inconvénients : non sécurisé aux exceptions ; si un filtre lançait une exception pendant le traitement, le tampon fuyait, et maintenir la logique de suppression correcte à travers vingt étapes de filtres devenait ingérable. Rejeté en raison des risques de fiabilité en production.
Conteneur std::vector<float>. Enveloppant des tampons dans std::vector fournissait une gestion automatique de la mémoire et un suivi de taille. Avantages : sécurité des exceptions et disponibilité de vérification des limites. Inconvénients : std::vector stocke implicitement des pointeurs de capacité (en général 24 octets de surcharge), ce qui rompait les contrats d'alignement DMA de taille fixe avec le matériel audio. De plus, std::vector suppose une propriété mutable et une réallocation potentielle, ce qui entre en conflit avec le pool de tampons fixes du pilote.
Spécialisation de std::unique_ptr<float[]>. Cette solution employait std::unique_ptr<float[]> qui instancie automatiquement std::default_delete<float[]>. Avantages : aucune surcharge (la taille est égale à celle d'un pointeur), invocation garantie de delete[], sémantique déplaçable pour des passes efficaces de chaîne de filtres et prévention à la compilation de la copie. Inconvénients : perte d'informations sur la taille à l'exécution nécessitant un suivi parallèle, et std::make_unique<float[]>(size) initialise par valeur les éléments, ce qui peut être inutile pour les types POD.
Décision et résultat. Nous avons choisi std::unique_ptr<float[]> combiné avec une vue légère de type span pour le suivi de la taille. Cela a fourni une sécurité des exceptions sans violer les contraintes d'alignement matériel. Le système a traité des flux audio pendant des mois sans fuites de mémoire, et la spécialisation explicite du tableau a détecté un bug critique lors de la compilation où un développeur a tenté std::unique_ptr<float> avec un tableau new, forçant la syntaxe correcte avant l'exécution.
Pourquoi std::unique_ptr<Base[]> rejette-t-il l'initialisation à partir de new Derived[N] lorsque std::unique_ptr<Derived> se convertit en std::unique_ptr<Base> ?
Les types de tableau présentent un comportement non-covariant contrairement aux pointeurs simples. Alors que Derived* se convertit implicitement en Base* par ajustement de pointeur, Derived[] ne peut pas se convertir en Base[] car l'arithmétique d'indexation de tableau dépend de la taille du type statique ; accéder à l'élément i dans une vue Base[] de Derived[] calculerait des décalages d'octets incorrects. Par conséquent, la spécialisation de tableau de std::unique_ptr supprime explicitement les constructeurs de conversion entre différents types de tableau pour éviter l'accès à une mémoire désalignée, tandis que la version scalaire permet la conversion (requérant des destructeurs virtuels pour la sécurité).
Comment std::make_unique<T[]>(n) initialise-t-il les éléments par rapport à std::make_unique<T>(args...), et pourquoi cela limite-t-il son applicabilité ?
La surcharge de tableau std::make_unique<T[]>(n) effectue une initialisation par valeur sur tous les n éléments, ce qui initialise à zéro les scalaires ou construit par défaut les objets. Cela diffère de la forme scalaire qui passe des arguments au constructeur de T. Cette distinction empêche l'utilisation de std::make_unique pour les tableaux de types non-construisibles par défaut, car vous ne pouvez pas passer d'arguments de constructeur pour des éléments individuels. Les candidats tentent souvent std::make_unique<NonDefaultConstructible[]>(5, args), ce qui échoue à la compilation, obligeant soit à des boucles manuelles, soit à l'utilisation de std::vector avec emplacements.
Quel comportement indéfini se manifeste lorsque std::unique_ptr<T> (scalaire) gère la mémoire provenant de new T[N], et pourquoi les compilateurs restent-ils silencieux ?
Le std::unique_ptr scalaire utilise std::default_delete<T>, qui appelle delete (delete scalaire). Lorsqu'il est appliqué à de la mémoire allouée en tableau à partir de new T[N], cela constitue un désaccord entraînant un comportement indéfini—libérant généralement uniquement la mémoire du premier élément ou corrompant les métadonnées de l'allocation du tas. Les compilateurs ne prévient pas car le paramètre de modèle T se décompose ; new T[N] retourne T*, et le système de types perd la distinction du tableau au moment de la construction de std::unique_ptr. Ce mode de défaillance silencieuse est précisément la raison pour laquelle std::unique_ptr<T[]> existe comme une alternative distincte et sécurisée par type.