In caso di utilizzare i puntatori (codice non sicuro) in C #?

StackOverflow https://stackoverflow.com/questions/584134

Domanda

In caso di utilizzare i puntatori nel codice C #? Quali sono i vantaggi? E 'consiglia dall'uomo (Microsoft)?

È stato utile?

Soluzione

Da "The Man" se stesso:

L'uso di puntatori è raramente necessaria in C #, ma ci sono alcune situazioni che li richiedono. Come esempi, utilizzando un contesto non sicuro per consentire puntatori sia giustificato dai casi seguenti:

  • Trattare con le strutture esistenti sul disco
  • scenari avanzati COM o Platform Invoke che coinvolgono strutture con puntatori in loro
  • prestazioni del codice-critical

L'uso di contesto non sicuro in altre situazioni è scoraggiato.

In particolare, un contesto non sicuro non deve essere utilizzato per tentare di scrivere codice C in C #.

Attenzione:

Il codice scritto utilizzando un contesto non sicuro non può essere verificato per essere sicuri, quindi sarà eseguito solo quando il codice viene completamente attendibile. In altre parole, il codice non sicuro non può essere eseguita in un ambiente non attendibile. Ad esempio, non è possibile eseguire codice non sicuro direttamente da Internet.

Riferimento

Altri suggerimenti

Se si deve.

Diciamo che avete bisogno di falsi colori una grande immagine in scala di grigi, dicono 2000x2000 pixel. In primo luogo scrivere la versione 'sicuro' utilizzando GetPixel() e SetPixel(). Se funziona, grande, andare avanti. se questo dimostra di essere troppo lento, potrebbe essere necessario per ottenere i bit reali che compongono l'immagine (dimenticare matrici di colore per il bene di questo esempio). Non c'è niente di 'cattivo' sull'utilizzo di codice non sicuro, ma aggiunge complessità al progetto e dovrebbe quindi essere usato solo in caso di necessità.

Non ricordo mai dover fare così - ma io non ho fatto molto di interoperabilità. Questa è l'applicazione più comune, credo: rimettere in codice nativo. Ci sono pochissime volte in cui l'utilizzo di puntatori consente di ottimizzare po 'di codice, ma è piuttosto raro nella mia esperienza.

Se si tratta di una guida, io mi considero abbastanza esperti in C #, ma se dovessi fare qualsiasi codice non sicuro avrei dovuto consultare le specifiche / libri / MSDN mi guida. Naturalmente ci saranno un sacco di persone che sono felici con il codice non sicuro, ma meno familiarità con (ad esempio) le espressioni di query ...

Direi che i temi principali sono: -

  • Il codice unsafe non è verificabile. Ciò significa che il codice può solo essere eseguito da un utente da un contesto del tutto attendibile, quindi se mai bisogno di un utente per eseguire il codice da qualsiasi luogo meno del tutto attendibile (ad esempio, una condivisione di rete non è configurata in modo da essere così), sei fregato.
  • La mancanza di verificabilità (hm non sono sicuro se questa è in realtà una parola) significa anche che si poteva potenzialmente rovinare la memoria nel vostro programma. Sei potenzialmente portando intere classi di bug di nuovo nella vostra applicazione - sovraccarichi del buffer, dangling pointer, bla bla che schifo che schifo. per non parlare di essere potenzialmente in grado di strutture di dati corrotti memoria senza rendersene conto quando il puntatore va strano.
  • Se si desidera che il codice non sicuro per accedere oggetti gestiti avete bisogno di 'pin' loro. Questo significa che il GC non è consentito di spostare l'oggetto in giro in memoria e quindi l'heap gestito può diventare frammentato. Questo ha implicazioni sulle prestazioni; quindi è sempre importante per determinare se qualsiasi potenziale guadagno perf non è compensato da questo problema.
  • Il tuo codice diventa più difficile da capire per i programmatori non utilizzati per l'approccio non gestito. Essi possono quindi essere più suscettibili di girare il loro piede fuori con alcune delle 'libertà' codice unsafe dà loro.
  • Si diventa in grado di scrivere un-type-safe di codice; questo in realtà piuttosto elimina un sacco del vantaggio di un bel caldo linguaggio gestito sfocata. Ora è possibile riscontrare problemi di sicurezza di tipo orribili. Perché prendere a ritroso quel passo?
  • Si rende il codice più brutto .

Sono sicuro che c'è di più che potrebbe essere aggiunto alla lista; in generale, come hanno detto altri - evitare a meno che non si dispone di to.e.g. chiamare un metodo non gestito tramite P / Invoke che richiede una certa speciale puntatore funking. Anche allora l'marshaller sarà in gran parte prevenire la necessità di esso, per lo più.

'L'uomo' dire anche evitare se non necessario, in pratica.

Oh, bell'articolo su pinning qui su MSDN dal modo in cui .

codice unsafe è completamente supportato funzione del CLR .NET. I vantaggi sono le prestazioni e la compatibilità con il codice binario. Il runtime è un sandbox che vi impedisce di crash e bruciare, ma che viene fornito con un costo. In situazioni in cui si sta facendo operazioni estremamente intensivi contro le grandi macchie in memoria, per esempio la manipolazione di immagini, è più veloce di uscire sicurezza normale runtime fornisce.

Ciò detto, credo che più la gente qui direbbe "non farlo". La stragrande maggioranza degli sviluppatori .NET non incorrere in un caso nelle loro normali attività che può essere risolto solo utilizzando il codice non sicuro.

Ho usato il codice non sicuro per utilizzare la rappresentazione per consentire l'accesso dei servizi alle condivisioni di rete. Non è un problema se si sa cosa si sta facendo.

Si dovrebbe usare se ne avete bisogno; per lo più questo sarà quando si tratta di alcuni scenari di interoperabilità difficili (per esempio quando ho scritto un wrapper gestito per DPAPI in .NET 1.0 ne fosse stato bisogno), ma molto di tanto in tanto potrebbe essere quello di migliorare le prestazioni (dopo profilatura!) utilizzando stackalloc o simili.

Si è consigliato da Microsoft in quanto essi sono i progettisti di C #, e hanno reso la decisione di aggiungere la capacità di scrivere codice unsafe in esso. Si può vedere dalla scelta di parole chiave e la necessità di delineare i metodi / classi in cui si scrive utilizzando la parola chiave, che non è stato progettato per essere la scelta de facto implementazione.

Reinterpretive come se non calchi fornita da BitConverter.
In particolare la conversione di un Unint in un int per le funzioni di hash, dove tutto ciò che interessa è il bit.

Utilizzando alcuni utili, ben motivato sulla C o C ++ funzioni idiomatiche su struct in cui è necessario trattarli come un byte * di lunghezza ben noto, ancora più utile per l'hashing.

estremamente veloce serializzazione binaria di (molto specifico) a struct memoria (facendolo a una serie di loro) anche se ad essere onesti questo è meglio fare da solo scendendo a C ++ / CLI.

C'è da dire che in molti casi il compito che richiede puntatori spesso può essere risolto meglio farlo in C ++ / CLI e quindi importare questo in voi c # progetto come una DLL. Non cambia se il codice è 'sicuro' o no, ma fa un sacco di funzioni utili per operare su strutture basate puntatore più accessibili. Esso permette anche di pasticciare con i tipi generici o enumerazioni se si vuole veramente.

Il rischio di maggior parte degli sviluppatori che devono fare questo è davvero remota. Utile quando è necessario, però ...

Naturalmente non è "raccomandato", è per questo che è etichettato come "non sicuro". Ma non lasciate che spaventare. Anche se, dovrebbe farti guardare due volte il codice. Forse c'è un modo riuscito a farlo?

utilizzando il codice non sicuro è come dimenticare le benenfits di .NET framework, ho usato una volta a vecchie strutture stile create come pile e roba, ma che era solo per la scuola, al giorno d'oggi i havent aveva la necessità di usarli.

Fatelo se rende il codice più corto e più chiara.

"Segui le tue inclinazioni tenendo in debito conto il poliziotto dietro l'angolo." WSM

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top