Wenn die Bedingung vor dem Fragezeichen wahr ist, wird der Teil vor dem Doppelpunkt geliefert, ansonsten der nach dem Doppelpunkt. Wenn TimingDelay gleich Null ist, wird TimingDelay der Wert Null zugeordnet, ansonsten der Wert "TimingDelay-1".
Nö, das war schon richtig so, weil die Operatoren unterschiedlichen Aufwand haben und Dein Code noch optimiert werden muss. Ganz deutlich wird das an diesem Beispiel:
"return --TimingDelay;"
vordekrementiert, kann man einfach übersetzen als:
Im "returnfall" ist also beides notwendig, wenn das Ergebnis des Operators aber nicht weiter verarbeitet wird, kann der Compiler Retval weglassen und "TimingDelay--" durch "--TimingDelay" ersetzen.
Das kann ersatzlos gestrichen werden, da sich der Wert durch die Zuweisung nicht ändert.
Da der Rückgabewert nicht gebraucht wird (der Post-Operator ist der mit dem Rückgabewert) kann direkt der Pre-Operator angewandt werden. Meine Formulierung ist also schon optimiert, bevor die der Compiler zu sehen bekommt. Außerdem verständlicher.
Dass es alle so machen, bedeutet nicht unbedingt, dass man es nicht besser machen kann.
Na ja, vorausgesetzt es ist kein Refresh, da würde der Code tatsächlich bei jedem Durchlauf einen Zugriff auf die Speicherstelle durchführen. Das würde der Compiler wohl kaum "wegoptimieren", das war zu kurz gesehen. :o(
Nein kann es (bei safety critical applications) nicht. Dort darf es keinen impliziten Code geben. (So muss bei switch/case ebenfalls der default: Pfad explizit existieren, auch wenn er leer ist).
Unabhängig von den Festlegungen bei safety ist es einfach schlechter Stil, impliziten Code zu schreiben. (Fast so schlecht wie der Code aus dem OP) Er liest sich schlecht und andere werden unnütz belastet, wenn sie sich einarbeiten müssen.
Und wenn die Zuweisung nur dazu da ist, beim Debug einen breakpoint reinsetzen zu können...
Kann ich mir nicht vorstellen. Bei switch-case schon, denn dort ist es sinnvoll, aber bei Konstrukten wie "if (a==0) a=0;" ist das zumindest für mich nur Unsinn. Und was ist denn genau impliziter Code? Muß man immer alle lokalen Variablen bei jedem "if" setzen? Oder gar alle globalen Variablen (von denen es ja besser nicht viele geben sollte) ?
Also wenn ich als C-Programmierer sowas lese:
if (TimingDelay==0) { TimingDelay=0; } else { TimingDelay--; }
dann muß ich länger darüber nachdenken, was der Code macht, da ich solchen redundanten Code nicht schreiben würde. Das hier:
if (TimingDelay) TimingDelay--;
ist viel einfach für mich verständlich, da es auch ein übliches C-Idiom ist.
Gute Debugger können Breakpoints mit Variablenprüfungen verbinden.
--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
Jetzt mal aus dem Stroutrup die Deklaration dieser Operatoren:
T& operator--(); // Präfix T operator--(int); // Postfix
Der Postfix-Operator liefert also eindeutig den schon genannten zusätzlichen Rückgabewert, während der Präfix-Operator eine Referenz auf den bearbeiteten Wert liefert, also keine zusätzliche Variable anlegen muss.
Ich verstehe nicht, was daran so schwer einzusehen ist. Das ist C++, kein BASIC, und die bessere Formulierung für oben genanntes Problem ist wirklich eindeutig.
a=foo1(); hier ist a=4 und TimingDelay=4 b=foo2(); hier erwarte ich b=5 und TimingDelay=4
Der post-operator dürfte ja eigentlich - der Logik nach - erst ausgeführt werden, wenn der Returnwert übergeben wurde. Naja wie auch schon in anderen Postings deutlich geworden ist, ist das Konzept der pre- und post-Operatoren relativ unverständlich. Man ist sich nicht wirklich sicher, was der Code tut
- ausser man geht mit dem Debugger drüber. Mir geht es mit regex ähnlich - auch wenn ich schon etliche regex-Ausdrücke gebastelt hab, fällt mir es unheimlich schwer das zu verstehen. Da ist ne simple pascal-ähnliche Syntax wirklich angenehmer. Vermutlich ist sowas nur was für Leute mit Inselbegabungen ;-).
Jedenfalls bis man so etwas selber geschrieben hat. Ich greife noch einmal die Operator-Deklarationen aus meinem anderen Posting auf, diesmal mit Implementierung:
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.