Procedure vs Function, Vor- und Nachteile

**freimatz**

Ich versuche schon seit Jahren, dahinter zu kommen, WIE genau const den Parameterzugriff wann optimiert.

Echt jetzt? Wozu? Also wenn Du das als Hobby machst ok.
Wenn Ihr aber professionell programieren wollt dann lasst den ...
Macht lieber schönen lesbaren code der sich schnell verstehen lässt und das tut was der Anwender will. Die Optimierungen hier sind marginal und merkt der Anwender nicht. Ich behaupte nicht mal in 1% der Fälle spielt das eine Rolle. Selbst wenn es mal ein Geschwindigkeitsproblem gibt, dann liegt das meist woanders. (Ich selber habe früher viel mit Assembler gemacht.) Und wenn Ihr schönen Code habt dann kann man viel leichter mal einen Cache o.a. dazwischenschieben wenn es nötig ist. Das bringt dann z.B. Faktor 5 und nicht nur 5%.
Es es hat schon seinen Grund warum EMB da (fast) nichts dokumentiert - sie würden sich ja selbst einen Klotz für künftige Optimierungen ans Bein binden.

http://clean-code-developer.de/die-g..._Optimierungen

**bernau**

Zitat von freimatz:

Zitat von Dennis07:

Ich versuche schon seit Jahren, dahinter zu kommen, WIE genau const den Parameterzugriff wann optimiert.

Echt jetzt? Wozu? Also wenn Du das als Hobby machst ok.
Wenn Ihr aber professionell programieren wollt dann lasst den ...
Macht lieber schönen lesbaren code der sich schnell verstehen lässt und das tut was der Anwender will. Die Optimierungen hier sind marginal und merkt der Anwender nicht. Ich behaupte nicht mal in 1% der Fälle spielt das eine Rolle. Selbst wenn es mal ein Geschwindigkeitsproblem gibt, dann liegt das meist woanders. (Ich selber habe früher viel mit Assembler gemacht.) Und wenn Ihr schönen Code habt dann kann man viel leichter mal einen Cache o.a. dazwischenschieben wenn es nötig ist. Das bringt dann z.B. Faktor 5 und nicht nur 5%.
Es es hat schon seinen Grund warum EMB da (fast) nichts dokumentiert - sie würden sich ja selbst einen Klotz für künftige Optimierungen ans Bein binden.

http://clean-code-developer.de/die-g..._Optimierungen

Also der Code wird m.M nach nicht unleserlicher, wenn man const verwendet.

Macht sich auch nicht immer bemerkbar. Wenn man aber eine Procedure hat, die Millionen mal aufgerufen wird, dann bekommt man schon einen merkbaren Geschwingkeitsschub.

Ich bin seit ein paar Jahren mit Refactoring beschäftigt, um meinen Code von meinem Altprojekt leserlicher zu machen. Manchmal gehört es auch dazu ein fehlendes const einzufügen. Mit Ctrl-Alt-Shift-P ist die Änderung auch ganz schnell in die Impelemtation oder in das Interface übertragen.

**Dennis07**

Zitat von freimatz:

Echt jetzt? Wozu? Also wenn Du das als Hobby machst ok.
Wenn Ihr aber professionell programieren wollt dann lasst den ...
Macht lieber schönen lesbaren code der sich schnell verstehen lässt und das tut was der Anwender will. Die Optimierungen hier sind marginal und merkt der Anwender nicht. Ich behaupte nicht mal in 1% der Fälle spielt das eine Rolle. Selbst wenn es mal ein Geschwindigkeitsproblem gibt, dann liegt das meist woanders. (Ich selber habe früher viel mit Assembler gemacht.) Und wenn Ihr schönen Code habt dann kann man viel leichter mal einen Cache o.a. dazwischenschieben wenn es nötig ist. Das bringt dann z.B. Faktor 5 und nicht nur 5%.
Es es hat schon seinen Grund warum EMB da (fast) nichts dokumentiert - sie würden sich ja selbst einen Klotz für künftige Optimierungen ans Bein binden.

Also da fehlen mir ehrlich gesagt die Worte... Warum um alles in der Welt soll es denn bitte "unleserlich" sein, Parameter, die einen bestimmten Zweck erfüllen sollen (var, out, const) als solche zu deklarieren? Kann ich beim besten Willen nicht nachvollziehen. Ich bin ja auch kein 5-jähriger, der nicht weiß wo oben und unten ist.

Also grundsätzlich, und da ist es mir völlig egal welche "Authorität" in seinem "CleanCode" guide irgendwas meint schreiben zu müssen, halte ich es im Gegenteil für eine enorm schlechte Praxis, die Features, die man besitzt (zB. "const" und "out") nicht zu benutzen, wenn dies angebracht wäre. Mal ganz abgesehen davon, dass es eben zumindest im Falle von "const" die Performance deutlich beeinflussen kann. Und selbst wenn es nur 5% sind, und man gleichzeitig noch die Übersicht durch den eingeschränkten Zugriff erhöht...
Im Grunde kann ich Bernau da nur zustimmen. Wollte es aber nochmal selbst mit eigenen Worten gesagt haben.

Zitat von p80286:

Was mir in der Betrachtung fehlt, ist die Schreibschutzprüfung die ja bei const irgendwo stattfinden muß.

Hatte ich zwar schon weiter oben erklärt, aber Danke an Neutral General, dass er es nochmal praktisch untermauert hat

Zitat von himitsu:

Es gibt Aufrufkonventionen, da landet alles auf dem Stack und nichts in Registern (außer dem Result, der praktisch überall in EAX ist ... abgesehn davon, wo hier der Result zu einem VAR-Parameter gemacht wurde)
Praktisch landen im "Pascal" die ersten 3 Parameter in Registern (EAX, EDX und ECX, wenn möglich) und der Rest immer auf dem Stack.
In Methoden gibt es einen "unsichtbaren" SELF-Parameter, der als Erstes kommt. ("procedure t.x", "class procedure t.x" aber nicht "class procedure t.x static")
Dazu kommt dann noch, ob die Referenz oder der Wert dort gespeichert wird.
Delphi macht bei gemanagten Typen aus aus dem Result einen VAR-Parameter und
Unter 64 Bit gibt es nur noch eine Konvention mit paar mehr Registern.

Jo, kann man aber auch alles im DocWiki unter Assembler-Prozeduren und -Funktionen nachlesen, wens interessiert. Anmerken würde ich hier nur, dass nur kurze Strings und Records, nicht aber andere Stringtypen (zB. OpenString, AnsiString oder UnicodeString), diese werden direkt in EAX zurückgegeben, da sie ja bereits Zeiger/Referenzen sind.

Zitat von himitsu:

{ IN .. Referenz . . . . . .} [ref] const Xxx: Txxx; // relativ neu

WWWAAS? Etwas in Delphi, das ich noch nicht kenne? Wow, ist mir das schon ewig nicht mehr passiert. Kannst du mal genau erklären, was das genau ist bzw. hast du einen Link zu dem Thema? Würde mich mal echt interessieren.

An dieser Stelle würde ich Zacherl gern noch für seinen Aufwand und die Erklärungen danken!