Méthode générique pour la conversion de type

Je suis en train d'écrire générique de la méthode de jeter types. Je veux écrire quelque chose comme Cast.To<Type>(variable) au lieu de (Type) variable.
Ma mauvaise version de cette méthode:

public class Cast
{
    public static T To<T>(object o)
    {
        return (T) o;
    }
}

Et c'est simple test:

public class A
{
    public static explicit operator B(A a)
    {
        return new B();
    }
}

public class B
{
}

A a = new A();
B b = Cast.To<B>(a);

Comme vous l'avez deviné, ce code va échouer avec InvalidCastException.

Est ce code d'échec à cause de la machine virtuelle ne sais pas comment faire pour lancer une variable de type object de type B au moment de l'exécution? Mais le message de l'exception, dit: "impossible de convertir l'objet de type A, de type B". Donc CLR connaît vrai type de la variable o, pourquoi il ne peut pas effectuer de casting?

Et voici la question principale: comment dois-je réécrire la méthode T To<T>(object o) pour résoudre ce problème?

  • Je n'aime pas vraiment l'idée d'un "convertir quoi que ce soit dans un T". Je suppose que je ne connais pas assez bien le C#.
  • Et voici ma question principale: Pourquoi? En quoi est Cast.To<B>(...) plus facile à utiliser que (B)...?
  • JeffN825 explique - méthode fait couramment à l'interface de style d'appel possible. Je ne vois pas d'autres raisons que moi-même...
  • ne vous méprenez pas sur la question, je ne cherche pas à remplacer le traditionnel type de jette, je veux comprendre comment CLR fonctionne et comment résoudre le problème décrit.
  • Ah, si c'est juste une question de mieux comprendre le CLR, je peux les comprendre.
InformationsquelleAutor xzt | 2011-07-22
  1. 12

    Si vous pouvez utiliser c# 4.0 cela fonctionne:

    namespace CastTest
{
    internal class Program
    {
        private static void Main(string[] args)
        {

            A a = new A();
            B b = Cast.To<B>(a);
            b.Test();

            Console.Write("Done.");
            Console.ReadKey();
        }

        public class Cast
        {
            public static T To<T>(dynamic o)
            {
                return (T)o;
            }
        }

        public class A
        {
            public static explicit operator B(A a)
            {
                return new B();
            }
        }

        public class B
        {
            public void Test()
            {
                Console.WriteLine("It worked!");
            }
        }

    }
}
    • Merci pour la résolution de problème principal!
    • ce qui est intéressant - ce qui est dynamic fais ici?
    InformationsquelleAutor CodingGorilla
  2. 15

    Tout ce qui a été dit à propos de l'opérateur de résolution est correcte...mais c'est ma réponse à votre question principale:

        public static T To<T>(this object o)
    {
        return (T)(dynamic)o;
    }

    La clé ici est que la coulée o dynamique de la force de l' .NET pour la recherche explicite de l'opérateur au moment de l'exécution.

    Plus, pourquoi ne pas en faire une méthode d'extension?

    Au lieu de

            A a = new A();
        B b = Cast.To<B>(a);

    vous pouvez faire

            A a = new A();
        B b = a.To<B>();

    Un avantage supplémentaire de l'exposer comme une extension de la méthode est que, vous acquérez une interface fluide pour une conversion explicite (si vous aimez ce genre de chose). J'ai toujours détesté le montant de la parenthèse imbriquée équilibrage requis pour une conversion explicite dans .NET.

    De sorte que vous pouvez faire: 

    a.To<B>().DoSomething().To<C>().DoSomethingElse()

    au lieu de 

    ((C)((B)a).DoSomething())).DoSomethingElse()

    qui, pour moi, semble plus claire.

    • Nooon! Veuillez ne pas introduire de dynamic ici! Il n'est pas exagéré, c'est EXAGÉRÉ :))
    • Méthode d'Extension est une bonne idée si vous allez seulement à faire avec une poignée de classes, mais plus que quelques ferait beaucoup de travail.
    • +1: tirer parti de la dynamique... génie!
    • Le coût est beaucoup trop pour un simple cast...
    • J'aime le fait de disposer d'une méthode d'extension car il signifie que vous exposer une interface fluide pour une conversion explicite (j'ai toujours détesté le montant de la parenthèse imbriquée équilibrage requis pour une conversion explicite dans .NET. De sorte que vous pouvez faire: un.≪B>().DoSomething().≪C>().DoSomethingElse() au lieu de ((C) (B)).DoSomething())).DoSomethingElse
    • Pourquoi quelqu'un downvote cela?
    • +2/-0. Ils sont juste pris upvotes loin.
    • Yep, je sais à propos de la méthode d'extensions. Pour être honnête, ce problème générique de la conversion de type est né exactement quand je veux plus propre syntaxe pour les jette comme vous l'avez dit ci-dessus. Je suis d'accord avec vous, ici, et je n'aime pas non plus des tonnes de parenthèse et que vous voulez écrire quelque chose comme a.To<B>(). Mais la méthode extensions sont point discutable et l'application de celles de object type n'est pas une bonne idée.
    • Bien sûr, la surutilisation de l'extension des méthodes appliquées pour le type d'objet n'est pas une bonne idée...mais je dirais que c'est le casting est plus que ok.
    • Pourriez-vous expliquer plus sur l'utilisation du mot-clé dynamic ici ? Ive a regardé autour et a tout juste réussi à trouver que le cast explicite nécessite un opérateur qui n'est que...

    InformationsquelleAutor Jeff
  3. 4

    Vous pouvez faire ce truc, trouver les bonnes méthodes à travers la Réflexion:

    public static T To<T> (object obj)
{
    Type sourceType = obj.GetType ();
    MethodInfo op = sourceType.GetMethods ()
                    .Where (m => m.ReturnType == typeof (T))
                    .Where (m => m.Name == "op_Implicit" || m.Name == "op_Explicit")
                    .FirstOrDefault();

    return (op != null)
        ? (T) op.Invoke (null, new [] { obj })
        : (T) Convert.ChangeType (obj, typeof (T));
}

    Dans .NET 4.0, vous pouvez utiliser dynamic mot-clé comme suggéré dans d'autres réponses.

    • Merci pour la Réflexion de la solution. Mais ce n'est pas vraiment complet. Je n'ai plus de test pour votre: double d = 1.5; int i = Cast.To<int>(d);. Ceci ne fonctionnera pas avec InvalidCastException.
    • bonne prise 🙂
    • fixe maintenant.
    • bon, il fonctionne.
    • Meilleure solution. Thx !
    InformationsquelleAutor Dan Abramov
  4. 2

    Votre Cast.To<T>() est juste d'essayer d'interpréter la référence à l'objet donné en référence à T. Qui tombe en panne en cours.

    Et si le compilateur rencontre (B) a et sait que a est de type A et le type A a au moment de la compilation opérateur de conversion de type B - il émet de cette distribution. Ce n'est pas votre cas.

    • Merci pour l'explication sur l'opérateur de résolution au moment de la compilation. Vous avez répondu à ma première question.
    • Voici la référence de C# spec (un peu obsolète, mais pas de changements importants liés à notre discussion ici ont été faites depuis): msdn.microsoft.com/en-us/library/aa691370%28v=vs.71%29.aspx
    InformationsquelleAutor Ivan Danilov
  5. 1

    Instance a est un objet au moment de la coulée de B. Pas A type, mais object. Ainsi, il est impossible de jeter object à B en raison de CLR ne pouvez pas savoir, que o contient explicite de l'opérateur.

    EDIT:

    Ouais! Voici la solution: 

    public class Cast
{
    public static T1 To<T1>(dynamic o)
    {
        return (T1) o;
    }
}

    Maintenant CLR sait, que o est une instance de type A et peut appeler l'explicite de l'opérateur.

    • N'est pas correcte. Il est possible de jeter object à B. Si object variable contient l'instance de B. Il est impossible de déterminer s'il est nécessaire pour appeler à la conversion explicite de la méthode de jeter donné object à B - c'est vrai.
    • vous ne comprenez pas @DotNET point: c'est que l'explicite de l'opérateur est enregistrée en fonction de A et pas object.
    • Toutefois, cela ne fonctionne toujours pas. Il en résultera l'erreur du compilateur, Cannot convert type 'T2' to 'T1'. C'est parce que l'opérateur de résolution de surcharge se produit au moment de la compilation et lorsque le Cast classe est compilée, T1 est seulement object et donc ne parvient toujours pas à ramasser le convertisseur.
    • est correcte, DotNET est correcte, il a juste légèrement erronés elle.
    • Woll: Il semble que ce soit un jeu de mots. Par "casting" je veux dire obtenir la valeur de type B à partir de la valeur d'un autre type. Et ne pas appeler opérateur de cast.
    • est correcte qu'il est toujours pas travailler, parce qu'au moment de la compilation, le compilateur ne peut pas garantir que T2 a le bon opérateur nécessaire pour effectuer la conversion.
    • Vraiment, j'ai eu tort.
    • Fait intéressant, même si vous ajouter les where clauses ( where T2 : A where T1 : B ) toujours n'autorise pas la distribution. Il doit y avoir quelques petites règles à propos de ce genre de chose dans le langage C# spec. Eric ou Jon, où êtes-vous? 😉
    • Je ne pense pas que le compilateur ne fait que beaucoup de travail pour rechercher les classes pour voir si elles sont compatibles opérateurs, semble que ce serait beaucoup de travail sur le compilateur de côté.
    • Woll: que faire si vous avez Un dérivé d'une qui a différents opérateurs de casting? Générique restrictions sont juste de ne pas garantir corriger les choses.
    • À l'aide de dynamic type n'est pas garante de corriger des choses 🙂
    • Oui, mais vous êtes le dire explicitement au compilateur qu'il doit effectuer des contrôles lors de l'exécution. Et donc c'est de la compilation. Sans dynamique si il compile - elle juste ne peut pas jeter des choses. À l'exception de ceux de votre opérateur de cast des lancers de cours.
    • Oui, absolument.

    InformationsquelleAutor Sergey Metlov
  6. 1

    Vous ne serez jamais obtenir que cela fonctionne sans un "convertisseur de type'(un processus manuel de la cartographie à travers les attributs pour tous les types connus qui ne sera tout simplement pas se produire). Vous ne peut tout simplement pas juste lancer un non-liées à la classe de béton à l'autre. Il serait briser le modèle d'héritage simple (qui est celui de la définition des principes de la programmation orientée objet - lire sur "le Diamant Problème")

    Il a également été noté sur les interfaces (polymorphisme) - les deux classes de dériver à partir de la même interface (qui est dans le même sens)

    • Le diamant problème est uniquement un problème touche un peu ces choses. Ici, il est tout au sujet de système de type et de type de sécurité. L'un de ces types de pourrait être interfaces, btw. Quel est donc alors avec de l'héritage simple? 🙂
    • Qu'entendez-vous par TypeConverter? L'OP t ont un type d'utilisateur opérateur de conversion enregistrés. Si vous avez réellement dire System.ComponentModel.TypeConverter qui semble à côté de la question que c'est la question de la langue, pas une API en question.
    • Je pense que TypeConverter a été mentionné ici, car de principe plutôt qu'en raison de la mise en œuvre concrète. Vous devriez vraiment avoir une telle classe, si vous avez besoin de convertir des classes à partir de différentes parties de la hiérarchie de classe. Donc TypeConverter point semble correct pour moi.
    • J'ai modifié pour inclure l'expression concrète de la classe d'Ivan et oui type de convertisseur est conçu dans le terme générique de mappage des attributs de l'autre côté (ce qui nous obligerait à le faire pour tous, connus et inconnus, des types de ce qui est évidemment impossible).
    • J'ai peur de ne pas comprendre comment le problème décrit et unique modèle d'héritage se croisent ici. Mais je crois que j'ai compris de vos pensées sur le "convertisseur de type". Je suis d'accord avec votre dans ce cas, en utilisant IConvertible ou TypeConverter ou de la coutume "convertisseur de type" ne sera pas une mauvaise idée.
    • Weeell, je pense tout de même que le Diamant problème n'a rien à faire ici, mais avec vos dernières modifications que j'ai pris mon -1 loin.

    InformationsquelleAutor Paul Sullivan
  7. 1

    En fait, j'ai rencontré ce problème plusieurs fois et qu'il n'a pas l'impression de la programmation orientée objet "sale" quand je peux me limiter à des types de mise en œuvre de la IConvertible interface. Ensuite, la solution devient réellement très propre!!

    private T To<T>(object o) where T : IConvertible
{
    return (T)Convert.ChangeType(o, typeof(T));
}

    J'ai utilisé une variante de cela, lorsque j'ai par exemple écrit un générateur de jetons, où l'entrée est une chaîne, mais où les jetons pourrait être interprété comme les deux chaînes de caractères, entiers, et en double.

    Puisque c'est à l'aide de la Convert classe, le compilateur va effectivement avoir des renseignements pour savoir quoi faire. Ce n'est pas seulement un simple cast.

    Si vous avez besoin d'encore plus de façon générique de casting, je me demande si ce n'est pas plutôt un problème de conception dans le code. Je pense à un problème avec l'élargissement de la portée de ces choses, c'est que les zones plus vous essayez de couvrir, le plus il sera difficile pour un étranger de savoir combien la méthode peut faire.

    Je pense qu'il est de la plus haute importance que le casting fonctionne vraiment quand quelqu'un écrit de façon explicite une méthode de travail afin d'éviter une situation comme Add(x, y) que pour certaines valeurs de x et y.

    Je pense que l'attente est différente si vous essayez de la coulée de vous-même, comme dans T1 x = (T1) T2 y. Ensuite, je pense que c'est plus apparente que vous êtes vraiment sur votre propre, puisque vous venez de faire quelques fonte plutôt qu'une "couverture de toutes les distributions de la méthode".

    Dans ce cas, il est clair que c'est précisément affaire à des objets de mise en œuvre IConvertible et le développeur peut supposer qu'il marchera bien avec l'un de ces objets.

    Peut-être orientée objet-philosophie lourds réponse que tout le monde ne sera même d'accord avec, mais je pense que ces sortes de "questions d'ordre conceptuel" finissent souvent dans la philosophie de programmation.

    InformationsquelleAutor Jonas
  8. 0

    Peut-être pas ce que tu dois faire exactement, mais qui fonctionne:

    public class Cast
{
    public static targetType To<soureType, targetType>(object o)
    {
        return (targetType)((sourceType) o);
    }
}

    Mais bien, une telle méthode semble inutile pour moi...

    • Wow. +1 juste pour l'exemple. Il semble que c'est un problème dans ce sujet 🙂 Mais vous avez raison. Il est lent et inutile.
    • Wow, arrêter. J'ai raté le problème ici 🙂 C'est le même que le premier DotNET tentative. Le compilateur ne sait pas d'une façon de jeter sourceType à targetType. Aaaargh! Votre +1 est verrouillé maintenant, je ne peux pas revenir en arrière. Vous avez de la chance, inattentif moi))
    • Ce n'est pas vraiment la même chose, vous devez fournir le type réel de l'objet (sourceType) et le type de cast. Cela implique sourceType peut être explicitement exprimés pour le type de cible. C'est le même que public static T1 To<T1, T2> (T2 o) { return (T1) o; }
    • Avec mon premier exemple, vous ne A a = new A (); B b = Cast.To<A, B> (a);. Il fonctionne, mais il est inutile.
    • Non, il ne peut pas. Au moment de la compilation pour le compilateur de ces deux types génériques. Imaginez que A et B sont placées dans différentes assemblée. Et le compilateur ne sait pas si la conversion de sourceType à targetType existe parce que les usages pourrait être pas encore écrit. Et il dit (copie&coller à partir du réel compilateur): "Impossible de convertir le type 'sourceType" à "targetType'". Période.
    InformationsquelleAutor Johnny5