Problème avec generic et appel de méthode

Bonjour,

je veux écrire :

Code:

---

1 2 3 4 5 6 7 8

public class Essai<T> { Essai() { T t; T.TryParse( "2.3", t ); } }

---

Sachant que tous mes T auront une méthode TryParse (par exemple Essai<long>, Essai<DateTime>)

J'ai l'erreur 'T' is a 'type parameter', which is not valid in the given context.

Comment faire ? Merci.

deux erreurs :

les contraintes sur ton type T!
l'appel de tryparse qui etais fais avec T et non t!

il faudra aussi penser à instancier ton objet t dans ton exemple !
ca va te faire un nullrefexecption sinon.

Code:

---

1 2 3 4 5 6 7 8

public class Essai<T> where T : InterfaceQuiImplementTryParse, new() { Essai() { T t = new T(); t.TryParse( "2.3", t ); } }

---

Salut et merci pour ta réponse, mais on écrit bien :

Code:

---

1 2 3 4 5 6

DateTime date; DateTime.TryParse( "2.3", out date );   // Ou alors long l; long.TryParse( "2.3", out l );

---

Ma seule erreur (hormis l'erreur que m'a donné visual plus haut) c'est d'avoir oublié le mot clef out dans l'appel à TryParse.

Mon exemple ne teste pas le retour de l'appel qui pourtant échouerait dans les deux cas, mais c'est juste un exemple.

J'avais pensé à la contrainte ITryParse mais DateTime et long n'utilisent pas d'interface pour cette méthode et je ne veux pas avoir à utiliser un wrapper.

En C++ ce que je veux faire est possible mais en C# je doute.

Citation:

---

Envoyé par NiamorH

Comment faire ? Merci.

---

C'est simple : tu peux pas, parce que TryParse est une méthode statique, et que rien ne relie plusieurs types qui ont une même méthode statique.
C'est un bon exemple de ce qui distingue les generics C# des templates C++ ; les uns se basent en partie sur la POO pour déterminer statiquement si le code est correct, les autres sont des macros au typage faible.

ok c'est bien ce qui me semblait.

Je pense que je peux m'en sortir par la reflexion cependant.

Une remarque HS : je ne crois pas qu'on puisse qualifier les templates C++ de typage faible. Les templates permettent justement de renforcer le typage face et de vieilles habitudes comme les void*. Les generics C# ont cependant un typage encore plus fort, ce qui ne m'arrange pas trop d'ailleurs, mais je suppose qu'il y a des contraintes techniques derriere celà.

Citation:

---

Envoyé par NiamorH

Une remarque HS : je ne crois pas qu'on puisse qualifier les templates C++ de typage faible.

---

Ce que je voulais dire, c'est que quand on écrit un template de méthode sur un type T, on a aucune information sur ce type T. je me souviens plus de la syntaxe exacte, mais on peut écrire en C++ un truc du style :

Code:

---

template<typename T> T Add(T t1, T t2) { return t1 + t2; }

---

Et c'est après, si on appelle Add sur un type qui n'a pas d'opérateur +, qu'une erreur de compilation (bien indigeste, d'ailleurs, vivement C++0x et sa jolie syntaxe) apparaît. Alors qu'avec les generics et leurs contraintes (mot-clé where), une méthode générique valide est valide tout le temps.

Je sais pas si je me fais bien comprendre mais je fatigue :aie:

Oui on est d'accord sur tous ces points. C'est juste que ça m'écorche l'oreille droite d'entendre que les templates C++ font du typage faible ;)

Les erreurs de type (bien indigestes pour un novice je te l'accorde) sont bel et bien détectées à la compil, donc -> typage fort.

Maintenant il y a fort et FORT et C# c'est plutôt FOOOORT tu vois ce que je veux dire ?

Citation:

---

Envoyé par NiamorH

Maintenant il y a fort et FORT et C# c'est plutôt FOOOORT tu vois ce que je veux dire ?

---

Bah disons que typage fort / faible est pas une expression super précise à la base :) Tu peux faire du code cradingue en C++ avec des dynamic_cast et reinterpretcast de partout qui court-circuitent le modèle objet de la syntaxe C++. Alors que C# ne traine pas le boulet du C et peut limiter les conversions de type sauvages.

Mais bref, on est d'accord :)

C'est vrai, tu peux faire des casts bizares en C++, mais C# aussi a les même problèmes :

Code:

---

long l = (long)(object)new DateTime();

---

Ce code ne donnera une erreur qu'à l'éxécution.

Si on veut revenir au sujet qui sont les generics, ils permettent à mon sens une meilleure compréhension de l'utilisateur de la classe, qui sait quel type d'objets il doit fournir, mais du coup on perd en flexibilité.

Citation:

---

Envoyé par NiamorH

Ce code ne donnera une erreur qu'à l'éxécution.

---

Ca tombe bien, c'est ce qu'on veut ! Heureusement qu'on peut faire du downcast quand même :)
Ce que je veux dire, c'est qu'en C++, avec les casts qui vont bien, tu dois pouvoir convertir un (Type1 *) en (Type2 *) et te servir de la zone mémoire que t'avais allouée comme étant Type1 comme si c'était un Type2. Même s'il n'y a pas de lien d'héritage entre les deux. En C#, c'est impossible, tu peux pas "réinterpréter" une zone mémoire. (p't'êt en code unsafe, mais j'ai jamais eu besoin de tester :))

Citation:

---

Envoyé par Guulh

(p't'êt en code unsafe, mais j'ai jamais eu besoin de tester :))

---

Effectivement, il faut passer par du code non managé. Par rapport au C++, ça a le gros avantage de prévenir l'utilisateur que ce qu'il fait risque de lui péter à la tronche (ou plutôt de corrompre sa mémoire sans qu'il s'en aperçoive). Du coup un développeur C# débutant préfèrera ne pas y toucher et c'est un bon point.

Code:

---

1 2 3 4 5 6

unsafe { long l = new long(); DateTime* dt = (DateTime*)&l; MessageBox.Show( dt->Date.ToString() ); }

---

Même si c'est beaucoup plus simple de se tromper en C++, j'avoue avoir rarement besoin de faire des reinterpret_cast et même des cast sur les pointeurs (hormis pour de l'optimisation poussée ou bien pallier à des incohérences des MFC ou de Win32).
Les static_cast et dynamic_cast sont en général les plus utilisés et sûrs d'utilisation.