Ha senso usare "as" invece di un cast anche se non è presente un controllo null? [chiuso]

Nei blog di sviluppo, esempi di codice online e (di recente) anche un libro, continuo a imbattermi in codice come questo:

var y = x as T;
y.SomeMethod();

o, peggio ancora:

(x as T).SomeMethod();

Questo non ha senso per me. Se si è certi che xè di tipo T, è necessario utilizzare un cast diretta: (T)x. Se non si è sicuri, è possibile utilizzare asma è necessario verificare nullprima di eseguire alcune operazioni. Tutto quello che fa il codice sopra è di trasformare un (utile) InvalidCastExceptionin un (inutile) NullReferenceException.

Sono l'unico a pensare che si tratti di un palese abuso della asparola chiave? O mi sono perso qualcosa di ovvio e lo schema sopra ha davvero senso?

La tua comprensione è vera. Mi sembra di provare a micro-ottimizzare per me. Dovresti usare un cast normale quando sei sicuro del tipo. Oltre a generare un'eccezione più sensata, fallisce anche velocemente. Se ti sbagli su tua ipotesi sul tipo, il vostro programma fallirà immediatamente e sarete in grado di vedere la causa del fallimento subito piuttosto che aspettare una NullReferenceExceptiono ArgumentNullExceptiono anche un qualche errore logico in futuro. In generale, asun'espressione che non è seguita da un nullsegno di spunta da qualche parte è un odore di codice.

D'altra parte, se non sei sicuro del cast e ti aspetti che fallisca, dovresti usare asinvece di un cast normale avvolto in un try-catchblocco. Inoltre, assi consiglia l' uso di un controllo del tipo seguito da un cast. Invece di:

if (x is SomeType)
   ((SomeType)x).SomeMethod();

che genera isinstun'istruzione per la isparola chiave e castclassun'istruzione per il cast (eseguendo effettivamente il cast due volte), è necessario utilizzare:

var v = x as SomeType;
if (v != null)
    v.SomeMethod();

Questo genera solo isinstun'istruzione. Il primo metodo presenta un potenziale difetto nelle applicazioni multithread poiché una condizione di competizione potrebbe causare il cambio di tipo della variabile dopo che il iscontrollo ha avuto esito positivo e si è verificato un errore nella linea di lancio. Quest'ultimo metodo non è soggetto a questo errore.

_{La seguente soluzione non è consigliata per l'uso nel codice di produzione. Se odi davvero un costrutto così fondamentale in C #, potresti prendere in considerazione il passaggio a VB o qualche altra lingua.}

Nel caso in cui uno odia disperatamente la sintassi del cast, può scrivere un metodo di estensione per imitare il cast:

public static T To<T>(this object o) { // Name it as you like: As, Cast, To, ...
    return (T)o;
}

e usa una sintassi [?] pulita:

obj.To<SomeType>().SomeMethod()

IMHO, ha assenso solo se combinato con un nullcontrollo:

var y = x as T;
if (y != null)
    y.SomeMethod();

L'uso di "as" non applica le conversioni definite dall'utente mentre il cast le utilizzerà laddove appropriato. Questa può essere una differenza importante in alcuni casi.

Ho scritto un po 'su questo qui:

http://blogs.msdn.com/ericlippert/archive/2009/10/08/what-s-the-difference-between-as-and-cast-operators.aspx

Capisco il tuo punto. E sono d'accordo con la sua spinta: che un operatore del cast comunica "Sono sicuro che questo oggetto può essere convertito in quel tipo e sono disposto a rischiare un'eccezione se sbaglio", mentre un operatore "come" comunica "Non sono sicuro che questo oggetto possa essere convertito in quel tipo; dammi un null se sbaglio".

Tuttavia, c'è una sottile differenza. (x come T). Qualsiasi cosa () comunica "Non so solo che x può essere convertito in una T, ma inoltre che ciò comporta solo conversioni di riferimento o unboxing, e inoltre che x non è nullo". Ciò comunica informazioni diverse da ((T) x). Qualunque cosa (), e forse è quello che intende l'autore del codice.

Ho visto spesso riferimenti a questo articolo fuorviante come prova che "as" è più veloce del casting.

Uno degli aspetti più ovvi e fuorvianti di questo articolo è il grafico, che non indica ciò che viene misurato: sospetto che stia misurando i calchi falliti (dove "as" è ovviamente molto più veloce in quanto non viene generata alcuna eccezione).

Se ti prendi il tempo per fare le misurazioni, vedrai che il casting è, come ti aspetteresti, più veloce di "come" quando il cast avrà successo.

Sospetto che questo possa essere uno dei motivi per l'uso di "cult cult" come parola chiave anziché come cast.

Il cast diretto richiede una coppia di parentesi in più rispetto alla asparola chiave. Quindi, anche nel caso in cui tu sia sicuro al 100% del tipo, riduce l'ingombro visivo.

Concordato sull'eccezione, però. Ma almeno per me, la maggior parte degli usi di si asriduce per controllare in nullseguito, che trovo più bello che prendere un'eccezione.

Il 99% delle volte quando uso "as" è quando non sono sicuro di quale sia il tipo di oggetto reale

var x = obj as T;
if(x != null){
 //x was type T!
}

e non voglio catturare esplicite eccezioni di cast né fare cast due volte, usando "is":

//I don't like this
if(obj is T){
  var x = (T)obj; 
}

È solo perché alla gente piace come appare, è molto leggibile.

Ammettiamolo: l'operatore di casting / conversione in linguaggi simil-C è piuttosto terribile, in termini di leggibilità. Mi piacerebbe se C # adottasse la sintassi Javascript di:

object o = 1;
int i = int(o);

O definire un tooperatore, l'equivalente di casting di as:

object o = 1;
int i = o to int;

Alla gente piace ascosì tanto perché li fa sentire al sicuro da eccezioni ... Come garanzia su una scatola. Un ragazzo offre una garanzia di fantasia sulla scatola perché vuole che tu ti senta tutto caldo e tostato dentro. Credi di aver messo quella scatoletta sotto il cuscino di notte, la Fata della Garanzia potrebbe scendere e lasciare un quarto, vero Ted?

Di nuovo sull'argomento ... quando si utilizza un cast diretto, esiste la possibilità di un'eccezione di cast non valida. Quindi le persone si applicano ascome una soluzione generale per tutte le loro esigenze di casting perché as(di per sé) non genererà mai un'eccezione. Ma la cosa divertente di questo, è nell'esempio che hai dato, (x as T).SomeMethod();stai scambiando un'eccezione cast non valida con un'eccezione di riferimento null. Il che offusca il vero problema quando vedi l'eccezione.

In genere non uso astroppo. Preferisco il istest perché a me sembra più leggibile e ha più senso quindi provare un cast e verificare la presenza di null.

Questo deve essere uno dei miei migliori problemi .

Il D&E di Stroustrup e / o qualche post sul blog che non riesco a trovare in questo momento discute la nozione di tooperatore che affronterebbe il punto sollevato da https://stackoverflow.com/users/73070/johannes-rossel (cioè la stessa sintassi asma con la DirectCastsemantica ).

Il motivo per cui questo non è stato implementato è perché un cast dovrebbe causare dolore ed essere brutto in modo da essere respinto dall'usarlo.

Peccato che i programmatori "intelligenti" (spesso autori di libri (Juval Lowy IIRC)) si aggirino abusando asin questo modo (C ++ non offre un as, probabilmente per questo motivo).

Anche VB ha più coerenza nell'avere una sintassi uniforme che ti costringe a scegliere un TryCasto DirectCaste prendere una decisione !

Credo che la asparola chiave possa essere pensata come una versione dall'aspetto più elegante del dynamic_castC ++.

Probabilmente è più popolare senza motivo tecnico, ma solo perché è più facile da leggere e più intuitivo. (Non dire che rende meglio solo provare a rispondere alla domanda)

Un motivo per usare "as":

T t = obj as T;
 //some other thread changes obj to another type...
if (t != null) action(t); //still works

Invece di (codice errato):

if (obj is T)
{
     //bang, some other thread changes obj to another type...
     action((T)obj); //InvalidCastException
}