Discussion :

[ttone]

Merci de recadrer (et même de répondre finalement) ce topic.

J'attire l'attention sur un terme ambiguë : "équivalent" ?

Equivelent comment : en terme de conception ? en terme de résultat à la compilation ? en terme de stabilité ?... bref, à préciser si possible.

[Jan Rendek]

J'aurais du écrire 'identique' à la place d'équivalent.

Lorsque tu écris le code suivant:

Code :

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

1
2
3
4
5
6
7
8
class A
{
  void f();
  void g() 
  {
     f();
  }
};

Le compilateur le transcrit le code de la fonction g() comme:

Code :

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

1
2
3
4
void g()
{
  this->f()
}

Pourquoi ? Simplement parce que les fonctions membres non statiques s'appliquent sur des instances de la classe en train de définir. Donc à chaque fois qu'un appel de fonction est présent dans le corps d'une fonction membre ( f() dans l'exemple ), le compilateur regardera s'il n'existe pas une fonction de membre de même nom qui puisse s'appliquer à l'objet courant ('this').

Il y a de rares cas où il est impératif de préciser le 'this'. Mais dans chacun de ces cas, le compilateur protestera s'il est omit. Cela arrive principalement en cas d'héritage multiple (comme cité précédemment) ou lors de la définition de classes template. Cependant ce sont des problèmes un peu plus avancés et, une fois encore, rares.

[ttone]

Pourquoi ? Simplement parce que les fonctions membres non statiques s'appliquent sur des instances de la classe en train de définir

Il y a de rares cas où il est impératif de préciser le 'this'. Mais dans chacun de ces cas, le compilateur protestera s'il est omit

+1 d'après moi.

[ttone]

Une question : si notre projet contient 5 classes, toute instanciée 1 seule fois, est il pertinent de faire des appels statiques ?

Que risque t on en faisant cela ?

[Jan Rendek]

Une question : si notre projet contient 5 classes, toute instanciée 1 seule fois, est il pertinent de faire des appels statiques ?

La question ne se pose pas en ces termes. Si une fonction membre dépend de l'instance sur laquelle elle s'applique, elle ne doit pas être déclarée statique.
A contratio, si elle ne dépend d'aucune des variables d'instances de la classe, elle doit l'être.

Prends par exemple une classe qui représente un point 2D. Elle contient 2 variables d'instance x_ et y_ (l'abcisse et l'ordonnée du point).

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
class Point
{
private:
  int x_;
  int y_;
 
public:
  Point (int x, int y) : x_(x), y_(y)
  { /* EMPTY */ }
 
  int x() {return x_;}
  int y() {return y_;}
 
  static void message()
  {
     cout << "Je suis un point" << endl;
  }
}

Les fonctions membre x() et y() dépendent complètement de l'instance de la classe. Si je crée 2 instances de Point:

Code :

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

1
2
Point origine(0,0);
Point p1(10, 26)

J'aurais bien deux résultats différents à origine.x() et p1.x().
En revanche, la fonction message ne dépend aucunement des variables d'instance de Point. Quelque soit l'instance sur laquelle je l'applique, le résultat sera toujours l'affichage du même message.
C'est pourquoi au lieu de l'appeler sur une instance ( genre origine.message() ), je la déclare 'static' et je peux l'appeler via Point::message().

Ces 2 modes d'appels n'ont pas été crées pour faciliter l'écriture, mais bien pour exprimer 2 concepts de fonctions membres différents.

[ttone]

merci, tu m'as rassuré sur ma compréhension de l'Obj.Dev C++ et j'ai même appris des trucs...



this->isAGoodTopic

[koala01]

Salut, et désolé de faire remonter le topic, mais...

Le seul cas - en dehors des fonctions statiques où il est utile - et nécessaire - d'utiliser la syntaxe Type::fonction, c'est lorsque tu veux appeler explicitement le comportement propre à la classe mère, qu'il s'agisse d'une classe mère directe ou d'une classe "ancêtre"...

Un petit exemple pour bien me faire comprendre:

Soit la classe Mere, qui propose la fonction foo avec un comportement bien à elle comme:

Code :

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

1
2
3
4
5
6
7
8
9
10
class Mere
{
    public:
    /* on se fout pas mal des big fours pour l'exemple :D */
        virtual void foo()
        {
            /* le comportement spécifique au type Mere */
            std::cout<<"comportement spécifique a mere"<<std::endl;
        }
};

et une classe Fille qui "enrobe" le comportement de la classe mère de son propre comportement comme:

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
class Fille
{
    public:
        virtual void foo()
        {
            /* ca, c'est propre à la classe Fille */
            std::cout<<"début du comportement de la classe fille"<<std::endl;
            /* ca, c'est le comportement de la classe Mere que l'on veut
             * AUSSI avoir
             */
            Mere::foo();
            /* et enfin, le reste du comportement de la classe Fille */
            std::cout<<"Et la fin du comportement de la classe Fille"<<std::endl;
        }
};

Lorsque tu va jouer avec ces deux classes, sous une forme proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
int main()
{
    /* une instance de la classe mere */
    Mere m;
    /* une instance de la classe fille */
    Fille f;
    std::cout<<"Jouons avec m"<<std::endl;
    m.foo();
    std::cout<<"et maintenant avec f"<<std::endl;
    f.foo();
    return 0;
}

tu obtiendra l'affichage suivant:

Jouons avec m
comportement spécifique a mere
et maintenant avec f
début du comportement de la classe fille
comportement spécifique a mere
Et la fin du comportement de la classe Fille

Bien sur, il t'appartient de décider si un tel genre de comportement est ce qui t'intéresse

[ttone]

Le seul cas - en dehors des fonctions statiques où il est utile - et nécessaire - d'utiliser la syntaxe Type::fonction, c'est lorsque tu veux appeler explicitement le comportement propre à la classe mère

+1

exemple typique : A hérite de X :

Code :

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

1
2
3
4
5
6
 
X::methode(){
    //autre code
    A::methode;
    //autre code
};

Je code actuellement la GUI d'une appli, pour les méthodes paint() ou les callbacks resized(), c'est un cas récurrent
Et plus généralement pour tous les overlloads (= override + rappel)