Kann eine String [] System.Object darin enthalten?

9

Findest du Frage ist seltsam? ja was passiert ist auch komisch. lass es mich erklären.

Ich habe einen Ausschnitt aus dieser Kovarianz und Kontravarianz mit C # -Arrays

%Vor%

Jon Skeet erklärt, dass der obige Code ArrayTypeMismatchException werfen wird, wie es ja heißt.

Was ich getan habe ist, dass ich einen Breakpoint in Zeile 3 gesetzt habe. Mit DebuggerVisualizer setze ich objects[0] = new object() manuell ein, es wird kein Fehler geworfen und es funktioniert. Später überprüft strings[0].GetType() System.Object. nicht nur System.Object irgendein Typ kann in string [] durch die oben erwähnte Prozedur gesetzt werden.

Ich habe keine Ahnung, wie das passiert ist. Ich habe meine Frage als Kommentar dort drüben gestellt, in der gleichen Frage, die ich gesehen habe, aber keine Antworten.

Ich bin neugierig zu wissen, was dahinter passiert. Jeder erklären pls.

Edit1 Das ist sogar interessant

Nach der Wiedergabe des obigen Verhaltens versuchen Sie dies

%Vor%

Wenn Sie die Maus über die Eigenschaftenlänge setzen, wird strings[0].Length threw ArgumentException mit der Nachricht Cannot find the method on the object instance angezeigt, aber tatsächlich wird keine Ausnahme ausgelöst, und der Code wird mit dem Ergebnis len=0

ausgegeben     
Sriram Sakthivel 14.07.2013, 15:40
quelle

2 Antworten

1

Ihr Beispiel scheint die Frage zu beantworten: Ja, eine string Referenz kann ein Nicht-String-Objekt referenzieren. Dies ist jedoch nicht beabsichtigt.

Überlegen Sie, was Sie gefunden haben, ein Fehler im Debugger.

Jon Skeet erklärt in die Antwort, die Sie erwähnen , weil .NET-Arrays diese "verrückte" Kovarianz haben, obwohl Arrays sind nicht schreibgeschützt, sondern mehr wie Read-Write, jedes Mal, wenn ein -Element in ein Array von Referenzen schreibt, muss das Framework den Typ des Objekts, das man in das Array schreibt, überprüfen und ein% co_de werfen %, wenn Sie einen falschen Typ verwenden möchten, wie zum Beispiel eine Instanz von ArrayTypeMismatchException einem Array von Cat s zuweisen (eine Laufzeit Dog ), die von "crazy" Kovarianz in ein Dog[] umgewandelt wurde.

Was Sie gezeigt haben, ist Folgendes: Wenn wir das Direkt-Fenster des Visual Studio-Debuggers (oder ähnlicher Fenster) verwenden, wird diese erforderliche Typüberprüfung nicht durchgeführt, und dies kann zu einem beliebigen Typ Animal[] (außer Zeiger) führen Typen), die einer Referenztypvariablen eines beliebigen Referenztyps zugeordnet werden Y . So:

%Vor%

Das kann ein X bellen wie ein Cat machen, und sowas.

Im verknüpften Thread bei der Typüberwachung von Umgehungen zeigt die Antwort von CodesInChaos eine nicht verwandte Technik, mit der Sie eine Referenz auf ein Objekt eines "falschen" und nicht verwandten Typs in eine Referenzvariable einfügen können.

    
Jeppe Stig Nielsen 15.07.2013 08:33
quelle
0

(Ich habe es vorgezogen, meine Antwort neu zu schreiben, weil der vorherige zu viele Updates hatte und nicht klar genug war).

Anscheinend wurde in einem der Werkzeuge (Direktfenster) im VS-Debugging-Teil ein nicht ganz so perfektes Verhalten gefunden. Dieses Verhalten hat (AT ALL) keinen Einfluss auf die normale Ausführung des Codes und hat rein selbst keinen Einfluss auf den Debugging-Prozess.

Was ich im letzten Satz meinte, ist, dass ich beim Debuggen von Code niemals das Direktfenster verwende, sondern einfach den gewünschten Code schreibe, ihn ausführen und sehen möchte, was der Debugger zeigt. Das referenzierte Problem hat keinen Einfluss auf diesen Prozess (der als "Debuggen von tatsächlich ausgeführtem Code" bezeichnet werden kann; im vorgeschlagenen Beispiel das Drücken von F11, wenn Sie sich in objects[0] = new object(); befinden), was ein schwerwiegendes Problem in VS bedeuten würde. Aus meiner Sicht (die Art des Debuggens, die ich tue) und vom Standpunkt der Ausführung aus hat der erwähnte Fehler keinerlei Auswirkungen.

Die einzige Anwendung dieses Fehlers ist die Ausführung der "Direktfenster" -Funktionalität, eine Funktion des Debuggers, die einschätzen kann, was der Code liefern wird, bevor er ihn tatsächlich liefert (was "Debuggen von nicht ausgeführtem Code" oder "Debugging" genannt wird) Schätzung erwarteter Ausgaben von nicht ausgeführtem Code ", etc .; in dem vorgeschlagenen Beispiel in objects[0] = new object(); , nicht Drücken von F11, sondern die Verwendung des Direktfensters, um Werte einzugeben und diese Funktion Ihnen sagen zu lassen, was zu erwarten ist).

Zusammenfassend muss das angesprochene Problem im richtigen Kontext verstanden werden, das heißt, es ist kein allgemein anwendbares Problem, nicht einmal ein Problem im gesamten Debugger (wenn Sie F11 in der entsprechenden Zeile vom Debugger drücken , es gibt einen Fehler aus und somit versteht der Debugger genau, dass diese Situation falsch ist), aber nur in einem seiner Werkzeuge. Ich bin mir nicht einmal sicher, ob dieses Verhalten für dieses Tool überhaupt akzeptabel ist (dh was "Immediate Window" liefert, ist eine Vorhersage, die vielleicht nicht 100% richtig ist; wenn Sie sicher wissen wollen, was passieren wird, führen Sie den Code aus und lassen Der Debugger zeigt Ihnen die Informationen).

  • FRAGE: Kann eine String [] System.Object darin enthalten?
  • ANTWORT: NEIN.
  • CLARIFICATION: Kovarianz ist eine komplexe Realität, die von einigen der sekundären Werkzeuge in VS nicht perfekt berücksichtigt werden kann (z. B. "Immediate Window") und somit könnte es Fälle geben, in denen die diese Aussage trifft nicht vollständig zu. ABER das ist ein Einheimischer Verhalten / Bug im spezifischen Werkzeug ohne Auswirkung in der tatsächlichen Ausführung des Codes.
varocarbas 14.07.2013 16:36
quelle

Tags und Links