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