Code Optimisation: Benutzung von const in prozedur-Köpfen

[SneakyBagels]

Kürzlich habe ich irgendwo nebenbei gefragt, was const in Prozedurköpfen bringt.
Geantwortet wurde, dass der Code dadurch wohl optimierter sei.

Kann man also festhalten, dass wenn ich die Parameter nicht innerhalb der Prozedur veränderte, ich überall const verwenden kann?
Für Integer, Boolean, Strings und Typen?

[TiGü]

https://www.delphitools.info/2010/07...nst-parameters

[Namenloser]

Ja, kannst du. Es schadet zumindest nicht. Bei Typen wie Integer, Char, Boolean etc. macht es aber in der Praxis keinen Unterschied, da eh immer der Wert kopiert wird. Bei größeren Typen wie Records kann const einiges ausmachen, weil dann nur noch ein Pointer übergeben wird, was schneller ist, als den ganzen Record zu kopieren. Und bei referenzgezählten Typen wie Strings spart man sich durch const ein addref und ein release.

[bra]

Ganz so trivial ist es aber leider auch nicht. Wenn du z.B. eine Klasse als const-Parameter übergibst, kannst du nur den Pointer nicht ändern, den Inhalt aber schon. Ich bin da auch schon drüber gestolpert, weil ich es von C++ anders kannte.

Auch führt folgendes zu m.E. seltsamen Ergebnissen:

Delphi-Quellcode:

var FString: String = 'Test';

procedure Change(const AString: String);
begin
  FString := 'Blubb';
  ShowMessage(AString);
end;

procedure CallMe;
begin
  Change(FString);
  Change(FString);
end;

[Der schöne Günther]

Zitat von bra:

Ich bin da auch schon drüber gestolpert, weil ich es von C++ anders kannte.

Oh ja, die const correctness ist auch mein Nummer 1-Feature das ich aus C++ vermisse

[SneakyBagels]

Zitat von bra:

Delphi-Quellcode:

var FString: String = 'Test';

procedure Change(const AString: String);
begin
  FString := 'Blubb';
  ShowMessage(AString);
end;

procedure CallMe;
begin
  Change(FString);
  Change(FString);
end;

Da frage ich mich.... wer baut so einen Unsinn?

[Mavarik]

Zitat von SneakyBagels:

Zitat von bra:

Delphi-Quellcode:

var FString: String = 'Test';

procedure Change(const AString: String);
begin
  FString := 'Blubb';
  ShowMessage(AString);
end;

procedure CallMe;
begin
  Change(FString);
  Change(FString);
end;

Da frage ich mich.... wer baut so einen Unsinn?

Jo... Wenn ich einen Referenz als Const übergebe und dann ne "GLOBALE" Variable intern ändere, muss ich mich nicht wundern...
Wie macht das den C? Den Zugriff auf die Globale Variable verhindern, weil das zufällig die gleiche Referenz ist?
Fehlermeldung beim compilieren? Oder etwa zur Laufzeit?

Mavarik

[bra]

Zitat von SneakyBagels:

Da frage ich mich.... wer baut so einen Unsinn?

Das war eigentlich nur ein Test, einen ähnlichen Code hatte ich irgendwo im Bezug auf diese Delphi-const-Geschichte gefunden. Dass der Code so Käse ist, ist mir schon klar. Seltsam ist nur das Ergebnis, da wird nämlich beim zweiten Aufruf ein Leerstring ausgegeben.

[SneakyBagels]

Zitat:

Wie macht das den C? (...) Fehlermeldung beim compilieren?

Eine Fehlermeldung beim Kompilieren wäre in zukünftigen Versionen von Delphi vielleicht nicht schlecht.

Zitat:

Das war eigentlich nur ein Test

Das weiß ich, keine Sorge

Ich handhabe es immer so, dass ich nur Variablen/Typen etc übergebe bei denen ich ganz genau weiß, dass ich diese in der Prozedur / Funktion nur lese und nicht schreibe.
Dann sollte eigentlich nichts schiefgehen.
Auch nutze ich das nur bei String und Typen. Zahlenwerte und Booleans ignoriere ich.

[Mavarik]

Ich denke Const ist nicht nur für die Performance, sondern auch (für mich) so einen Art Flag...

Signalisiert mir Procedure Foo(Const AValue : Integer) ändert nix an dem was ich Übergebe...
Genauso wie OUT klar kann man Var nehmen aber das verhalten wird eindeutiger...