Die kurzen davon:
Ja, dieser Ansatz wird [wahrscheinlich] Arbeit in begrenzten Anzahl spezialisierten Umständen. Ich vermute nicht, dass std::vector
(oder der Rest von STL) zu diesen Umständen gehören.
Die lange davon:
Wie andere erwähnt haben (und ich stimme), außerhalb eines eingebetteten Systems, Code aufblasen ist nicht viel von einem Problem auf einer kompilierten binären.
Aber viele von uns leiden unter den Kompilierungskosten beim Erstellen von Größen mehr Code während des Kompilierungsschritts, als wenn wir kompilierte Bibliotheken zum Verknüpfen hätten (anstatt Headerdateien zu kompilieren). Fügen Sie ihm die Schwierigkeit hinzu, eine dieser Template-Header-Dateien zu ändern und das gesamte Projekt von Grund auf neu zu kompilieren. Lange kompilieren Zeiten für sad Entwickler machen :(
Es kann nicht ein großes Prozent der Entwickler beeinflussen -.. Von der Größe Ihres Unternehmens Code-Basis abhängig, und wie Sie Ihre Build-Umgebung strukturieren Steuern zweifellos wir in meiner Firma
Wie einige Antworten darauf hingewiesen haben, gibt es nicht viel zu abstrahieren von einer std::vector
, die es in Ihrem Beispiel besser machen würde.Sicherlich müssen Sie in der Lage sein, einzelne Elemente zu erstellen und zu zerstören und Methoden virtual
zu behindern Laufzeit-Leistung (was wichtiger als Kompilierzeit-Leistung ist) Darüber hinaus verliert der Compiler die Möglichkeit, die void*
-Bibliothek für Vorlagencode zu optimieren, dies könnte zu einem größeren Ergebnis führen e Leistungsverlust.
Ich interessiere mich mehr für die komplexeren Strukturen - würde std::map
Abstraktion profitieren? Was, wenn Sie den rot-schwarzen Baum (die SGI-Implementierung) herausgenommen und gegen eine rot-schwarze Baumbibliothek verbunden haben.Sie müssten (wahrscheinlich) die Elemente außerhalb der std::map
speichern, so dass die Destruktoren nicht aufgerufen werden müssen, dies aber (wieder) zu einem Leistungsverlust in der Laufzeit aufgrund der Verdopplung Ihrer Indirektion führen kann.
Ich bin ziemlich sicher, dass Sie diese Methode nicht verwenden können, um die Implementierung von STL zu verbessern.
Wenn Sie die Datenstrukturen, die Sie gespeichert haben, besser gekannt haben, oder wenn Sie einen sehr speziellen Vorlagen-Typ hatten (nicht unbedingt einen Container), könnten Sie wahrscheinlich Ihre Leistung verbessern. Aber dann stellt sich die Frage: Wie oft werden Sie diesen neuen Templat-Typ verwenden, so dass der Aufwand für die Erstellung deutlich erhöht wird? Natürlich würde es helfen, Zeiten für std::vector
zu kompilieren, aber vielleicht nicht für my_domain_specific_ptr_container
. Wenn Sie 50% der Kompilierzeit für my_domain_specific_ptr_container
speichern, wie oft müssen Sie es verwenden, um einen ausreichend hohen Build-Boost zu bemerken, um die zusätzliche Komplexität der Klasse zu rechtfertigen (und die Debug-Fähigkeit zu reduzieren).
Wenn Sie nicht bereits haben, Ihre Zeit besser ausgegeben werden können Ihre Build-Tools verteilen :)
Wenn auf der anderen Seite, können Sie dies versuchen und es funktioniert für STL-Container ... bitte Post zurück. Ich möchte einen schnelleren Build! ;)
Dieser Code funktioniert nicht wie er ist, da alle 'vectorBase'-Member' private' sind und daher von abgeleiteten Klassen nicht zugänglich sind. –
Und es fehlt ';' überall, aber wir haben es verstanden. +1 Interessante Frage imho. – ereOn
Ja, ich weiß, dass dieser Code nicht kompiliert wird. es ist mir egal;) Ich möchte nicht eine ganze STL-Container einfügen ... – benoitj