Ich lese Generic & lt; Programmierung & gt; Typed Buffers , ein ziemlich alter Artikel von Andrei Alexandrescu.
Ich frage mich, ob es immer noch Sinn macht. In seinem Artikel weist Alexandrescu auf einige Probleme mit std::vector hin, wenn die Leistung kritisch ist:
std::vector::reserve gelöst werden kann
std::vector für den Typ wie char , indem Sie std::memcpy und std::memmove verwenden. Das ist jetzt für Mainstream-Compiler (von dem, was ich gesehen habe) nicht wahr. std::vector nicht verkleinern, um sie mit einem einfachen Methodenaufruf an die Größe anzupassen. Was seit C ++ 11 mit std::vector::shrink_to_fit() auch nicht stimmt
Meine Frage ist, ist dieser Artikel völlig veraltet, kann ich jetzt auf Vektor (einschließlich benutzerdefinierter Zuordnung, wenn nötig) verlassen, um einen schnellen zusammenhängenden Puffer zu haben?
C ++ 11 schließt die Lücke zwischen std::vector und rohen Arrays weitgehend (Bewegungssemantik und shrink_to_fit lösen einige von Alexandrescus Punkten), aber die Nische existiert immer noch in gewissem Maße; std::vector setzt die Initialisierung der Elemente fort. reserve hilft nicht, weil Sie nicht auf den reservierten Speicher zugreifen können. Sie können dies mit einem benutzerdefinierten Zuordner hacken, aber es ist bei weitem nicht zufriedenstellend.
Am anderen Ende macht unique_ptr<T[]> das Halten eines Puffers in Ihrer Containerklasse viel einfacher, da es die Ausnahmesicherheitsprobleme weitgehend löst. Der TS dynarray , der bei der Konstruktion eine Fixed-Size-Zuweisung mit Standard-Initialisierung bietet, sieht wahrscheinlich so aus Schließen Sie einen Großteil des Rests der Lücke.
Die verbleibende Nische, die Alexandrescus generische Puffer belegen, besteht darin, default-initialisierte Elemente mit O (n) Shrink- und Grow-Operationen anzubieten; Diese sind im Allgemeinen nicht als Komponente von Container-Klassen nützlich und können bei Bedarf als Nicht-Member-Funktionen geschrieben werden.