Bonjour, j'aimerais avoir une classe:
class Matrix <T> where T : // I don't know what to write here { T[][] elements; }
4 Réponses :
Comme je ne suis pas au courant d'une solution intégrée, vérifiez-y:
public abstract class BaseClass { public static BaseClass operator +(BaseClass p1, BaseClass p2) { return p1 + p2; } public static BaseClass operator *(BaseClass p1, BaseClass p2) { return p1 * p2; } } public class ChildClass : BaseClass { } public class Matrix <T> where T : BaseClass { T[][] elements; }
S'il y a une autre classe prenant en charge + code> et
* code> mais n'hérite pas
basoclass code> cela ne fonctionnera pas. Par exemple
int code>
@Default En effet, merci d'avoir souligné cela. J'ai mis à jour la réponse pour ajouter cette restriction.
Peut être de cette façon sera utile pour quelqu'un. Vous pouvez améliorer cela en mettant l'ajout, multiplicez des fonctions dans la classe de la bibliothèque de tissu.
Il suffit de fournir un accès à une propriété comme celle-ci: p> et vous pouvez faire ceci: p>
De cette façon, je ne peux pas donner de la valeur à l'élément (comme 0 ou un nombre, je ne peux également pas les jeter à INT ou à un type non nullable)
Pourriez-vous donner un exemple de ce que vous ne pouvez pas faire?
Je vous recommanderais vivement de jeter un coup d'œil à la bibliothèque "Miscutil" de MM Messrs Skeet et Gravell:
http://www.yoda.arachsys.com/cshaarp/miscutil/ p>
contenu est un incroyable implémentation "opérateurs de mathématiques génériques", qui devrait gérer joliment avec votre tente de créer une classe de mathématiques de matrice générique. Cela me rappelle effectivement (un peu) de python et de la manière dont il gère le référencement des fonctions de l'opérateur directement. P>
(à part à @ jon-Skeet: toute chance de cela en faisant partie de Nuget?) P>
Quelques exemples d'usages de leurs tests: p>
Ce n'est pas possible car le type générique non contraint est supposé être de type mais, les types primitifs (int32, double, etc.) définissent efficacement les opérations arithmétiques en tant que méthodes statiques (en réalité, le compilateur les traite spécialement et génère le code en ligne) et une interface en C # ne peut pas définir des méthodes statiques (bien que la conception du CLR le lui permet de lui permettre). Par conséquent, aucune interface n'est écrite en C # qui satisfait aux exigences de soutenir les opérations arithmétiques; Même si cela pourrait être écrit, les types primitifs ne l'héritent pas, de sorte que cela ne fonctionnerait toujours pas. P> Le résultat final est qu'il n'ya aucun moyen de faire ce que vous voulez en C #. P > Si vous l'essayerez, vous obtenez une erreur similaire à p> si vous faites une recherche sur le Web pour ce message, vous trouverez diverses discussions sur les solutions de contournement possibles . p> p> objet code>, qui ne définit pas les opérateurs arithmétiques. Par conséquent, il semble que vous devez spécifier une interface.
Malheureusement, il n'ya aucune contrainte pour les types qui mettent en œuvre des opérateurs spécifiques. Il y a des solutions de contournement que je n'utiliserais pas personnellement, comme la coulée sur
dynamique code>.
contrainte pour seuls les entiers avec une solution éventuelle étant Convertible
Bien qu'une question intéressante, cela fonctionnerait-il en spécifiant implicitement les types (tels que iCatrix pour
int code> et fmatrix pour
float code>)?