Discussion :

[killwin]

Bonjour,

Je viens de me poser la question suivante : Quand dois-je déclarer mes variables dans ma classe ? Et quand dois-je déclarer mes variables dans mes méthodes ?

Par exemple, dois-je faire ça ?

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
17
18
19
20
21
22
23
24
25
26
27
 
class A {
 
    public :
    A();
    void calcul();
 
    private :
    int i;
 
    void methode0();
    void methode1();
}
 
void A::methode0() {
    i = 2;
}
 
void A::methode1() {
    i+=4;
}
 
void A::calcul() {
    methode0();
    methode1();
    std::cout << i << std::endl;
}

____________

Ou ça ?

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
17
18
19
class A {
    public :
    A();
}
 
int A::methode0() {
    int i = 2;
    return i;
}
 
void A::methode1(int &i) {
    i+=4;
}
 
void A::calcul() {
    int i = methode0;
    methode1(i);
    std::cout << i << std::endl;
}

Merci d'avance, car la déclaration de mes variables je les fait au filling et j'aimerais être méthodique :-)

[ternel]

Cela dépend grandement de l'intérêt de ta variable.
Est-elle une information (interne) sur l'état de l'objet?
Si oui, c'est qu'elle est pertinente dans toutes les fonctions membres, et vaut le coup d'être une variable membre.
Si non, c'est du bruit inutile, qui alourdi la classe.

Les variables membres maintiennent l'état de ton objet. L'état visible et l'état interne.
Par exemple, pour un std::fstream, dans l'état visible, il y a normalement l'état du fichier (ouvert ou non, en lecture ou non, etc), la position actuelle dans le fichier.
Dans son état interne, il y a peut-être un buffer pour soulager le système (l'accès au fichier physique en lui-même est très lent).

[koala01]

Salut,

De manière générale, il est toujours utile de faire en sorte qu'une variable soit utilisable dés sa création, sans avoir d'autres étapes à entreprendre que le seul fait de la déclarer. C'est, du moins, ce qui ressort de l'analyse de Coplien et qui n'a jamais été démenti (il y a d'ailleurs bien peu de chances que ce soit démenti un jour).

Du coup, le meilleur endroit pour initialiser les données membres d'une classe est le constructeur, de préférence en utilisation les listes d'initialisation.

Par contre, la forme canonique orthodoxe de Coplien a été démentie sur plusieurs points, à savoir:

1. le fait qu'il faut forcément un constructeur par défaut (ne prenant aucun paramètre) pour la classe, car un tel constructeur n'a de sens que dans le cadre d'une classe ayant sémantique de valeur. Un constructeur qui soit en mesure d'initialiser correctement toutes les données membres s'avère très souvent bien plus utile.
2. Le fait qu'il faut forcément un constructeur de copie et un opérateur d'affectation, car de tels éléments n'ont aucun sens dans le cadre d'une classe ayant sémantique d'entité.

A décharge de Coplien, on peut faire valoir que, lorsqu'il a émis sa suggestion, on n'avait pas encore pris toute la mesure de la différence qui pouvait exister entre la sémantique de valeur et la sémantique d'entité

[Médinoc]

Et à l'époque, = delete n'existait pas. Il fallait donc systématiquement au moins déclarer un constructeur de copie et opérateur d'affectation, même si c'était juste pour les rendre privés.

[koala01]

Oui, en effet, j'ai été un peu rapide dans ma description