![]() |
Konstante Übergabevariablen bei Prozeduren/Funktionen
Moin.
Mal eine kurze Frage, die mir aber schon seit Jahren im Kopf rumgeistert:
Delphi-Quellcode:
Procedure Whatever(input: integer);
vs.
Delphi-Quellcode:
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? |
AW: Konstante Übergabevariablen bei Prozeduren/Funktionen
Warum sollte es?
|
AW: Konstante Übergabevariablen bei Prozeduren/Funktionen
Zitat:
Wo ist sonst der Sinn von Konstanten, nur zu Wissen, dass sich der Wert nicht ändert? |
AW: Konstante Übergabevariablen bei Prozeduren/Funktionen
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. |
AW: Konstante Übergabevariablen bei Prozeduren/Funktionen
Zitat:
|
AW: Konstante Übergabevariablen bei Prozeduren/Funktionen
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) |
AW: Konstante Übergabevariablen bei Prozeduren/Funktionen
Zitat:
Kann das jemand bestätigen, widerlegen? |
AW: Konstante Übergabevariablen bei Prozeduren/Funktionen
Zitat:
Bei größeren Nichtzeigertypen (= Records / statischen Array) könnte sich das aber lohnen. |
AW: Konstante Übergabevariablen bei Prozeduren/Funktionen
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
Delphi-Quellcode:
:
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 |
AW: Konstante Übergabevariablen bei Prozeduren/Funktionen
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.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:47 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz