Sind basic_string-Literale schneller oder werden sie zur Kompilierzeit besser behandelt?

8

Während ich den Entwurf von C ++ 14 / C ++ 1y (n3690) überflog, bemerkte ich die Einführung der basic_string literal Suffixe in § 21.7:

%Vor%

Meine Fragen sind:

  • Gibt es eine Möglichkeit, zur Laufzeit mit basic_string Literalen schneller zu sein?
  • Ist meine "naive" Umsetzung völlig falsch?
  • Kann das Layout von Daten im ROM mit basic_string Literalen oder einem anderen Unterschied zur Kompilierungszeit im Vergleich zur Laufzeit anders sein?

Hintergrund

Ich weiß, dass dies die direkte Verwendung von String-Literalen wie folgt ermöglicht:

%Vor%

Aber was ist der Vorteil gegenüber dem Konvertierungskonstruktor string(const char*) ?

?

Der "alte" Code würde aussehen:

%Vor%

Soweit ich sehen kann, würde die Implementierung von operator "" s() im Prinzip so aussehen:

%Vor%

Also, nur die Verwendung des gleichen c'tor. Und meine Vermutung ist, das muss zur Laufzeit gemacht werden, liege ich falsch?

Bearbeiten: Da Nicol Bolas unter meinem Beispiel richtig angezeigt wird, verwendet nicht denselben Konstruktor, sondern den mit der zusätzlichen Länge - - Das ist natürlich sehr nützlich für den Bau. Dies hinterlässt bei mir die Frage: Ist es besser für den Compiler, String-Literale in ROM zu schreiben, oder etwas ähnliches zur Kompilierzeit?

    
towi 26.08.2013, 08:11
quelle

3 Antworten

6
  
  • Gibt es eine Möglichkeit, zur Laufzeit mit basic_string-Literalen schneller zu sein?
  •   

Wie bereits erwähnt, ist die Stringlänge bekannt und wird automatisch an den Konstruktor übergeben.

  
  • Ist meine "naive" Umsetzung völlig falsch?
  •   

Nein, das stimmt.

  
  • Kann sich das Layout von Daten im ROM mit basic_string-Literalen oder einem anderen Unterschied bei der Kompilierungszeit im Vergleich zur Laufzeit unterscheiden?
  •   

Wahrscheinlich nicht, weil der relevante basic_string -Konstruktor nicht constexpr ist, also nicht für die statische Initialisierung geeignet ist, also wahrscheinlich nicht in das ROM geschrieben werden kann und zur Laufzeit ausgeführt werden muss.

>     
Jonathan Wakely 27.08.2013, 11:53
quelle
4
  

Also, nur die Verwendung des gleichen c'tor.

OK, mal sehen, wie das aussehen würde:

%Vor%

Was fehlt in fromBare ? Lass es mich für dich buchstabieren:

%Vor%

Ja, du kannst die Länge der Zeichenfolge nicht bekommen, ohne ... die Länge zu erhalten. Das bedeutet, dass fromBare das Literal durchlaufen muss, um das fromLit -Zeichen zu finden. Zur Laufzeit. using std::string wird nicht; Der Compiler stellt die Länge der Zeichenfolge als einen für die Kompilierung bestimmten Parameter bereit. Jeder Compiler, der es wert ist verwendet zu werden, wird nur die Länge in den ausführbaren Code brennen.

Und selbst wenn das nicht der Fall war, ist es aus anderen Gründen immer noch besser. Bedenken Sie Folgendes:

%Vor%

Die letzten beiden machen dasselbe (minus dem Punkt, den ich vorher gemacht habe), aber einer von ihnen ist viel kürzer. Selbst wenn Sie using namespace std; (oder töricht %code% ) verwenden, ist die zweite noch kürzer. Aber es ist klar, was genau passiert.

    
Nicol Bolas 26.08.2013 08:35
quelle
1

Es bietet mehr Sicherheit bei der Kompilierungszeit.

Betrachten Sie Wie konstruieren Sie? eine std :: string mit einem eingebetteten null?

Die einzige Möglichkeit, ein std::string aus einem String-Literal zu konstruieren, das ein Nullzeichen enthält, ist entweder die Größe des String-Literals anzugeben (fehleranfällig), initializer_list syntax (verbose) zu verwenden oder eine Art von Schleife mit mehreren Aufrufen von push_back (noch ausführlicher). Mit dem Literalkonstruktor wird die Größe jedoch automatisch an Sie übergeben, wodurch eine mögliche Fehlerquelle entfernt wird.

    
David Stone 04.10.2013 00:27
quelle