Können Parameter konstant sein?

Ich suche das C # -Äquivalent von Java final. Existiert es?

Hat C # Folgendes:

public Foo(final int bar);

Im obigen Beispiel barhandelt es sich um eine schreibgeschützte Variable, die nicht von geändert werden kann Foo(). Gibt es eine Möglichkeit, dies in C # zu tun?

Zum Beispiel, vielleicht habe ich eine lange Methode , die mit arbeiten werden x, yund zKoordinaten eines Objekts (Ints). Ich möchte absolut sicher sein, dass die Funktion diese Werte in keiner Weise ändert und dadurch die Daten beschädigt. Daher möchte ich sie schreibgeschützt erklären.

public Foo(int x, int y, int z) {
     // do stuff
     x++; // oops. This corrupts the data. Can this be caught at compile time?
     // do more stuff, assuming x is still the original value.
}

Leider können Sie dies in C # nicht tun.

Das const Schlüsselwort kann nur für lokale Variablen und Felder verwendet werden.

Das readonlySchlüsselwort kann nur für Felder verwendet werden.

HINWEIS: Die Java-Sprache unterstützt auch die endgültigen Parameter für eine Methode. Diese Funktionalität ist in C # nicht vorhanden.

von http://www.25hoursaday.com/CsharpVsJava.html

EDIT (2019/08/13): Ich werfe dies zur besseren Sichtbarkeit ein, da dies akzeptiert wird und auf der Liste am höchsten ist. Mit inParametern ist das jetzt irgendwie möglich . Siehe die Antwort unter dieser für Details.

Dies ist jetzt in C # Version 7.2 möglich:

Sie können das inSchlüsselwort in der Methodensignatur verwenden. MSDN-Dokumentation .

Das in Schlüsselwort sollte hinzugefügt werden, bevor das Argument einer Methode angegeben wird.

Beispiel eine gültige Methode in C # 7.2:

public long Add(in long x, in long y)
{
    return x + y;
}

Während folgendes nicht erlaubt ist:

public long Add(in long x, in long y)
{
    x = 10; // It is not allowed to modify an in-argument.
    return x + y;
}

Folgende Fehler werden angezeigt, wenn entweder zu ändern versuchen , xoder yweil sie markiert sind , mit in:

Kann der Variablen 'in long' nicht zugewiesen werden, da es sich um eine schreibgeschützte Variable handelt

Ein Argument mit inMitteln markieren :

Diese Methode ändert den Wert des als dieser Parameter verwendeten Arguments nicht.

Hier ist eine kurze und süße Antwort, die wahrscheinlich viele negative Stimmen erhalten wird. Ich habe nicht alle Beiträge und Kommentare gelesen. Bitte verzeihen Sie mir, wenn dies zuvor vorgeschlagen wurde.

Nehmen Sie Ihre Parameter und übergeben Sie sie an ein Objekt, das sie als unveränderlich verfügbar macht, und verwenden Sie dieses Objekt dann in Ihrer Methode.

Mir ist klar, dass dies wahrscheinlich eine sehr offensichtliche Lösung ist, die bereits in Betracht gezogen wurde, und das OP versucht, dies zu vermeiden, indem es diese Frage stellt, aber ich war der Meinung, dass es trotzdem hier sein sollte ...

Viel Glück :-)

Die Antwort: C # hat nicht die const-Funktionalität wie C ++.

Ich stimme Bennett Dill zu.

Das Schlüsselwort const ist sehr nützlich. In diesem Beispiel haben Sie ein int verwendet, und die Leute verstehen Ihren Standpunkt nicht. Aber warum, wenn Ihr Parameter ein riesiges und komplexes Objekt des Benutzers ist, das innerhalb dieser Funktion nicht geändert werden kann? Das ist die Verwendung des Schlüsselworts const: parameter kann innerhalb dieser Methode nicht geändert werden, da [aus welchem ​​Grund auch immer] dies für diese Methode nicht wichtig ist. Das Const-Schlüsselwort ist sehr mächtig und ich vermisse es wirklich in C #.

Ich werde mit der intPortion beginnen. intist ein Werttyp, und in .Net bedeutet dies, dass es sich wirklich um eine Kopie handelt. Es ist eine wirklich seltsame Designbeschränkung, einer Methode mitzuteilen: "Sie können eine Kopie dieses Werts haben. Es ist Ihre Kopie, nicht meine. Ich werde sie nie wieder sehen. Aber Sie können die Kopie nicht ändern." Der Methodenaufruf impliziert, dass das Kopieren dieses Werts in Ordnung ist, da wir die Methode sonst nicht sicher aufrufen könnten. Wenn die Methode das Original benötigt, überlassen Sie es dem Implementierer, eine Kopie zum Speichern zu erstellen. Geben Sie der Methode entweder den Wert oder geben Sie der Methode nicht den Wert. Gehen Sie nicht zwischendurch auf die Wäsche.

Kommen wir zu den Referenztypen. Jetzt wird es etwas verwirrend. Meinen Sie eine konstante Referenz, bei der die Referenz selbst nicht geändert werden kann, oder ein vollständig verriegeltes, unveränderliches Objekt? In diesem Fall werden Verweise in .Net standardmäßig als Wert übergeben. Das heißt, Sie erhalten eine Kopie der Referenz. Wir haben also im Wesentlichen die gleiche Situation wie bei Werttypen. Wenn der Implementierer die ursprüngliche Referenz benötigt, kann er diese selbst behalten.

Das lässt uns nur mit einem konstanten (gesperrten / unveränderlichen) Objekt zurück. Dies mag aus Sicht der Laufzeit in Ordnung erscheinen, aber wie soll der Compiler dies durchsetzen? Da Eigenschaften und Methoden alle Nebenwirkungen haben können, sind Sie im Wesentlichen auf den schreibgeschützten Feldzugriff beschränkt. Ein solches Objekt dürfte nicht sehr interessant sein.

Erstellen Sie eine Schnittstelle für Ihre Klasse, die nur schreibgeschützte Eigenschaftszugriffsmethoden enthält. Lassen Sie dann Ihren Parameter von dieser Schnittstelle und nicht von der Klasse selbst sein. Beispiel:

public interface IExample
{
    int ReadonlyValue { get; }
}

public class Example : IExample
{
    public int Value { get; set; }
    public int ReadonlyValue { get { return this.Value; } }
}


public void Foo(IExample example)
{
    // Now only has access to the get accessors for the properties
}

Erstellen Sie für Strukturen einen generischen const-Wrapper.

public struct Const<T>
{
    public T Value { get; private set; }

    public Const(T value)
    {
        this.Value = value;
    }
}

public Foo(Const<float> X, Const<float> Y, Const<float> Z)
{
// Can only read these values
}

Es ist jedoch erwähnenswert, dass es seltsam ist, dass Sie das tun möchten, was Sie in Bezug auf Strukturen tun möchten. Als Verfasser der Methode sollten Sie erwarten, dass Sie wissen, was in dieser Methode vor sich geht. Die übergebenen Werte werden nicht beeinflusst, um sie innerhalb der Methode zu ändern. Sie müssen also nur sicherstellen, dass Sie sich in der von Ihnen geschriebenen Methode verhalten. Es kommt ein Punkt, an dem Wachsamkeit und sauberer Code der Schlüssel sind, um const und andere solche Regeln durchzusetzen.

Wenn Sie häufig auf solche Probleme stoßen, sollten Sie "Apps ungarisch" in Betracht ziehen. Die gute Art im Gegensatz zur schlechten Art . Während dies normalerweise nicht versucht, die Konstanz eines Methodenparameters auszudrücken (das ist einfach zu ungewöhnlich), hindert Sie nichts daran, ein zusätzliches "c" vor dem Bezeichnernamen anzuheften.

Lesen Sie bitte die Meinungen dieser Koryphäen zum Thema: Alle, die jetzt den Downvote-Button drücken möchten:

• Eric Lippert
• Larry Osterman
• Joel Spolsky

Ich weiß, dass dies etwas spät sein könnte. Aber für Leute, die immer noch nach anderen Wegen suchen, könnte es einen anderen Weg geben, um diese Einschränkung des C # -Standards zu umgehen. Wir könnten die Wrapper-Klasse ReadOnly <T> schreiben, wobei T: struct. Mit impliziter Konvertierung in Basistyp T. Aber nur explizite Konvertierung in die Wrapper <T> -Klasse. Dies erzwingt Compilerfehler, wenn der Entwickler versucht, den Wert vom Typ ReadOnly <T> implizit auf den Wert zu setzen. Wie ich im Folgenden zwei Verwendungsmöglichkeiten demonstrieren werde.

Für die Verwendung von USAGE 1 musste die Anruferdefinition geändert werden. Diese Verwendung wird nur zum Testen der Richtigkeit Ihres Funktionscodes "TestCalled" verwendet. Während der Release-Version / Builds sollten Sie es nicht verwenden. Da im großen Maßstab mathematische Operationen bei Konvertierungen möglicherweise zu viel bewirken und Ihren Code verlangsamen. Ich würde es nicht benutzen, aber nur zu Demonstrationszwecken habe ich es gepostet.

USAGE 2, das ich vorschlagen würde, hat die Verwendung von Debug vs Release in der TestCalled2-Funktion demonstriert. Bei Verwendung dieses Ansatzes würde die TestCaller-Funktion ebenfalls nicht konvertiert, erfordert jedoch ein wenig mehr Codierung der TestCaller2-Definitionen mithilfe der Compilerkonditionierung. Sie können Compilerfehler in der Debug-Konfiguration feststellen, während bei der Release-Konfiguration der gesamte Code in der TestCalled2-Funktion erfolgreich kompiliert wird.

using System;
using System.Collections.Generic;

public class ReadOnly<VT>
  where VT : struct
{
  private VT value;
  public ReadOnly(VT value)
  {
    this.value = value;
  }
  public static implicit operator VT(ReadOnly<VT> rvalue)
  {
    return rvalue.value;
  }
  public static explicit operator ReadOnly<VT>(VT rvalue)
  {
    return new ReadOnly<VT>(rvalue);
  }
}

public static class TestFunctionArguments
{
  static void TestCall()
  {
    long a = 0;

    // CALL USAGE 1.
    // explicite cast must exist in call to this function
    // and clearly states it will be readonly inside TestCalled function.
    TestCalled(a);                  // invalid call, we must explicit cast to ReadOnly<T>
    TestCalled((ReadOnly<long>)a);  // explicit cast to ReadOnly<T>

    // CALL USAGE 2.
    // Debug vs Release call has no difference - no compiler errors
    TestCalled2(a);

  }

  // ARG USAGE 1.
  static void TestCalled(ReadOnly<long> a)
  {
    // invalid operations, compiler errors
    a = 10L;
    a += 2L;
    a -= 2L;
    a *= 2L;
    a /= 2L;
    a++;
    a--;
    // valid operations
    long l;
    l = a + 2;
    l = a - 2;
    l = a * 2;
    l = a / 2;
    l = a ^ 2;
    l = a | 2;
    l = a & 2;
    l = a << 2;
    l = a >> 2;
    l = ~a;
  }


  // ARG USAGE 2.
#if DEBUG
  static void TestCalled2(long a2_writable)
  {
    ReadOnly<long> a = new ReadOnly<long>(a2_writable);
#else
  static void TestCalled2(long a)
  {
#endif
    // invalid operations
    // compiler will have errors in debug configuration
    // compiler will compile in release
    a = 10L;
    a += 2L;
    a -= 2L;
    a *= 2L;
    a /= 2L;
    a++;
    a--;
    // valid operations
    // compiler will compile in both, debug and release configurations
    long l;
    l = a + 2;
    l = a - 2;
    l = a * 2;
    l = a / 2;
    l = a ^ 2;
    l = a | 2;
    l = a & 2;
    l = a << 2;
    l = a >> 2;
    l = ~a;
  }

}

Wenn struct an eine Methode übergeben wird, wird es von der Methode, an die es übergeben wird, nicht geändert, es sei denn, es wird von ref übergeben. In diesem Sinne ja.

Können Sie einen Parameter erstellen, dessen Wert innerhalb der Methode nicht zugewiesen werden kann oder dessen Eigenschaften innerhalb der Methode nicht festgelegt werden können? Nein. Sie können nicht verhindern, dass der Wert innerhalb der Methode zugewiesen wird, aber Sie können verhindern, dass seine Eigenschaften festgelegt werden, indem Sie einen unveränderlichen Typ erstellen.

Die Frage ist nicht, ob der Parameter oder seine Eigenschaften innerhalb der Methode zugewiesen werden können. Die Frage ist, was es sein wird, wenn die Methode beendet wird.

Externe Daten werden nur geändert, wenn Sie eine Klasse übergeben und eine ihrer Eigenschaften ändern oder wenn Sie einen Wert mit dem Schlüsselwort ref übergeben. Die Situation, die Sie skizziert haben, tut beides nicht.