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

[SneakyBagels]

Zitat:

Zitat von Mavarik (Beitrag 1373847)

Genauso wie OUT klar kann man Var nehmen aber das verhalten wird eindeutiger...

Der Name var hat mich eh schon immer gestört. Außerdem ist er total irreführend.

[Der schöne Günther]

Zitat:

Zitat von Mavarik (Beitrag 1373847)

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

Signalisiert mir

Delphi-Quellcode:

Procedure Foo(Const AValue : Integer)

ändert nix an dem was ich Übergebe...

Nö, für den Aufrufer ändert sich doch nichts. Wenn die Methode kein

Delphi-Quellcode:

const

hätte erhält sie lokal auf dem Stack eine Kopie des Parameters, aber was kümmert das den Aufrufer?

[Mavarik]

Zitat:

Zitat von Der schöne Günther (Beitrag 1373852)

Zitat:

Zitat von Mavarik (Beitrag 1373847)

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

Signalisiert mir

Delphi-Quellcode:

Procedure Foo(Const AValue : Integer)

ändert nix an dem was ich Übergebe...

Nö, für den Aufrufer ändert sich doch nichts. Wenn die Methode kein

Delphi-Quellcode:

const

hätte erhält sie lokal auf dem Stack eine Kopie des Parameters, aber was kümmert das den Aufrufer?

Also: Bei

Delphi-Quellcode:

Procedure Foo(Var AValue : integer)

könnte es sein, dass die procedure Foo AValue intern verändert. Um das raus zu bekommen, muss ich mir die Procedure anschauen... Wenn da jedoch

Delphi-Quellcode:

Procedure Foo(Const AValue : Integer)

steht, ist es klar, meine Variable bleibt erhalten... (Halte Dich jetzt nicht am Integer="Welchertyp auch immer" fest) (Abgesehen von Classen-Object-Inhalte die über Methoden verändert werden...)

Warum hat developer X Var geschrieben? Weil er nicht wollte, das die ganze Struktur einmal kopiert werden muss... (Der kannte kein Const) Ich habe selber noch Millionen Zeilen Source-Code mit Var statt Const.

[Zacherl]

Im Bezug auf Strings hatte ich vor kurzem schonmal auf eine ähnliche Frage geantwortet:
http://www.delphipraxis.net/1359775-post23.html

Zitat:

Zitat von Mavarik (Beitrag 1373841)

Wie macht das den C? Den Zugriff auf die Globale Variable verhindern, weil das zufällig die gleiche Referenz ist?

Nee, vor solchen Sachen schützt C einen auch nicht. Könnte ja auch gewollt sein, selbst wenn es wenig Sinn ergibt.

Zitat:

Zitat von Der schöne Günther (Beitrag 1373852)

Zitat:

Zitat von Mavarik (Beitrag 1373847)

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

Signalisiert mir

Delphi-Quellcode:

Procedure Foo(Const AValue : Integer)

ändert nix an dem was ich Übergebe...

Nö, für den Aufrufer ändert sich doch nichts. Wenn die Methode kein

Delphi-Quellcode:

const

hätte erhält sie lokal auf dem Stack eine Kopie des Parameters, aber was kümmert das den Aufrufer?

Ich glaube Mavarik geht es um den Aspekt des "self documenting code". Natürlich ändert sich die Variable auch ohne

Delphi-Quellcode:

const

nicht nach dem Funktionsaufruf, aber z.b. Objektparameter deklariere ich auch gerne mit

Delphi-Quellcode:

const

, um zu signalisieren, dass ich das Objekt nicht verändere (auch wenn das aufgrund der fehlenden const correctness von Delphi natürlich funktionieren würde).

[Der schöne Günther]

Ok ich wollte nur darauf hinaus dass ein

Delphi-Quellcode:

const

für den Aufrufer genauso viel aussagt wie kein

Delphi-Quellcode:

const

.

Aus Performance-Gründen haben wir das

Delphi-Quellcode:

const

drin wo geht, es als Doku für Arme zu nutzen dass man verspricht das übergebene Objekt nicht zu manipulieren wäre natürlich auch eine Möglichkeit. Leider ist es dafür zu spät. Wäre vielleicht wirklich eine gute Idee gewesen. Naja, für's nächste Projekt... ;-)

[DeddyH]

Zitat:

Zitat von SneakyBagels (Beitrag 1373849)

Der Name var hat mich eh schon immer gestört. Außerdem ist er total irreführend.

Inwiefern? Gut, man hätte es auch als InOut bezeichnen können, aber ob das immer alle auf Anhieb kapieren?

[uligerhardt]

Zitat:

Zitat von DeddyH (Beitrag 1373862)

Zitat:

Zitat von SneakyBagels (Beitrag 1373849)

Der Name var hat mich eh schon immer gestört. Außerdem ist er total irreführend.

Inwiefern? Gut, man hätte es auch als InOut bezeichnen können, aber ob das immer alle auf Anhieb kapieren?

Ich hab das implizit immer als "der Parameter ist variabel" interpretiert. Also scheint mir das halbwegs logisch, zumindest nicht "total irreführend".

[p80286]

Sobald const,var und out im Spiel sind, weiß ich, das nicht der Wert übergeben wird.
Aber das

Delphi-Quellcode:

var Myvariable

das gleiche ist wie

Delphi-Quellcode:

@Myvariable

muß ich mir immer wieder ins Bewußtsein holen. Meiner Meinung nach ist das nicht so Optimal.

Gruß
K-H

[Sailor]

Ehrlich gesagt, verstehe ich die Verwirrung nicht: Man googele doch bitte mal CallByValue, CallByReference und CallByName. Das sind uralte Techniken. Das CONST soll doch das bei CallByValue obligatorische Kopieren des Wertes auf den Stack verhindern, um den nicht unnötig vollzumüllen und macht daher nur bei komplexen Datenstrukturen sowie in Delphi bei Strings Sinn. VAR resp. OUT bedeuten dagegen CallByReference, d.h. es wird die Adresse übergeben und damit ist der Wert der Variablen außerhalb der Prozedur veränderbar. CallByName kennt Delphi glücklicherweise nicht. Das gab es in ALGOL60, mit teilweise verblüffenden Ergebnissen.

[p80286]

Ja klar ist das uralt, aber warum zum Teufel gibt es dann kein

Delphi-Quellcode:

refconst Myvalue

sondern nur ein

Delphi-Quellcode:

const Myvalue

? Wahrscheinlich dient es der Klarheit :mrgreen:

Gruß
k-H