Einen minimalen Vorteil bringt es, da das Programm nicht ständig testen muss, ob die Variable geändert wurde,
die leistungsersparniss ist allerdings so klein, dass es fast nichts bringt.
Außerdem läufst du nicht Gefahr, die Variable mit einer ähnlichen Variable zu verwechseln.
Aber sonst sehe ich auch keine Nennenswerten Vorteile

in einer anderen Sprache die ich für die Arbeit brauche benutze ich ziemlich oft Konstanten aber auch nur aus dem Grund das wenn ich in Rechnungen später auch noch weiß warum ich jetzt den einen Wert abgezogen habe.

z.b. Tischunterkante = Tischhoehe - Konstante Plattenstärke anstelle Tischunterkante = Tischhoehe - 25mm

ist zwar ein einfaches beispiel aber mir hilft die konstante immer dabei einem Wert einen Namen zu geben.

Es gibt einen - wenn auch vernachlässigbaren (in allermeisten Fällen) - Performanceunterschied. Der grössere Punkt ist, dass man je nach Problem Variablem braucht, die unter keinen Umständen verändert werden dürfen. Wenn jemand eine Methode zur Flächenberechung von Kreisen schreibt, wäre es natürlich verheerend wenn man die Konstante PI innerhalb der Methode ändern könnte. Für den Author der Methode mag es klar sein, dass eine grösse immer die selbe sein sollte. Wird dieser Code an andere Leute weitergegeben, kann das natürlich anders aussehen.

MemoAnMichSelbst schrieb:

Ich frage mich, warum sollte ich Konstante Plattenstärke benutzen und nicht Plattenstärke

ja wenn es verschiedene Stärken gibt dann trifft dies ja auch zu gibt aber andere Fälle (zumindest bei mir) wo sich Werte nie verändern.
In meinem Fall ist es schwer zu erklären wenn man das was ich mache nicht kennt aber auch in VB ist es ja nützlich wenn man die Konstante ändern kann
wenn mal was sein sollte und nicht den ganzen Code nach Werten absuchen muss oder?

Hey,

ich meine auch mal iwo gelesen zu haben, dass eine Const vom Compiler direkt in die IL geschrieben wird, anstatt den Wert aus dem Speicher zu holen.

Z. B. folgender QuellCode:



Mit IL-Spy dekompiliert:

SpaceyX schrieb:

ich meine auch mal iwo gelesen zu haben, dass eine Const vom Compiler direkt in die IL geschrieben wird, anstatt den Wert aus dem Speicher zu holen.

Das meinst du nicht nur, das ist sogar wirklich so ;). Der Compiler ersetzt verweise auf Konstanten direkt durch deren Wert. Zusätzlich werden private Konstanten sogar gelöscht bzw. entfernt und dienen somit eigentlich nur der Wartbarkeit.

@MemoAnMichSelbst: Konstanten solltest Du immer dann verwenden, wenn der Wert nie geändert werden kann/darf und Du dem Wert einen aussagekräftigen Namen geben willst.
Beispiele:
Math.Pi
Math.E
Byte.MinValue
Byte.MaxValue
(Das selbe für andere primitive Datentypen)
Double.Epsilon
Double.PositiveInfinity
Double.NegativeInfinity
Double.NaN
(Das selbe für Single)
DateTime.TicksPerMillisecond
(Und TicksPerSecond, Minute, etc.)
Timeout.Infinite

Das sind alles Werte, die nie geändert werden, weil es keinen Sinn machen würde. Und da verwendet man Konstanten.

Und ja, es gibt einen kleinen Performance-Unterschied.
Beispiel:

Also die Bar-Methode weist der lokalen Variable einmal ValueA zu, welches ein (ReadOnly)-Feld ist, und danach ValueB, welches eine Konstante ist.
Die Bar-Methode wird zu folgendem IL-Code kompiliert:

Wie Du siehst, muss beim Feld tatsächlich der Inhalt des Feldes geladen werden (ldsfld). Macht Sinn, denn der Compiler weiß ja nicht, dass Du den Wert nie verändern wirst.
Hingegen "verschwindet" die Konstante beim Kompilieren. Da wird direkt der Wert 4 auf den Auswertungsstapel gelegt (ldc_i4_4). Das ist schneller. Insbesondere, wenn man kein statisches Feld verwendet, sondern (unnötigerweise) ein Instanzfeld. Denn dann kommt das heraus:

Also da wird nochmal zuerst die aktuelle Instanz auf den Stapel gelegt, und dann muss da der Wert des Feldes rausgepuhlt werden.

Also es gibt einen Performance-Unterschied, aber der ist, wie gesagt wurde, so gering, dass er vernachlässigbar ist.
Viel wichtiger ist die zusätzliche Information, die die Konstante bekommt, dadurch, dass sie als konstant deklariert wurde. Denn dadurch weiß man als Programmierer "Aha, das ist eine Konstante".

Edit: War zu langsam.

im Gegensatz zu readonly Public Shared Membern können Konstanten auch als optionale Parameter eingesetzt werden.

Beachtet auch, wie in Enums mehrere Konstanten als zusammengehörig gruppiert sind.

Der (vernünftige) Name einer Konstante liest sich im Quelltext besser als eine Zahl.
@MemoAnMichSelbst:: Welchen Wert gibst Du der Zahl, die sich aus der Division von Kreisumfang und Durchmesser ergibt?

jo - und punkt 1 ist auch noch irrelevant, denn kein proggi wird jemals laggen, weils seine Konstanten variabel definiert (beachte die sprachliche Paradoxie ;)).

Konstanten sind also v.a. eine inhaltliche Aussage: "dieser Wert ist Konstant".

So, wie man eine Property ebensogut (ich finde sogar: eiglich besser) durch Setter- und Getter- Methode simulieren kann (ist es im Hintergrund sogar), so kann man auch eine Konstante durch ein Shared Readonly Feld "simulieren".
Aber für die menschliche OOP-Denkweise ists günstiger, man spricht von der Eigenschaft eines Objekts.
Und so ists fürs menschliche Hirn auch besser, eine Konstante als Konstante zu denken - nicht als Shared Readonly.

MemoAnMichSelbst schrieb:

Kreiszahl

Math.PI, eine Konstante.
Oder wieviele Stellen schreibst Du davon in Deinen Code?

Mehrwert ist das bessere Verständnis.
Man kann das Programm auch in einer Funktion runterschreiben, unstrukturiert. Warum tut man das nicht (zumindest sollte man nicht )? Weil es unverständlich, schlecht wartbar und nur schwer veränderbar und anpassbar ist.
Wenn eine Konstante auch als Konstante definiert und benannt ist (auch im Namen), sieht ein Mensch, der dein Programm anschaut (auch du einige Monate später), sofort, dass es eine Konstante ist und braucht nicht mehr zu überprüfen, ob auf diese Variable irgendwo zugegriffen wird und deren Wert sich verändert.
Wenn man ein Programm anschaut, hat man ein Bild, eine Struktur, ein Modell im Kopf (sollte man zumindest) - und "Konstante" ist ein Puzzlestein, welches es erleichtert, dieses Modell schneller zu bilden. Wenn es natürlich an der Stelle sinnvoll ist...

Hi
wie schon gesagt, es ist in gewissen Bereichen ein Nachteil, aber Pi wird sich nicht von heute auf morgen ändern, auch wenn von gewissen Menschen immer wieder Versuche dahingehend unternommen werden. D.h. sie ist eben konstant. Konstante Werte werden, wie bereits gesagt wurde, nicht aus dem Heap genommen, sondern direkt in den IL-Code geschrieben, d.h. der Zugriff ist effizienter, sofern der JITC das nicht wegkompiliert, was er afaik nicht tut/kann, da das Festlegen im statischen Konstruktor des enthaltenden Typs festgelegt wird. D.h. hier wird ebenfalls ein "Methoden"aufruf ausgeführt, der beim Kompilieren von IL-Code zu nativem Code (einmalig) stattfindet (mittels lazy evaluation, wenn ich mich an die Tests richtig erinnere).
Statische readonly-Properties sind nicht konstant (!), ebenso ist der Inhalt konstant definierter Strings nicht konstant, sondern lediglich das darstellende Handle auf den String. D.h. der Wert, der das Objekt darstellt ist konstant. Für Wertetypen, wie Integer, usw. ist somit auch der Wert konstant, der Speicher, an dem der Wert steht, aber nicht. Daher kann man String-Inhalte mittels Zeiger eben auch beschreiben, obwohl das Speicherhandle konstant ist (der Wert liegt ja im Heap!).
Insgesamt dienen schreibgeschützte Werte natürlich einem Zweck und es ist auch kein Nachteil. Nicht-primitive Typen außer String, Type und einige ausgewählte Typen (z.B. auch Enums) sind außerdem nicht als Konstante darstellbar.

Gruß
~blaze~

Es ist kein Mehrwert, offensichtlich konstante Werte veraenderlich zu machen. Es ist mir frueher oft passiert, dass ich an Sachen wie Stringformat.Genericdefault rumgepfuscht hab, weil ich dachte es waere konstant (inzwischen weiss ich ja, dass das bei Klassen gar nicht geht und auch ein Readonly nur vor der Zuweisung schuetzt, nicht aber vir dem Aendern der Eigenschaften). Und das hatte dann ziemlich unschoene Folgen, wie du dir vielleicht vorstellen kannst.

Ein nicht-veränderbar sein ist kein Vorteil... Das ist ein Nachteil... Den man in Kauf nehmen kann wenn man eine Variable nicht ändern muss, da sie konstant ist. Aber nunmal kein Mehrwert.

Aber das ist doch genau der Vorteil, den man durch Konstanten bekommt
Gott sei Dank kann man das nicht mit Konstanten machen:

Das ist ja der Sinn von Konstanten, dass man sie nicht verändern kann.
Man kann Pi nicht versehentlich auf 3 ändern... oder auf 7.