[migration depuis C++] class pair

Version imprimable

16/01/2008, 13h35
ZaaN

[migration depuis C++] class pair

Hello, je cherche la classe C# correspondant à la classe pair de la STL en C++.

j ai pensé à DictionaryEntry ... ?
merci d'avance.

PS: inutil de me preciser que je peux la reimplementer moi-même.
16/01/2008, 14h04
ced600

Peux tu expliquer ce qu'est une classe pair en C++ ?
16/01/2008, 14h08
SaumonAgile

Il existe une classe Pair perdue au milieu du system.web.ui.
16/01/2008, 14h44
ZaaN

Citation:

Envoyé par ced600

Peux tu expliquer ce qu'est une classe pair en C++ ?

c'est une classe ( struct par dessous je crois) qui comporte juste deux membre independant. Utilisé pour traité deux object en un.

Cela dis, j ai résolu mon problème en utilisant une entrée de dictionnaire
16/01/2008, 14h45
SirJulio

KeyValuePairs<U, V> de Generics ne conviendrait-il pas ?
16/01/2008, 15h03
ced600

Citation:

Envoyé par ZaaN

c'est une classe ( struct par dessous je crois) qui comporte juste deux membre independant. Utilisé pour traité deux object en un.

Cela dis, j ai résolu mon problème en utilisant une entrée de dictionnaire

Merci.

Mais cela ne me semble pas très utile. Enfin ce n'est pas le problème ici.
16/01/2008, 15h05
SaumonAgile

Citation:

Envoyé par ced600

Merci.

Mais cela ne me semble pas très utile. Enfin ce n'est pas le problème ici.

ça peut (pouvait ?) être utile pour une fonction qui doit retourner simplement deux variables.
16/01/2008, 15h10
ced600

Citation:

Envoyé par SaumonAgile

ça peut (pouvait ?) être utile pour une fonction qui doit retourner simplement deux variables.

Donc c'est de la bidouille. Il y en a d'autre pour ce genre de cas :
- Renvoyer un objet.
- Renvoyer une structure.
- Renvoyer 1 variable et modifier l'autre dans la fonction.
- Renvoyer un tableau.
- Et certainement d'autre.

ben de toutes façons c'est assez bidon de réimplémenter une paire générique comme dans la STL...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class Pair<T1, T2>
{
    public Pair(T1 first, T2 second)
    {
        this.First = first;
        this.Second = second;
    }
 
    public T1 First {get; set;}
    public T2 Second {get; set;}
 
    // si besoin réimplémenter les opérateurs etc...
}

16/01/2008, 15h43
SaumonAgile

Citation:

Envoyé par ced600

Donc c'est de la bidouille. Il y en a d'autre pour ce genre de cas :
- Renvoyer un objet.
- Renvoyer une structure.
- Renvoyer 1 variable et modifier l'autre dans la fonction.
- Renvoyer un tableau.
- Et certainement d'autre.

Pour moi ce n'est pas une bidouille, c'est simplement un moyen. Bidouille me donne une impression de quelquechose de sale. Ici ce n'est qu'une solution, elle n'est peut-être pas aussi élégante que des passages par référence, mais n'a pas à rougir face aux autres solutions que tu proposes.
Pour moi, c'est une solution rapide et acceptable : "je dois renvoyer deux valeurs pour cette fonction, il existe un objet fait pour stocker deux valeurs, j'utilise l'objet en question. Fin de la reflexion."

tomlev a aussi raison mais n'a pas lu le premier post ;)

Citation:

PS: inutil de me preciser que je peux la reimplementer moi-même.
16/01/2008, 15h59
ced600

Citation:

Envoyé par SaumonAgile

Pour moi ce n'est pas une bidouille, c'est simplement un moyen. Bidouille me donne une impression de quelquechose de sale. Ici ce n'est qu'une solution, elle n'est peut-être pas aussi élégante que des passages par référence, mais n'a pas à rougir face aux autres solutions que tu proposes.
Pour moi, c'est une solution rapide et acceptable : "je dois renvoyer deux valeurs pour cette fonction, il existe un objet fait pour stocker deux valeurs, j'utilise l'objet en question. Fin de la reflexion."

tomlev a aussi raison mais n'a pas lu le premier post ;)

Bah en fait le passage par référence je le trouve propre et le reste je vois cela comme de la bidouille.
Enfin question de gout et de couleur, inutile que l'on débate dessus d'ailleurs.

Mais bon le passage de variable par référence pour moi existe pour éviter que l'on est à créer un conteneur pour renvoyer plusieurs valeur.
Limite conservant la valeur de retour uniquement comme moyen de savoir si la fonction s'est exécuté correctement.
16/01/2008, 16h04
Guulh

Citation:

Envoyé par ced600

Limite conservant la valeur de retour uniquement comme moyen de savoir si la fonction s'est exécuté correctement.

Et les exceptions, alors !! :)
/me a trop vu de fonctions catchant tout et renvoyant true si aucune exception n'a été levée :aie:
16/01/2008, 16h05
tomlev

Citation:

tomlev a aussi raison mais n'a pas lu le premier post ;)

Oups :oops:
16/01/2008, 17h31
ced600

Citation:

Envoyé par Guulh

Et les exceptions, alors !! :)
/me a trop vu de fonctions catchant tout et renvoyant true si aucune exception n'a été levée :aie:

Une fonction peu considérer que ce qu'elle doit faire ne s'est pas fait correctement sans pour autant qu'il y ai eu une exception levée.
Alors deux choix d'implémentation :
1) levée son exception.
2) renvoyer une valeur d'erreur.
16/01/2008, 18h09
Guulh

Citation:

Envoyé par ced600

Une fonction peut considérer que ce qu'elle doit faire ne s'est pas fait correctement sans pour autant qu'il y ait eu une exception levée.
Alors deux choix d'implémentation :
1) lever son exception.
2) renvoyer une valeur d'erreur.

Certes, je voulais seulement dire que les exceptions sont bien plus puissantes et moins source d'erreur que les codes d'erreur à la C (errno :aie:), et que je pleure des larmes de sang quand je vois du code qui fait un catch(Exception e) { return false;} dans une appli de prod. A part des fonctions style TryGetValue des Dictionary qui en plus de son traitement renvoie true si elle a un entrant ayant la clé donné, la plupart des méthodes du framework signalent un comportement inhabituel (plus précisément ingérable) par une exception plutôt que par un booléen / une enum de retour.
17/01/2008, 11h10
ced600

Code:

catch(Exception e) { return false;}

on a du demander au gars de faire une application qui ne plante pas :mrgreen: