Sollten Sie Zeiger (unsicherer Code) in C# verwenden?

Question

Sollten Sie Zeiger in Ihrem C# -Code verwenden? Was sind die Vorteile? Wird es von The Man (Microsoft) empfohlen?

Answer 1

Von "The Man" selbst:

Die Verwendung von Zeigern selten in C# erforderlich ist, aber es gibt einige Situationen, die sie benötigen.Als Beispiele einen unsicheren Zusammenhang mit Zeigern zu ermöglichen, durch den folgenden Fällen gerechtfertigt ist:

• mit bestehenden Strukturen auf dem Datenträger Umgang
• Advanced COM oder Platform Invoke Szenarien, die Strukturen mit Zeigern in ihnen beinhalten
• Erfolgs- kritischer Code

Die Verwendung von unsicherem Kontext in anderen Situationen wird abgeraten.

Insbesondere sollte ein unsicherer Kontext nicht verwendet werden, um zu versuchen, C-Code in C# zu schreiben.

Vorsicht:

-Code geschrieben einen unsicheren Kontext verwendet, kann nicht als sicher überprüft werden, so wird es nur dann ausgeführt werden, wenn der Code vollständig vertrauenswürdig ist. Mit anderen Worten, unsicherer Code kann nicht in einer nicht vertrauenswürdigen Umgebung ausgeführt werden. Beispielsweise können Sie unsicheren Code nicht direkt aus dem Internet ausführen.

Reference

Answer 2

Ich kann mich nicht erinnern, dass ich es jemals tun musste - aber ich habe nicht viel Interop gemacht. Das ist die gängigste Anwendung, glaube ich: Aufruf in nativen Code. Es gibt sehr wenige Zeiten, in denen die Verwendung von Zeigern es Ihnen ermöglicht, etwas Code zu optimieren, aber es ist ziemlich selten in meiner Erfahrung.

Wenn es ein Leitfaden ist, betrachte ich mich selbst als ziemlich erfahren in C#, aber wenn ich irgendeinen unsicheren Code machen müsste, müsste ich die Spezifikation/Bücher/MSDN konsultieren, um mich zu führen. Natürlich gibt es viele Leute, die mit unsicheren Code zufrieden sind, aber weniger mit (sagen) Abfrageausdrücken ...

Answer 3

Sie sollten sie verwenden, wenn Sie sie brauchen; Meistens wird dies bei schwierigen Interop-Szenarien der Fall sein (zum Beispiel wenn ich einen verwalteten Wrapper für DPAPI in .NET 1.0 geschrieben habe), aber sehr gelegentlich könnte es sein, die Performance (nach dem Profiling) zu verbessern, indem man stackalloc oder ähnliches benutzt.

Es wird von Microsoft in so viel empfohlen, wie sie die Designer von C# sind, und sie haben die Entscheidung getroffen, die Möglichkeit hinzuzufügen, unsafe Code darin zu schreiben. Aus der Wahl des Schlüsselworts und der Anforderung, die Methoden/Klassen, in denen Sie es schreiben, mit dem Schlüsselwort zu beschreiben, können Sie sehen, dass es nicht als de-facto Implementierungswahl gedacht ist.

Answer 4

natürlich ist es nicht "empfohlen", deshalb ist es mit "unsicher" gekennzeichnet. Aber lass dich nicht davon abschrecken. Trotzdem sollte es Sie zweimal auf Ihren Code schauen lassen. Vielleicht gibt es einen Weg, es zu tun?

Answer 5

Unsafe code ist eine vollständig unterstützte Funktion der .NET CLR. Die Vorteile sind Leistung und Kompatibilität mit Binärcode. Die Laufzeit ist eine Sandbox, die verhindert, dass Sie abstürzen und brennen, aber das kostet Sie. In Situationen, in denen Sie extrem intensive Operationen gegen große Blobs im Speicher ausführen, z. B. bei der Bildbearbeitung, ist es schneller, die normale Sicherheit, die die Laufzeit bietet, zu verlassen.

Das gesagt worden ist, denke ich am meisten Leute würden hier sagen "tun Sie es nicht". Die überwiegende Mehrheit der .NET-Entwickler wird bei ihren normalen Aktivitäten nicht auf einen Fall stoßen, der nur durch die Verwendung von unsicherem Code gelöst werden kann.

Answer 6

Wenn Sie müssen.

Angenommen, Sie müssen ein großes Graustufenbild, sagen wir 2000x2000 Pixel, falsch darstellen. Schreiben Sie zuerst die "sichere" Version mit GetPixel() und SetPixel(). Wenn das klappt, dann mach weiter. Wenn sich herausstellt, dass es zu langsam ist, müssen Sie möglicherweise die tatsächlichen Bits, aus denen das Bild besteht, ermitteln (vergessen Sie zum Beispiel die Farbmatrizen). Es gibt nichts Schlimmes an der Verwendung von unsicherem Code, aber es erhöht die Komplexität des Projekts und sollte daher nur bei Bedarf verwendet werden.

Answer 7

Ich habe unsicheren Code verwendet, um den Identitätswechsel zu verwenden, um den Dienstzugriff auf Netzwerkfreigaben zuzulassen. Es ist kein Problem, wenn Sie wissen, was Sie tun.

Answer 8

Unsafe Code ist die benenfits des .Net Framework wie zu vergessen, habe ich sie einmal geschaffen altmodischen Strukturen wie Stacks und Sachen, aber das war nur für die Schule, heute ich haben die Notwendigkeit zu benutze sie.

Answer 9

Tun Sie es, wenn es Ihren Code kürzer und klarer macht.

"Folgen Sie Ihren Neigungen mit Rücksicht auf den Polizisten um die Ecke." WSM

Answer 10

Reinterpretive wie Guss nicht von BitConverter geliefert.
Konversion von einem Unint in ein int für Hash-Funktionen, wo Sie nur die Bits interessiert.

Verwenden Sie einige nützliche, gut begründete über C oder C++ idiomatische Funktionen auf Strukturen, wo Sie sie als ein Byte * einer bekannten Länge behandeln müssen, wiederum am nützlichsten für Hashing.

Extrem schnelle binäre Serialisierung von (sehr spezifischen) in Speicherstrukturen (indem man es zu einem Array von ihnen macht), aber um ehrlich zu sein, ist dies besser, indem man einfach auf C++/CLI fällt.

Es muss gesagt werden, dass in vielen Fällen die Aufgabe, die Zeiger benötigt, oft besser gelöst werden kann, indem Sie es in C++/CLI tun und dann dieses in Ihr C# -Projekt als DLL importieren. Es ändert sich nicht, ob der Code "sicher" ist oder nicht, aber er macht eine Reihe von nützlichen Funktionen zum Arbeiten mit zeigerbasierten Strukturen zugänglicher. Es erlaubt Ihnen auch, sich mit generischen Typen oder enums zu beschäftigen, wenn Sie das wirklich wollen.

Die Wahrscheinlichkeit, dass die meisten Entwickler dies tun müssen, ist in der Tat weit entfernt. Nützlich, wenn Sie es brauchen ... obwohl

Answer 11

Ich würde die wichtigsten Fragen sagen, sind: -

• Unsafe Code nicht überprüfbar ist. Dies bedeutet, dass der Code nur von einem Benutzer aus einem vollständig vertrauenswürdigen Kontext ausgeführt werden kann, also wenn Sie jemals einen Benutzer benötigen, um den Code von weniger als vollständig vertrauenswürdig auszuführen (z. B. eine Netzwerkfreigabe nicht konfiguriert), Sie bin geschraubt.
• Mangel an Überprüfbarkeit (hm nicht sicher, ob das tatsächlich ein Wort ist) bedeutet auch, dass Sie könnten potenziell Messspeicher in Ihrem Programm versauen. Sie sind potenziell bringt ganze Klassen von Fehlern zurück in Ihre Anwendung - Pufferüberläufe, baumelnde Zeiger, Yada Yada Yuck Yuck. ganz zu schweigen davon, dass es möglich ist, Datenstrukturen im Speicher zu beschädigen, ohne zu merken, wenn der Zeiger merkwürdig wird.
• Wenn Sie möchten, dass Ihr unsicherer Code auf verwaltete Objekte zugreift, müssen Sie sie "anheften". Dies bedeutet, dass der GC das Objekt nicht im Speicher verschieben darf und der verwaltete Heap daher fragmentiert werden kann. Dies hat Auswirkungen auf die Leistung. Daher ist es immer wichtig zu bestimmen, ob eine mögliche Verbesserung nicht durch dieses Problem aufgewogen wird.
• Ihr Code wird für Programmierer schwieriger, die nicht an den unmanaged Ansatz gewöhnt sind. Sie könnten dann eher dazu neigen, ihren Fuß mit einigen der 'Freiheit', die unsichere Codes geben, abzuschießen.
• Sie können un-typsicheren Code schreiben; das beseitigt den Vorteil einer warmen, unscharfen Sprache. Jetzt können Sie auf schreckliche Sicherheitsprobleme stoßen. Warum diesen Schritt rückwärts machen?
• Es macht Ihren Code hässlicher.

Ich bin sicher, dass es mehr gibt, die der Liste hinzugefügt werden könnten; im Allgemeinen, wie andere gesagt haben - vermeiden, es sei denn, du musst z. Aufruf einer unmanaged Methode über p/invoke, die ein spezielles Pointer-Feature benötigt. Selbst dann wird der Marshaller meistens die Notwendigkeit dafür größtenteils verhindern.

'Der Mann' auch sagen zu vermeiden, wenn notwendig, im Grunde.

Oh, schöner Artikel über Pinning here on MSDN übrigens.