Discussion :

[5:35pm]

Bonjour,
je cherche a savoir si il y existe un moyen de stocker des pointeurs de fonctions dans un tableau, de maniere a appeller differentes fonction dynamiquement...
Ces fonctions necessitent aussi des arguments de type different, donc je sais vraiment pas si c'est faisable...

voila

[StormimOn]

Regarde du côté des délégués

[5:35pm]

j'y ai pense, mais, un delegue ne necessite il pas un event?

[StormimOn]

Absolument pas. Les événements sont liés aux délégués c'est vrai (le délégué représente le type de l'événement en fait), mais il n'y a pas besoin d'événement pour utiliser les délégués, heureusement

[5:35pm]

je vois
je veux pas trop en demander, mais, n'ayant jamais utilise un delegate sans events associe, je ne sais pas comment sa marche, si tu as deux trois ligne d'exemple, ce serait cool

[deeal]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
public delegate String MethodDelegue( TypeDeLaMethode XX );

String : tu met le type de retour de ta fonction

donc tu declares la modele de fonction que recevra ton delegate

et apres disant que tu as une classe qui s'appelle TOTO qui a une methode

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
public String Tata(TypeDeLaMethode  variable)
{
 // le code de ta methode
}

// ce que tu veux

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
public static void Main()
{
// code
TOTO MaClasse = new TOTO();// tu cree ta classe
MethodeDelegue DInstance = new MethodeDelegue(MaClass.Tata);
// et la ton "Pointeur de fonction"
 
//
 
 
apres tu appeller ta fonction delegue
TypeDeLaMethode ff = new ....; 
// a modifier seulent le type a passer
String TITI = DInstance(ff);
}

[cinemania]

sur le framework .NET 2.0 la plupart du temps, il n'est pas nécessaire d'utiliser le contructeur du délégué mais simplement de faire

FonctionDelegue handler = this.Fonction;

avec FonctionDelegue le délégué, et Fonction la fonction qui correspond à appeler.
Maintenant c'est sure qu'il est plus propre de l'instancier, mais ce n'est pas obligatoire, 2.0 le fait automatiquement dans la majorité des cas.

[5:35pm]

merci pour les eclairsissement les gars =)
ca y es j'ai capte =)

[Mose]

sur le framework .NET 2.0 la plupart du temps, il n'est pas nécessaire d'utiliser le contructeur du délégué mais simplement de faire

FonctionDelegue handler = this.Fonction;

avec FonctionDelegue le délégué, et Fonction la fonction qui correspond à appeler.
Maintenant c'est sure qu'il est plus propre de l'instancier, mais ce n'est pas obligatoire, 2.0 le fait automatiquement dans la majorité des cas.

Comment ça il ne le fait pas tout le temps ? C'est nul. Comment tu sais si ça marche ou pas ? T'essayes, tu compiles et tu vois ? Quelle bande de charlots chez MS. C'est pas avec ce genre de blague que je vais me mettre au framework 2

[5:35pm]

Comment ça il ne le fait pas tout le temps ? C'est nul. Comment tu sais si ça marche ou pas ? T'essayes, tu compiles et tu vois ? Quelle bande de charlots chez MS. C'est pas avec ce genre de blague que je vais me mettre au framework 2

Je crois que t'as pas compris a ce que Cinemania a explique, parce que ta reaction est vraiment incoherente...
sinon donne moi un seul exemple de compilo qui sait tout detecter... il n'existe aucun compilo qui puisse predire ce qui se passe vraiment a l'execution.
Dans tout les cas, tu passe pas mal de temps a tester/debuguer ton appli

[Mose]

Si si, j'ai compris.
Et je trouve ça complètement idiot de devoir passer par un new dans certains cas et pas dans d'autres. Ca rajoute de la complexité gratuitement, ça rend C# moins intuitif, et ça embrouille les débutants.

Sinon je vois pas bien le rapport avec ton compilo qui sais tout détecter ou pas. Mon problème c'est les liberté qu'on prend avec le langage, qui petit à petit lui font perdre son sens et son côté "carré", indispensable en informatique (à mon humble avis de codeur-psycho-rigide)

Bon, et puis on va éviter le débat "un compilateur n'est pas capable de tout détecter", paske tu te plantes. Renseigne-toi sur un truc qui s'appelle "la méthode B".

[smikar]

sur le framework .NET 2.0 la plupart du temps, il n'est pas nécessaire d'utiliser le contructeur du délégué mais simplement de faire

FonctionDelegue handler = this.Fonction;

avec FonctionDelegue le délégué, et Fonction la fonction qui correspond à appeler.
Maintenant c'est sure qu'il est plus propre de l'instancier, mais ce n'est pas obligatoire, 2.0 le fait automatiquement dans la majorité des cas.

Ah tiens, je ne savais pas qu'il était parfois nécessaire d'instancier explicitement le délégué. Peux-tu me dire dans quelle situation cela peut se produire stp, ça m'intrigue ?

Comment ça il ne le fait pas tout le temps ? C'est nul. Comment tu sais si ça marche ou pas ? T'essayes, tu compiles et tu vois ? Quelle bande de charlots chez MS. C'est pas avec ce genre de blague que je vais me mettre au framework 2

Inutile d'être insultant pour se faire entendre, ça ne fait que décrédibiliser tes messages. Si tu tiens à utiliser ad aeternam le framework 1.x, rien ne t'en empêche : tu passes simplement à côté d'une évolution majeure qui apporte son lot de petites merveilles.

Si si, j'ai compris.
Et je trouve ça complètement idiot de devoir passer par un new dans certains cas et pas dans d'autres. Ca rajoute de la complexité gratuitement, ça rend C# moins intuitif, et ça embrouille les débutants.

C'est mon avis personnel, mais je pense qu'un débutant préférera affecter directement la fonction au délégué, et qu'il saura comprendre sans grande difficulté la "version longue".

Sinon je vois pas bien le rapport avec ton compilo qui sais tout détecter ou pas. Mon problème c'est les liberté qu'on prend avec le langage, qui petit à petit lui font perdre son sens et son côté "carré", indispensable en informatique (à mon humble avis de codeur-psycho-rigide)

Ce n'est pas une liberté néfaste comme tu l'entends. C'est un raccourci qui ne nuit en rien à la lisibilité et n'ajoute pas d'ambiguïté. On essayera simplement de se contraindre à une seule des deux approches pour le même projet, de la même manière que l'on donne des règles sur le nommage des variables, la position des accolades, de l'indentation, etc.

Bon, et puis on va éviter le débat "un compilateur n'est pas capable de tout détecter", paske tu te plantes. Renseigne-toi sur un truc qui s'appelle "la méthode B".

C'était peut-être mal exprimé, mais il parle des erreurs lors de l'exécution, qui ne sont évidemment pas détectables à la compilation (si seulement ), mais il s'agit d'autre chose, on est d'accord.

[deeal]

Bon, et puis on va éviter le débat "un compilateur n'est pas capable de tout détecter", paske tu te plantes. Renseigne-toi sur un truc qui s'appelle "la méthode B".

ah cela je parie
le compliteur fait de son mieux, mais il y'a des erreurs qui n'apparaiterons qu'a l'execution , sinon on aurait tous des programmes une fois compiles ne poseraient aucun problemes

[Mose]

Inutile d'être insultant pour se faire entendre, ça ne fait que décrédibiliser tes messages. Si tu tiens à utiliser ad aeternam le framework 1.x, rien ne t'en empêche : tu passes simplement à côté d'une évolution majeure qui apporte son lot de petites merveilles.

Insultant ? Bah y'a quand même plein de petits problèmes à la con, de trucs à moitié fais qui m'agacent un peu dans le framework. Ca manque d'homogénéité, et le pire c'est que je sais exactement pourquoi : j'ai bossé en très proche collaboration avec MS et leur gestion de projet est loin d'être la meilleure. Mais bon... faudrait faire un nouveau topic pour parler de tout ça...

Un exemple que j'ai rencontré très récemment, dans System.Reflection :
MethodInfo a une propriété 'IsStatic'
FieldInfo a une propriété 'IsStatic'
mais PropertyInfo non... super...
et MemberInfo non plus, alors que ça aurait un sens. Mais passons.

C'est mon avis personnel, mais je pense qu'un débutant préférera affecter directement la fonction au délégué, et qu'il saura comprendre sans grande difficulté la "version longue".

Ouais, mais bon.. va lui expliquer que ça marche dans certains cas et pas dans d'autres.
- "Pourquoi ?"
- "Bah je sais pas".
Maintenant, si toi tu sais, la réponse m'intéresse, et si la justification est bonne, je suis prêt à éditer tous mes posts précédent pour présenter mes excuses.

Ce n'est pas une liberté néfaste comme tu l'entends. C'est un raccourci qui ne nuit en rien à la lisibilité et n'ajoute pas d'ambiguïté. On essayera simplement de se contraindre à une seule des deux approches pour le même projet, de la même manière que l'on donne des règles sur le nommage des variables, la position des accolades, de l'indentation, etc.

Mouaip. Mais là y'a deux écoles. C'est comme les VBistes qui ne comprennent pas pourquoi le C# est case-sentitive. Bah moi je comprend pas pourquoi le VB ne l'es pas. Maintenant, chacun son école. C'est un avis personnel de toute façon, ça ne se discute pas

C'était peut-être mal exprimé, mais il parle des erreurs lors de l'exécution, qui ne sont évidemment pas détectables à la compilation (si seulement ), mais il s'agit d'autre chose, on est d'accord.

Je pense aussi. Ma réaction était ptet un peu exagérée en l'occurence, mais elle valait pour tous les griefs que j'ai contre la politique de gestion de projet de MS et d'imperfection dans leur framework.

[Mose]

ah cela je parie
le compliteur fait de son mieux, mais il y'a des erreurs qui n'apparaiterons qu'a l'execution , sinon on aurait tous des programmes une fois compiles ne poseraient aucun problemes

Tu paries combien ? Je suis sûr de gagner
La méthode B ça s'appelle.
Et non, c'est vraiment pas fait pour faire du haut niveau comme du C#. Faut être assez matheux pour s'en servir. Ce n'est qu'un début, mais c'est l'avenir... et c'est français

Une activité de preuve formelle permet de vérifier la cohérence du modèle abstrait et la conformité de chaque raffinement avec le modèle supérieur (prouvant ainsi la conformité de l'ensemble des implantations concrètes avec le modèle abstrait).

[smikar]

Insultant ? Bah y'a quand même plein de petits problèmes à la con, de trucs à moitié fais qui m'agacent un peu dans le framework. Ca manque d'homogénéité, et le pire c'est que je sais exactement pourquoi : j'ai bossé en très proche collaboration avec MS et leur gestion de projet est loin d'être la meilleure. Mais bon... faudrait faire un nouveau topic pour parler de tout ça...

De mon point de vue, le framework .NET est d'une homogénéité remarquable, même s'il y a certainement quelques améliorations qui pourraient être apportées ici ou là, mais cela est du détail. La perfection n'existe pas, la qualité si. Je n'aime pas voir cracher impunément sans raison fondée, d'où ma réaction.

Mais c'est une question d'opinion et je ne suis pas un fervent défenseur de Microsoft dans toutes les situations. Je ne tiens d'ailleurs pas à polémiquer donc je n'insisterai pas, sans rancune

Mouaip. Mais là y'a deux écoles. C'est comme les VBistes qui ne comprennent pas pourquoi le C# est case-sentitive. Bah moi je comprend pas pourquoi le VB ne l'es pas. Maintenant, chacun son école. C'est un avis personnel de toute façon, ça ne se discute pas Je pense aussi.

Je n'essayerai pas de te faire changer d'avis non plus (d'ailleurs je ne pourrais pas travailler sans case-sensitive non plus ).

[Mose]

De mon point de vue, le framework .NET est d'une homogénéité remarquable, même s'il y a certainement quelques améliorations qui pourraient être apportées ici ou là, mais cela est du détail. La perfection n'existe pas, la qualité si. Je n'aime pas voir cracher impunément sans raison fondée, d'où ma réaction.

Pas de pb, mais mes raisons sont fondées. Je bosse sur le framework depuis la version béta, j'ai bossé dans une SSII filiale de MS, où y'avait des anciens de MS, et on a bossé avec des gens encore chez MS, donc je connais pas mal la maison, et je ne critique que parce que je sais pourquoi les choses sont comme ça.

Remarque à la con : vous savez pkoi y'a plein de trucs qui existent en VB et pas en C# (et vice-versa) ? Paske c'est deux équipes de dev complètement séparée qui bossent à moitié en concurrence. Ca vaut le coup de faire une corporation si c'est pour bosser chacun dans son coin...

Bref, sinon pour conclure : je ne suis pas un anti-MS-bête-et-méchant, non, ce qui me dérange c'est les conneries niveau technique, rien de plus