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.
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
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.
{ 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!
