std::list Implementierung
-
314159265358979 schrieb:
Feedback bitte
Warum eigentlich?
-
Werner Salomon schrieb:
314159265358979 schrieb:
Feedback bitte
Warum eigentlich?
Weil ich wissen möchte, ob noch jemandem etwas auffällt, das total falsch oder schöner/besser/schneller zu lösen ist. Bin halt ein Perfektionist
-
Neben der fehlenden iterator -> const_iterator Konvertierung ist mir noch etwas aufgefallen. Du verwendest überall Schleifen der Art
for (auto&& iter = list.begin(); iter != list.end(); ++iter) ...wobei hinter dem auto ein && sitzt. Das ist aber eigentlich überflüssig. list.end() wird (logisch) auch jedes Mal aufgerufen.
Und ich sehe gerade noch, dass der Selbstzuweisungstest beim operator=(List) nicht nötig ist.
-
krümelkacker schrieb:
Neben der fehlenden iterator -> const_iterator Konvertierung ist mir noch etwas aufgefallen.
Wäre es ratsamer in iterator einen operator const_iterator() zu definieren, oder dem const_iterator einen iterator-Konstrukor zu geben?
krümelkacker schrieb:
wobei hinter dem auto ein && sitzt. Das ist aber eigentlich überflüssig.
Was zur Folge hat, dass der Returnwert gemoved wird. Dass das wenig bringt, ist mir klar.
krümelkacker schrieb:
list.end() wird (logisch) auch jedes Mal aufgerufen.
Natürlich könnte ich die Schleife so umschreiben:
for(auto&& iter = list.begin(), end = list.end(); iter != end; ++iter) ...Aber kann der Compiler das nicht von selbst optimieren?
krümelkacker schrieb:
Und ich sehe gerade noch, dass der Selbstzuweisungstest beim operator=(List) nicht nötig ist.
Danke, habe ich übersehen
-
314159265358979 schrieb:
Weil ich wissen möchte, ob noch jemandem etwas auffällt, das total falsch oder schöner/besser/schneller zu lösen ist. Bin halt ein Perfektionist
Warum lehnst du dann alle verbesserungs vorschlaege ab?
-
Shade Of Mine schrieb:
314159265358979 schrieb:
Weil ich wissen möchte, ob noch jemandem etwas auffällt, das total falsch oder schöner/besser/schneller zu lösen ist. Bin halt ein Perfektionist
Warum lehnst du dann alle verbesserungs vorschlaege ab?
Tue ich doch gar nicht, vielleicht habe ich mich schlecht ausgedrückt, ich möchte es erstmal bei der vorhandenen Funktionalität belassen
-
314159265358979 schrieb:
krümelkacker schrieb:
wobei hinter dem auto ein && sitzt. Das ist aber eigentlich überflüssig.
Was zur Folge hat, dass der Returnwert gemoved wird.
Wie bitte? Was wird wohin "gemoved"?
-
Normalerweise wird der Returnwert kopiert, mit && gemoved. Jaja, ich weiß, copy elision, aber ich habs mir angewöhnt den Returnwert aus Funktionen mit && zu moven. Und langsamer kanns dadurch ja nicht werden
-
314159265358979 schrieb:
Normalerweise wird der Returnwert kopiert, mit && gemoved. Jaja, ich weiß, copy elision, aber ich habs mir angewöhnt den Returnwert aus Funktionen mit && zu moven. Und langsamer kanns dadurch ja nicht werden
Aber "gemoved" wird hier gar nichts. Du bindest lediglich eine Rvalue-Referenz an ein temporäres Objekt, dessen Lebenszeit dann verlängert wird.
-
krümelkacker schrieb:
314159265358979 schrieb:
Normalerweise wird der Returnwert kopiert, mit && gemoved. Jaja, ich weiß, copy elision, aber ich habs mir angewöhnt den Returnwert aus Funktionen mit && zu moven. Und langsamer kanns dadurch ja nicht werden
Aber "gemoved" wird hier gar nichts. Du bindest lediglich eine Rvalue-Referenz an ein temporäres Objekt, dessen Lebenszeit dann verlängert wird.
Da hast du Recht, habe das wohl verwechselt, jedenfalls war es so gemeint