Konstante Übergabevariablen bei Prozeduren/Funktionen

[Cyberstorm]

Moin.

Mal eine kurze Frage, die mir aber schon seit Jahren im Kopf rumgeistert:

Procedure Whatever(input: integer);

vs.

Procedure Whatever(const input: integer);

Bringt das definieren als Konstante hardwareseitig theoretisch irgendeine Verbesserung (ram / cpu) und falls ja, wieso sieht man es so selten bei Funktionen / Prozeduren aus dem Netz, wo die Übergabeparameter eigentlich zu 90% Konstant sind?

[mkinzler]

Warum sollte es?

[Cyberstorm]

Zitat von mkinzler:

Warum sollte es?

Weil es die Möglichkeit gibt.

Wo ist sonst der Sinn von Konstanten, nur zu Wissen, dass sich der Wert nicht ändert?

[mkinzler]

Aber warum sollten diese dann weniger Speicherplatz belegen?
Es wird so nur sichergestellt, dass der Wert innerhalb der Prozedur/Funktion nicht geändert werden kann.

[Cyberstorm]

Zitat von mkinzler:

Aber warum sollten diese dann weniger Speicherplatz belegen?
Es wird so nur sichergestellt, dass der Wert innerhalb der Prozedur/Funktion nicht geändert werden kann.

Weiß auch nicht. Dachte z.B. bei einem konstanten String spart man evtl. irgendeinen Zwischenschritt

[mleyen]

Bei strings kann es ohne const sein, dass der Compiler diesen komplett kopiert und der somit 2 mal im RAM liegt.
Es gab da mal einige ASM /- Performancevergleiche die stark abweichten.
Ich denk mal das es bei Int genauso ist. Ich schreib einfach überall const dran wo es geht. (nur lesende Parameter)

[Cyberstorm]

Zitat von mleyen:

Bei strings kann es ohne const sein, dass der Compiler diesen komplett kopiert und der somit 2 mal im RAM liegt.
Es gab da mal einige ASM /- Performancevergleiche die stark abweichten.
Ich denk mal das es bei Int genauso ist. Ich schreib einfach überall const dran wo es geht. (nur lesende Parameter)

Genau an soetwas hatte ich gedacht.

Kann das jemand bestätigen, widerlegen?

[BUG]

Zitat von mleyen:

Ich denk mal das es bei Int genauso ist.

Bei Integer wäre es idiotisch der Funktion bei einem const-Parameter einen Zeiger statt des Wertes zu übergeben, da der Zeiger in Delphi immer größergleich der Integergröße ist und man in der Funktion eine Dereferenzierung zusätzlich machen müsste (bei jedem Zugriff oder einmalig beim Ablegen in einer lokalen Variable).

Bei größeren Nichtzeigertypen (= Records / statischen Array) könnte sich das aber lohnen.

[himitsu]

Ein String, dynamische Arrays und Interfaces haben eine Referenzzählung, da werden nur Referenzen hoch-/runtergezählt.
Da kann sich ein CONST eventuell lohnen, aber im allgemeinen ist soein kleines IF+INC+DEC recht flott, as daß man es oftmals überhaupt merkt.
Deßhalb laß ich dieses CONST auch bei Strings und dyn. Arrays oftmals weg, da so die Funktionsdeklaration (für mich) dann übersichtlicher wird, da kürzer und man nicht durch dieses hervorgehobene CONST abgelenkt wird.

Aber beim ShortString, Records und statischen Arrays sieht das schnell mal ganz anders aus.

Ein Integer ist hier quasi ein Sonderfall, denn der ist kleingenug, um in ein CPU-Register zu passen, darum macht dort CONST oder nicht keinen Unterschied.
Nur bei VAR wird dort ja eine Referenz übergeben und nicht der Wert.
Auch ein Int64 wird eventuell, mit der Standardaufrufkonvention, hier genauso behandelt, da dort der Wert in zwei Register paßt, also wenn dieses der erste Parameter ist (EAX+EDX ist ja eine allgemein übliche Kombination)


Also gehen wir mal auf größere Typen los, wie z.B. ein array[0..10000000] :
{nix} - eine Kopie des Arrays wird angelegt (das Kopieren und eventuell späteres Freigeben kann schonmal etwas dauern)
CONST - eine Referenz (Zeiger) auf das Array wird übergeben und, für den Compiler, als schreibgeschützt markiert
VAR - eine Referenz auf das Array wird übergeben

[Medium]

Und wie immer der Hinweis: Wenn man ein Objekt als Konstant übergibt, so verhindert der Compiler zwar das Ändern der Referenz, die Member können aber problemlos übernagelt werden. Objekte werden übrigens immer als Referenz übergeben, so dass dort das const nicht mehr macht als eben die Referenz zu schützen. Ich bin nur grad unsicher, was bei einer Änderung der Referenz ohne var passiert. Dürfte nur lokale Auswirkungen haben, zumindest was die Referenz an sich angeht. Nicht die Member.