forward declaration

Michael wrote:

Je sais ce que c'est qu'une forward declaration, mais je n'ai jamais utilisé.
Quelles sont les applications pratiques?

Elles sont de deux ordres : cela peut éviter l'inclusion d'un .h lorsque
l'on n'a pas besoin de la définition d'une classe :

class A;

class B {
A* a;
//...
};

Ici, on n'a pas besoin d'inclure A.h car on n'a pas besoin de connaître
la définition de A. Donc, on gagne en temps de compilation, notamment.

Et cela est indispensable dans le cas de deux classes qui se réfèrent
l'une l'autre :

class B; // rendu nécessaire par la définition de A qui réfère B

class A {
B* b; // B doit avoir été déclaré.
};

class B {
A* a; // A doit avoir été déclaré
//...
};

--
Arnaud

C'est très clair, merci :)

Arnaud Meurgues wrote:

Michael wrote:

Je sais ce que c'est qu'une forward declaration, mais je
n'ai jamais utilisé. Quelles sont les applications
pratiques?

Elles sont de deux ordres : cela peut éviter l'inclusion d'un
.h lorsque l'on n'a pas besoin de la définition d'une classe :

class A;

class B {
A* a;
//...
};

Ici, on n'a pas besoin d'inclure A.h car on n'a pas besoin de
connaître la définition de A. Donc, on gagne en temps de
compilation, notamment.

Plus que le temps de compilation en soi, on gagne à cause de
l'absence de la dépendance. Une modification de quelque chose
dans la définition de A ne provoque pas la récompilation des
utilisateurs de B.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze wrote on 20/06/2006 09:07:

Plus que le temps de compilation en soi, on gagne à cause de
l'absence de la dépendance. Une modification de quelque chose
dans la définition de A ne provoque pas la récompilation des
utilisateurs de B.

donc "plus qu'en temps de compilation", on gagne en temps "de
recompilation" !

c'est vrai c'est pas pareil ! ;)

Sylvain.

Plus que le temps de compilation en soi, on gagne à cause de
l'absence de la dépendance. Une modification de quelque chose
dans la définition de A ne provoque pas la récompilation des
utilisateurs de B.

donc "plus qu'en temps de compilation", on gagne en temps "de
recompilation" !

Moi j'ai plutôt compris ça comme : « plus qu'en temps de compilation,
on gagne en temps de non compilation ».

c'est vrai c'est pas pareil ! ;)

C'est vrai.

--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)

Sylvain wrote:

kanze wrote on 20/06/2006 09:07:

Plus que le temps de compilation en soi, on gagne à cause de
l'absence de la dépendance. Une modification de quelque chose
dans la définition de A ne provoque pas la récompilation des
utilisateurs de B.

donc "plus qu'en temps de compilation", on gagne en temps "de
recompilation" !

c'est vrai c'est pas pareil ! ;)

On gagne aussi la possibilité d'avoir des dépendances circulaires,
comme dans

class A;
class B { A* a; void foo(A&); };
class A { B* b; void bar(B&); };

Falk

Falk Tannhäuser wrote on 20/06/2006 23:59:

On gagne aussi la possibilité d'avoir des dépendances circulaires,

?!?
Arnauld l'a déjà indiqué.

Sylvain.

On gagne aussi la possibilité d'avoir des dépendances circulaires,
comme dans

class A;
class B { A* a; void foo(A&); };
class A { B* b; void bar(B&); };

A noter qu'on gagne aussi en temps de recompilation :P

--
Vincent

Olivier Miakinen wrote on 20/06/2006 12:04:

Plus que le temps de compilation en soi, on gagne à cause de
l'absence de la dépendance. Une modification de quelque chose
dans la définition de A ne provoque pas la récompilation des
utilisateurs de B.
donc "plus qu'en temps de compilation", on gagne en temps "de

recompilation" !

Moi j'ai plutôt compris ça comme : « plus qu'en temps de compilation,
on gagne en temps de non compilation ».

quitte à insister dans l'erreur ...

soit A.h la définition de A, A.cpp son implémentation, respect. B.h, B.cpp

si B.h n'inclut pas A.h mais référence A*, nécessairement B.cpp inclut
A.h et une modif de celui-ci doit entrainer la recompilation de B.cpp

ne pas inclure une déf. dans une autre def. ne change rien aux
dépendances d'une implémentation.

Sylvain.

Sylvain wrote:

Olivier Miakinen wrote on 20/06/2006 12:04:

Plus que le temps de compilation en soi, on gagne à cause de
l'absence de la dépendance. Une modification de quelque chose
dans la définition de A ne provoque pas la récompilation des
utilisateurs de B.
donc "plus qu'en temps de compilation", on gagne en temps "de

recompilation" !

Moi j'ai plutôt compris ça comme : « plus qu'en temps de
compilation, on gagne en temps de non compilation ».

quitte à insister dans l'erreur ...

soit A.h la définition de A, A.cpp son implémentation,
respect. B.h, B.cpp

si B.h n'inclut pas A.h mais référence A*, nécessairement
B.cpp inclut A.h et une modif de celui-ci doit entrainer la
recompilation de B.cpp

ne pas inclure une déf. dans une autre def. ne change rien aux
dépendances d'une implémentation.

On voit que tu n'as jamais travaillé sur un gros projet.
L'avantage, c'est que les clients d'B, qui incluent B.h,
n'incluent pas indirectement A.h, et une modification de A.h ne
provoque pas leur récompilation. Or, typiquement, A.h voit avoir
un fichier d'implémentation (qui lui doit inclure B.h), mais des
dizaines (voire dans certaines applications des centains) de
clients. Qu'une modification dans l'interface de A provoque la
récompilation des clients d'A, c'est inévitable, étant donné la
façon que fonctionne les systèmes de make actuellement répandus.
En revanche, qu'il provoque la récompilation des clients de B,
parce que B est un client d'A, c'est à éviter -- ce genre de
dépendences s'enchaînent, et on est vite arrivé à un point où la
moindre modification de quoique ce soit provoque la
récompilation de tout.

(Note que techiquement, si j'ajoute une fonction non-virtuelle à
A, il n'y a pas vraiement de raison à avoir à récompiler les
clients d'A qui n'ont changé. Mais les systèmes de make actuel
ne permet pas de faire cette distinction.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34