Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Analyse und Verbesserung meines Programmierstils?

Werbeanzeige

Legend

Alter Hase

Beiträge: 731

Beruf: Softwareentwickler

  • Private Nachricht senden

51

01.12.2013, 14:10

Und wie passt dann ein Exkrement rein? :P

On Topic: Die statische Codeanalyse von Visual Studio 2012 empfiehlt bei STL-Iteratoren Preinkrement statt Postinkrement, weil es wohl etwas schneller sein kann. Das ist aber natürlich ne ziemliche Mikrooptimierung.
"Wir müssen uns auf unsere Kernkompetenzen konzentrieren!" - "Juhu, wir machen eine Farm auf!"

Netzwerkbibliothek von mir, C#, LGPL: https://sourceforge.net/projects/statetransmitt/

MitgliedXYZ

Alter Hase

Beiträge: 1 369

Wohnort: Bayern

  • Private Nachricht senden

52

01.12.2013, 14:18

Zitat von »Legend«

Die statische Codeanalyse von Visual Studio 2012 empfiehlt bei STL-Iteratoren Preinkrement statt Postinkrement, weil es wohl etwas schneller sein kann. Das ist aber natürlich ne ziemliche Mikrooptimierung.
Versteh ich nicht, wenn Präinkrement schneller als Postinkrement ist, warum ersetzt VS dann nicht einfach die Postinkremente intern zu Präinkrementen und wandelt dann den Code in Maschiensprache/.Net-irgendwas um?

Evrey

Treue Seele

Beiträge: 245

Beruf: Weltherrscher

  • Private Nachricht senden

53

01.12.2013, 14:41

Es empfiehlt sich immer, die Prä-Dinger zu nutzen, da die Postinkremente und Postdekremente eine Kopie des Ursprungswerts liefern, die möglicher Weise, unter Umständen, noch gebraucht werden könnte. Aber selbst wenn ein guter Compiler sowas im Handumdrehen erledigen kann, ist diese "Mikrooptimierung" nichts was weh tut und verdeutlicht bloß umso mehr die Intention hinterm Code.

Im Übrigen ist solch eine compilerseitige Optimierung mit Builtin-Typen wie int noch ganz trivial. Nach unbenutzten Registern suchen und fertig ist die Lauge. Bei überladenen Operatoren sieht das schon anders aus, da C++ unglücklicher Weise erlaubt, Postkremente und Dekremente separat zu definieren. Es ist also - wenngleich das total bescheuert wäre - denkbar, dass für ein Objekt x nicht zwingend ++x das selbe x liefert wie x++, x. Und da der Compiler in aller Regel keine Lust hat, alle Operatoren durchzuinterpretieren, um sie auf Äquivalenz zu überprüfen, nimmt er gewöhnlich eine sinnlose Kopie des Objekts in Kauf.

Sprachen wie D haben es geschickter gelöst. Dort kann man nur die Präkremente überladen. Postkremente werden davon abgeleitet.

C-/C++-Quelltext

 
1
2
3
4

int main(int _argc, char** _argv) noexcept {
  asm volatile("lock cmpxchg8b %eax");
  return 0;
} // ::main
(Dieses kleine Biest vermochte einst x86-Prozessoren lahm zu legen.)

=> Und er blogt unter Hackish.Codes D:

Werbeanzeige

Ähnliche Themen