Est-il judicieux d'utiliser «comme» au lieu d'un transtypage même s'il n'y a pas de vérification nulle? [fermé]

Dans les blogs de développement, les exemples de code en ligne et (récemment) même un livre, je continue de trébucher sur le code comme ceci:

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

ou pire encore:

(x as T).SomeMethod();

Cela n'a aucun sens pour moi. Si vous êtes sûr xest de type T, vous devez utiliser une distribution directe: (T)x. Si vous n'êtes pas sûr, vous pouvez utiliser asmais devez vérifier nullavant d'effectuer une opération. Tout ce que fait le code ci-dessus est de transformer un (utile) InvalidCastExceptionen (inutile) NullReferenceException.

Suis-je le seul à penser que c'est un abus flagrant du asmot-clé? Ou ai-je raté quelque chose d'évident et le schéma ci-dessus a-t-il du sens?

Votre compréhension est vraie. Cela ressemble à essayer de micro-optimiser pour moi. Vous devez utiliser un casting normal lorsque vous êtes sûr du type. En plus de générer une exception plus sensible, il échoue également rapidement. Si vous vous trompez sur votre hypothèse sur le type, votre programme échouera immédiatement et vous pourrez voir la cause de l'échec immédiatement plutôt que d'attendre une NullReferenceExceptionou ArgumentNullExceptionou même une erreur logique dans le futur. En général, une asexpression qui n'est pas suivie d'une nullvérification quelque part est une odeur de code.

D'un autre côté, si vous n'êtes pas sûr de la distribution et que vous vous attendez à ce qu'elle échoue, vous devez utiliser à la asplace d'une distribution normale enveloppée d'un try-catchbloc. De plus, l'utilisation de asest recommandée par rapport à une vérification de type suivie d'un plâtre. Au lieu de:

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

qui génère une isinstinstruction pour le ismot - clé et une castclassinstruction pour le casting (exécutant effectivement le casting deux fois), vous devez utiliser:

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

Cela ne génère qu'une isinstinstruction. La première méthode présente un défaut potentiel dans les applications multithread car une condition de concurrence peut entraîner le changement de type de la variable après la isréussite de la vérification et l'échec de la ligne de distribution. Cette dernière méthode n'est pas sujette à cette erreur.

_{La solution suivante n'est pas recommandée pour une utilisation dans le code de production. Si vous détestez vraiment une construction aussi fondamentale en C #, vous pourriez envisager de passer à VB ou à un autre langage.}

Dans le cas où l'on déteste désespérément la syntaxe du cast, il / elle peut écrire une méthode d'extension pour imiter le cast:

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

et utilisez une syntaxe [?] soignée:

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

À mon humble avis, il assuffit d'avoir du sens lorsqu'il est combiné avec un nullchèque:

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

L'utilisation de "as" n'applique pas les conversions définies par l'utilisateur, tandis que la distribution les utilisera le cas échéant. Cela peut être une différence importante dans certains cas.

J'ai écrit un peu à ce sujet ici:

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

Je comprends votre point. Et je suis d'accord avec l'idée maîtresse: qu'un opérateur de cast communique "Je suis sûr que cet objet peut être converti en ce type, et je suis prêt à risquer une exception si je me trompe", alors qu'un opérateur "as" communique "Je ne suis pas sûr que cet objet puisse être converti dans ce type; donnez-moi une valeur nulle si je me trompe".

Cependant, il existe une différence subtile. (x as T). Quoi que () communique "Je sais non seulement que x peut être converti en T, mais en plus, cela implique seulement des conversions de référence ou de déballage, et en plus, que x n'est pas nul". Cela communique des informations différentes de ((T) x). Quoi que (), et c'est peut-être ce que l'auteur du code a l'intention de faire.

J'ai souvent vu des références à cet article trompeur comme une preuve que "as" est plus rapide que le casting.

L'un des aspects trompeurs les plus évidents de cet article est le graphique, qui n'indique pas ce qui est mesuré: je soupçonne qu'il mesure les transformations échouées (où "as" est évidemment beaucoup plus rapide car aucune exception n'est levée).

Si vous prenez le temps de faire les mesures, vous verrez que le lancer est, comme vous vous en doutez, plus rapide que "as" lorsque le lancer réussit.

Je soupçonne que cela peut être l'une des raisons de l'utilisation du mot-clé as par "culte du fret" au lieu d'un casting.

Le casting direct a besoin d'une paire de parenthèses de plus que le asmot clé. Ainsi, même dans le cas où vous êtes sûr à 100% du type, cela réduit l'encombrement visuel.

Mais je suis d'accord sur l'exception. Mais au moins pour moi, la plupart des utilisations de l' asébullition se vérifient par la nullsuite, ce que je trouve plus agréable que d'attraper une exception.

99% du temps quand j'utilise "comme" c'est quand je ne suis pas sûr quel est le type d'objet réel

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

et je ne veux pas intercepter les exceptions de cast explicites ni faire de cast deux fois, en utilisant "is":

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

C'est juste parce que les gens aiment son apparence, c'est très lisible.

Avouons-le: l'opérateur de conversion / conversion dans les langages de type C est assez terrible, en termes de lisibilité. J'aimerais mieux que C # adopte la syntaxe Javascript de:

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

Ou définissez un toopérateur, l'équivalent de casting de as:

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

Les gens aiment astellement parce que cela les met à l'abri des exceptions ... Comme une garantie sur une boîte. Un gars met une garantie de fantaisie sur la boîte parce qu'il veut que vous vous sentiez tout chaud et grillé à l'intérieur. Vous pensez que vous avez mis cette petite boîte sous votre oreiller la nuit, la fée de garantie pourrait descendre et quitter un quart, ai-je raison Ted?

Retour sur le sujet ... lors de l'utilisation d'un cast direct, il existe la possibilité d'une exception de cast non valide. Ainsi, les gens postulent en astant que solution globale à tous leurs besoins en matière de casting, car as(en eux-mêmes) ne lèveront jamais d'exception. Mais ce qui est drôle, c'est que dans l'exemple que vous avez donné, (x as T).SomeMethod();vous échangez une exception de distribution non valide contre une exception de référence nulle. Ce qui obscurcit le vrai problème lorsque vous voyez l'exception.

Je n'en utilise généralement pas astrop. Je préfère le istest car il me semble plus lisible et plus logique que d'essayer un cast et de vérifier null.

Cela doit être l'un de mes coups de cœur .

Le D&E de Stroustrup et / ou un article de blog que je ne peux pas trouver en ce moment traite de la notion d'un toopérateur qui répondrait au point soulevé par https://stackoverflow.com/users/73070/johannes-rossel (c'est-à-dire, même syntaxe que asmais avec la DirectCastsémantique ).

La raison pour laquelle cela n'a pas été implémenté est parce qu'un casting devrait causer de la douleur et être laid, donc vous êtes poussé à ne pas l'utiliser.

Dommage que des programmeurs «intelligents» (souvent des auteurs de livres (Juval Lowy IIRC)) contournent cela en abusant asde cette façon (C ++ n'en offre pas as, probablement pour cette raison).

Même VB a une plus grande cohérence d'avoir une syntaxe uniforme qui vous oblige à choisir un TryCastou DirectCastet faites votre esprit !

Je crois que le asmot - clé pourrait être considéré comme une version plus élégante dynamic_castdu C ++.

Il est probablement plus populaire sans raison technique, mais simplement parce qu'il est plus facile à lire et plus intuitif. (Ne pas dire que cela améliore, juste essayer de répondre à la question)

Une raison d'utiliser "as":

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

Au lieu de (mauvais code):

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