Standardbibliotheken, die einen Allocator zuweisen, aber nicht verwenden

8

An den meisten Stellen, an denen die C ++ - Standardbibliothek Speicher zuweist, kann der Benutzer dies anpassen, indem er eine Klasse bereitstellt, die Allocator Anforderungen . Zum Beispiel nehmen fast alle Container ein Allokator-Template-Argument an, und std::allocate_shared gibt eine shared_ptr zurück, deren enthaltenes Element und Steuerblock beide über einen bereitgestellten Allocator zugewiesen sind.

Es gibt jedoch einige Stellen, an denen die Standardbibliothek (möglicherweise) Speicher reservieren kann, aber keine Allocator support. Die, die ich mir vorstellen kann, sind:

  • std::make_unique() (keine entsprechende allocate_unique() )
  • std::any
  • std::function (Zuweiserunterstützung wird in C ++ 17)
  • entfernt
  • std::valarray
  • std::basic_filebuf (obwohl std::basic_stringbuf einen Zuweiser verwendet)
  • std::inplace_merge()

Fragen:

  • Ich bin mir sicher, dass diese Liste unvollständig ist, aber was habe ich noch verpasst?
  • Von den Nicht-Zuweisungs-Klassen und -Funktionen angegeben, ob sie global ::operator new , plain new oder die Speicherquelle nicht spezifiziert verwenden?
  • Wenn jemand weiß, was sind die Gründe dafür, dass die Zuweisung von Zuweisern in any nicht erfolgt und sie aus function ?
  • entfernt wird?
Tristan Brindle 27.03.2017, 20:55
quelle

1 Antwort

4

Nicht unbedingt eine erschöpfende Liste.

  • Alles in <stdexcept> , das Speicher zum Speichern der Nachrichtenzeichenfolge reservieren muss.
  • Die standardmäßigen Pool- / monotonen Speicher-Ressourcenklassen weisen offensichtlich Speicher zu, aber sie tun dies von einer anderen Speicherressource, nicht von einem Zuordner, so dass sie technisch Ihrer Beschreibung entsprechen.
  • boyer_moore_searcher und boyer_moore_horspool_searcher .
  • Mehrere <algorithm> -Algorithmen versuchen, zusätzlichen Speicher zu erhalten (z. B. stable_partition , stable_sort ), und alle parallelen Algorithmen (unabhängig vom Header) benötigen möglicherweise zusätzlichen Speicher.
  • Viele Dinge in der Dateisystembibliothek:
    • %Code%; Dieser verwendete intern den Standard-Allocator, sieht aber so aus, als ob der neueste Entwurf diese Anforderung entfernt hätte, obwohl es anscheinend immer noch die Absicht ist.
    • path und directory_iterator .
  • recursive_directory_iterator .
  • basic_­regex und thread .
  • async , Zuweisungsunterstützung wurde in C ++ 17 entfernt.

  • Viele Dinge sind hart codiert, um den Standardzuordner zu verwenden:

    • packaged_task , error_code::message() , error_condition::message() : Diese geben ein error_category::message() zurück, also nur den Standard-Allokator.
    • Der Streaminsertion-Operator von string ruft fiktiv bitset mit dem Standardzuordner auf, obwohl dies in der Praxis nicht durch eine Implementierung mit hoher Qualität möglich ist.
    • Die Funktionen to_string und to_string free geben to_wstring / std::string zurück; keine Chance, einen eigenen Allokator anzugeben. Offensichtlich haben die benutzerdefinierten Literale für std::wstring (z. B. string ) auch keine Unterstützung für benutzerdefinierte Zuordnungen.
    • Es gibt mehrere Facetten in "foo"s , deren Memberfunktionen entweder <locale> oder std::string zurückgeben, dh den Standardzuordner verwenden (zB std::basic_string<charT> ), oder nur numpunct akzeptieren (zB basic_string<charT> ).
    • Verschiedene Typen in money_get verwenden <random> mit dem Standardzuordner.
  

Wenn jemand weiß, was die Gründe dafür sind, dass kein Allokator zur Verfügung steht   Unterstützung in vector und Entfernen von any ?

function 's Zuweisungsunterstützung ist nicht implementierbar . any 's Allokator-Unterstützung ist schlecht spezifiziert und mit Problemen geplagt .

    
T.C. 27.03.2017, 22:44
quelle