Die Anforderung ergibt sich aus den Typverfallregeln von C++ und der Notwendigkeit einer Deleter-Auswahl zur Kompilierzeit. Wenn ein Arraytyp an ein Template übergeben wird, verfällt er zu einem Zeiger, wobei die Informationen zur Arraygröße, die zwischen skalarem (delete) und Array- (delete[]) Deallokation unterscheiden würden, entfallen. std::unique_ptr löst dies durch partielle Template-Spezialisierung: Das Haupttemplate std::unique_ptr<T> verwendet std::default_delete<T>, das den skalaren delete aufruft, während std::unique_ptr<T[]> std::default_delete<T[]> instanziiert, welches delete[] aufruft. Diese explizite Syntax stellt sicher, dass der Compiler den richtigen Zerstörungscode generiert, ohne zur Laufzeit ein Typ-Introspektion oder Overhead zu haben.
Kontext: Eine Latenz-arme Audioverarbeitungs-Engine erhält PCM-Sample-Puffer von einer Hardwaretreiber-API, die float* über new float[buffer_size] zuweist. Diese Puffer müssen durch eine Kette von digitalen Signalverarbeitungsfiltern geleitet werden, während strenge Echtzeitanforderungen und Ausnahme-Sicherheit beibehalten werden.
Problem: Das Team benötigte eine Lösung mit smarten Zeigern, die RAII-Sicherheit für diese C-Stil-Arrays bieten, ohne den Overhead von std::vector zur Größen-/Kapazitätsverfolgung hinzuzufügen, was die Cache-Line-Ausrichtungsanforderungen für SIMD-Operationen verletzen würde. Kritisch wäre die Verwendung von skalar delete auf array-zugeordneter Speicher insbesondere der Heap beschädigen und die Audio-Pipeline abstürzen.
Rohzeiger mit manueller Löschung. Dieser Ansatz verwendete nackte float*-Zeiger mit expliziten delete[]-Aufrufen in jedem Exit-Pfad. Vorteile: Null Abstraktions-Overhead und direkte Hardware-API-Kompatibilität. Nachteile: Ausnahme-unsafe; wenn ein Filter während der Verarbeitung eine Ausnahme auslöste, ging der Puffer verloren, und die Aufrechterhaltung der richtigen Löschlogik über zwanzig verschiedene Filterstufen hinweg wurde unhaltbar. Wegen der Zuverlässigkeitsrisiken in der Produktion abgelehnt.
std::vector<float> Container. Das Verpacken von Puffern in std::vector bot automatisches Speicher-Management und Größenverfolgung. Vorteile: Ausnahme-Sicherheit und Verfügbarkeit von Bereichsprüfungen. Nachteile: std::vector speichert implizit Kapazitätszeiger (typischerweise 24 Bytes Overhead), was die festen DMA-Ausrichtungsverträge mit der Audio-Hardware brach. Darüber hinaus geht std::vector von veränderlichem Eigentum und möglicher Neuzuweisung aus, was im Widerspruch zum festen Pufferpool des Treibers steht.
std::unique_ptr<float[]> Spezialisierung. Diese Lösung verwendete std::unique_ptr<float[]>, die automatisch std::default_delete<float[]> instanziiert. Vorteile: Null Overhead (die Größe entspricht einem Zeiger), garantierter Aufruf von delete[], bewegliche Semantik für effiziente Übergaben zwischen Filterketten und kompilierzeitliche Verhinderung von Kopien. Nachteile: Verliert zur Laufzeit die Größeninformation, was parallele Verfolgung erfordert, und std::make_unique<float[]>(size) initialisiert die Elemente, was für POD-Typen möglicherweise unnötig ist.
Entscheidung und Ergebnis. Wir wählten std::unique_ptr<float[]> in Kombination mit einer leichten span-artigen Sicht für die Größenverfolgung. Dies gewährte Ausnahme-Sicherheit, ohne die Hardware-Ausrichtungsanforderungen zu verletzen. Das System verarbeitete monatelang Audio-Streams ohne Speicherlecks, und die explizite Array-Spezialisierung entdeckte einen kritischen Fehler während der Kompilierung, als ein Entwickler versuchte, std::unique_ptr<float> mit array-new zu verwenden, was die richtige Syntax vor der Laufzeit erforderte.
Warum lehnt std::unique_ptr<Base[]> die Initialisierung von new Derived[N] ab, während std::unique_ptr<Derived> zu std::unique_ptr<Base> konvertiert?
Arraytypen zeigen im Gegensatz zu einzelnen Zeigern nicht-kovariantes Verhalten. Während Derived* implizit zu Base* durch Zeigeranpassung konvertiert, kann Derived[] nicht zu Base[] konvertiert werden, da die Array-Indexarithmetik von der statischen Typgröße abhängt; der Zugriff auf Element i in einer Base[]-Ansicht von Derived[] würde falsche Byte-Offsets berechnen. Daher lehnt die Array-Spezialisierung von std::unique_ptr explizit konvertierende Konstruktoren zwischen verschiedenen Arraytypen ab, um den Zugriff auf misaligned memory zu verhindern, während die skalare Version die Konvertierung erlaubt (und virtuelle Destruktoren zur Sicherheit erfordert).
Wie initialisiert std::make_unique<T[]>(n) Elemente im Vergleich zu std::make_unique<T>(args...), und warum schränkt dies ihre Anwendbarkeit ein?
Die Array-Überladung std::make_unique<T[]>(n) führt eine Wertinitialisierung aller n Elemente durch, die Skalare null-initialisiert oder Objekte standard-konstruiert. Dies unterscheidet sich von der skalaren Form, die Argumente an den Konstruktor von T weiterleitet. Diese Unterscheidung verhindert die Verwendung von std::make_unique für Arrays von nicht-standard-konstruierten Typen, da Sie keine Konstruktorargumente für einzelne Elemente übergeben können. Kandidaten versuchen oft std::make_unique<NonDefaultConstructible[]>(5, args), was zu Kompilierungsfehlern führt und entweder manuelle Schleifen oder die Verwendung von std::vector mit Emplacement erzwingt.
Welches undefinierte Verhalten tritt auf, wenn std::unique_ptr<T> (skalar) den Speicher von new T[N] verwaltet, und warum schweigen Compiler?
Der skalare std::unique_ptr verwendet std::default_delete<T>, der delete (skalar delete) aufruft. Wenn dieser auf array-zugeordneten Speicher von new T[N] angewendet wird, stellt dies eine Fehlanpassung dar, die zu undefiniertem Verhalten führt – typischerweise wird nur der Speicher des ersten Elements freigegeben oder die Metadaten des Heap-Zuweisers werden beschädigt. Compiler warnen nicht, weil der Template-Parameter T verfällt; new T[N] gibt T* zurück, und das Typsystem verliert die Array-Unterscheidung zum Zeitpunkt der Konstruktion von std::unique_ptr. Dieser stille Fehlermodus ist genau der Grund, warum std::unique_ptr<T[]> als verschiedene typsichere Alternative existiert.