Séparer prototypes et définitions

Version imprimable

01/03/2010, 13h18
Invité

Séparer prototypes et définitions

Bonjour,

J'aimerais savoir s'il est possible de séparer prototypes (.hpp) et définitions (.cpp) des méthodes inline; templates; et virtuel d'une classe A.

Certains disent que c'est possible, d'autre le déconseillent fortement. Qu'en pensez vous ? Merci d'avance pour vos réponse.
01/03/2010, 13h41
méphistopheles

la plupart des compilateurs ne le gèrent pas. de toutes façon, les fichier .cpp servent surtout pour moi à être compilé indépendamment, ce qui n'est évidemment pas possible pour un template ou une fonction inline.

Bref. Le plus simple est pour moi, c'est de mettre tes définitions dans un autre .hpp que tu include dans le .hpp de ta classe principale si tu veux les séparer...

Bonne chance ;)
01/03/2010, 13h42
koala01

Salut,

C'est possible pour les fonction inlines et pour les fonctions de classes template, mais sous certaines conditions

C'est très fortement recommandé pour les fonctions virtuelles.

Les conditions auxquelles il est possible de définir les fonctions inline et les fonctions de classes template sont identiques (parce qu'elle suivent un raisonnement sensiblement): le code d'implémentation doit être disponible pour chaque appel de la fonction.

En effet:
Pour implémenter l'appel d'une fonction inline, le compilateur doit... disposer du code de la dite fonction afin de remplacer l'appel.

En ce qui concerne les fonctions de classes template, le compilateur ne peut pas créer le code exécutable correspondant tant qu'il n'a pas connaissance de la taille... de tous les types utilisés pour paramétrer les fonctions, chose qu'il ne peut avoir que... quand on crée effectivement une instance particulière (dans le sens de "paramétrée avec un ou des types particuliers) de la classe.

Note que, quoi qu'il en soit, tu devra expliciter le fait que les fonctions sont inlines, si tu le fais de cette manière ;)

Enfin, en ce qui concerne les fonctions virtuelles, le propre de ces fonctions est de passer par la vtable de la classe parent, et elles ne peuvent donc pas être inline.

De plus, si tu place leur définition ailleurs que dans un fichier d'implémentation séparé, tu auras beau les entourer de tous les gardes anti inclusion multiple que tu voudra, tu arrivera au mieux à éviter qu'elles soient définies deux fois dans la même unité de compilation, mais tu aura le plus grand mal à éviter qu'elles ne soient définie dans plusieurs unités de compilation (même si ce n'est qu'une seule fois par unité de compilation).

Quoi qu'il en soit, la règle de la définition unique sera bafouée, et l'éditeur de liens ne sera plus en mesure de faire son travail correctement ;)

Merci pour vos réponse,

Mais si j'ai dans un même fichier (A.hpp) les prototypes et définitions (toujours séparé) d'une même classe A :
Code:

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 28 29 30 31 32 33 34 35 36 37 38 39 40 #ifndef FILE__A #define FILE__A class A { public: A(); bool uu() inline int tt(); template<typename T> T ch(T h = 0); protected: bool u; int t; int c; }; A::A() : u(true), t(8), c(1) { } bool A::uu() { return u; } inline int A::tt() { return t; } template<typename T> T A::ch(T h) { if(h == 1) return h + c; } #endif //FILE__A
Et que j'ai deux fichiers sources (.cpp) qui incluent ce même fichier. Il ne risquent pas d'avoir un problème de linker ? Comment faire dans ce cas "particulier" ?

Merci encore ;)

Citation:
Envoyé par Abdelite
Merci pour vos réponse,

Mais si j'ai dans un même fichier (A.hpp) les prototypes et définitions (toujours séparé) d'une même classe A :
Code:

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 28 29 30 31 32 33 34 35 36 37 38 39 40 #ifndef FILE__A #define FILE__A class A { public: A(); bool uu() inline int tt(); template<typename T> T ch(T h = 0); protected: bool u; int t; int c; }; A::A() : u(true), t(8), c(1) { } bool A::uu() { return u; } inline int A::tt() { return t; } template<typename T> T A::ch(T h) { if(h == 1) return h + c; } #endif //FILE__A
Et que j'ai deux fichiers sources (.cpp) qui incluent ce même fichier. Il ne risquent pas d'avoir un problème de linker ?
Non, il n'y a aucun risque...

Pour la fonction inline, comme je l'ai indiqué, le compilateur remplacera la séquence

push des informations sur la fonction appelante
exécution fonction appelée
pop des informations sur la fonction appelante
par... les instructions de la fonction appelée.

Pour les fonctions template, le compilateur doit attendre de savoir à quoi correspond T pour créer le code exécutable en prenant la bonne taille pour représenter ce T... et réagira exactement comme si la fonction avait été déclarée inline

Et cela, il ne peut le savoir que... lors de l'appel de ch... dans la fonction qui y fait appel ;)

Citation:

Comment faire dans ce cas "particulier" ?

Merci encore ;)

Comme tu l'as fait, c'est très bien ;)

01/03/2010, 14h19
3DArchi

Salut,
Le rôle d'inline est double : indiquer que le compilateur peut remplacer l'appel de la fonction directement par son code. Le second rôle est d'indiquer que les différentes définitions n'en sont qu'une (sous réserve que ce soit effectivement la même définition). Le linker ne provoque alors pas d'erreur et une seule fonction est bien générée.

Citation:
Envoyé par Abdelite
Merci pour vos réponse,

Mais si j'ai dans un même fichier (A.hpp) les prototypes et définitions (toujours séparé) d'une même classe A :
Code:

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 28 29 30 31 32 33 34 35 36 37 38 39 40 #ifndef FILE__A #define FILE__A class A { public: A(); bool uu() inline int tt(); template<typename T> T ch(T h = 0); protected: bool u; int t; int c; }; A::A() : u(true), t(8), c(1) { } bool A::uu() { return u; } inline int A::tt() { return t; } template<typename T> T A::ch(T h) { if(h == 1) return h + c; } #endif //FILE__A
Et que j'ai deux fichiers sources (.cpp) qui incluent ce même fichier. Il ne risquent pas d'avoir un problème de linker ? Comment faire dans ce cas "particulier" ?

Merci encore ;)
En théorie il faudrait définir A() et uu() dans un fichier séparé.

Par contre, ta fonction inline sera effectivement redéfinie puisqu'elle sera recopiée à chaque occurrence de son appel, mais c'est effectivement ce qu'on attend d'une fonction inline.

Pour ta fonction Template, Il me semble que le compilateur créera une nouvelle fonction pour chaque jeu de paramètre template différent avec lesquels elle sera appelé, ce qui revien à créer un .cpp a elle ne sera pas définie tant qu'elle n'est pas appvec cette fonction, pour chaque jeu paramètres templates différents avec lesquels tu l'utilise, donc pas de souci :D

Bonne continuation ;)

edit : arf grilled. Par contre, pour les deux non template, ne serait-ce pas mieux de les définir dans un fichier séparé (ou alors le compilo s'en charge ?).

01/03/2010, 14h23
koala01

Citation:

Envoyé par 3DArchi

Salut,
Le rôle d'inline est double : indiquer que le compilateur peut remplacer l'appel de la fonction directement par son code. Le second rôle est d'indiquer que les différentes définitions n'en sont qu'une (sous réserve que ce soit effectivement la même définition). Le linker ne provoque alors pas d'erreur et une seule fonction est bien générée.

Oui, effectivement, tu complète ma réponse en prenant en compte le fait que le fait de déclarer une fonction inline ne fait que demander au compilateur de l'inliner...

Mais cette nuance est surtout importante lorsque l'on parle de performances que l'on croit parfois à tord être supérieure pour les fonctions inline ;)
01/03/2010, 14h30
koala01

Citation:

Envoyé par méphistopheles

En théorie il faudrait définir A() et uu() dans un fichier séparé.

Oui, évidemment... Au temps pour moi... Je m'étais honteusement laissé aveugler par ch et tt :oops:

A() et uu() poseront problème parce que ce ne sont pas des fonctions inline ni considérées comme, et ton éditeur de liens ne se plaindra pas pour ch et tt, mais bien pour A et uu...

Si tu veux vraiment mettre ces deux fonctions particulières dans ton fichier d'en-tête, tu devra les définir au sein même de la définition de ta classe...

Elles seront alors implicitement réputées inline;)
01/03/2010, 14h40
Invité

Merci pour vos réponse, pour ceux à qui ça intéresse, sachez que j'ai posté ce topic, en rapport avec ce topic là : http://www.developpez.net/forums/d88...ement-sources/

Merci encore à vous ;)
01/03/2010, 14h46
méphistopheles

Citation:

Envoyé par koala01

Oui, évidemment... Au temps pour moi... Je m'étais honteusement laissé aveugler par ch et tt :oops:

A() et uu() poseront problème parce que ce ne sont pas des fonctions inline ni considérées comme, et ton éditeur de liens ne se plaindra pas pour ch et tt, mais bien pour A et uu...

Si tu veux vraiment mettre ces deux fonctions particulières dans ton fichier d'en-tête, tu devra les définir au sein même de la définition de ta classe...

Elles seront alors implicitement réputées inline;)

Je me disais aussi ... :mrgreen:
01/03/2010, 14h50
3DArchi

Citation:

Envoyé par koala01

Si tu veux vraiment mettre ces deux fonctions particulières dans ton fichier d'en-tête, tu devra les définir au sein même de la définition de ta classe...

Ou les définir inline comme la fonction générique.
01/03/2010, 15h00
Invité

Citation:

Envoyé par 3DArchi

Ou les définir inline comme la fonction générique.

Un constructeur et une méthode classique inline ? Attendez, repartons de 0, une fonction inline, ça sert bien a gagner en souplesse, je suis embrouillé :'(
01/03/2010, 15h04
3DArchi

Citation:

Envoyé par Abdelite

Un constructeur et une méthode classique inline ? Attendez, repartons de 0, une fonction inline, ça sert bien a gagner en souplesse, je suis embrouillé :'(

inline a 2 objectifs :
1/ indiquer que le compilateur peut remplacer l'appel d'une fonction par son implémentation. Pourquoi ne pourrait-il pas le faire pour un constructeur, un destructeur ou toute autre fonction non générique ? (les seuls cas plus subtils (encore que), sont les fonctions virtuelles nécessitant le type dynamique pour résoudre l'appel).
2/ indiquer que si différentes unités de compilation ont la même définition, alors il faut la considérer comme unique et non pas comme des définitions différentes. En quoi est-ce incompatible avec un constructeur, un destructeur ou toute autre fonction non générique (et même virtuelle, rares cas où virtuel et inline peuvent avoir un sens).
01/03/2010, 15h11
Invité

Et dans mon cas (cf. lien ci-dessus), ce serait, le deuxième objectif :

Citation:

indiquer que si différentes unités de compilation ont la même définition, alors il faut la considérer comme unique et non pas comme des définitions différentes. En quoi est-ce incompatible avec un constructeur, un destructeur ou toute autre fonction non générique (et même virtuelle, rares cas où virtuel et inline peuvent avoir un sens).

Et le premier alors ? Il est aussi remplit... l'appel de mon constructeur va être remplacé par son implémentation, et si j'ai 40 000 fonctions, 4000 constructeur, tous inline ? C'est mon exécutable qui va souffrir...

Il n'y a pas un moyen de contourner cette règle des fonction inline et de remplir que le deuxième objectif cité ?
01/03/2010, 15h19
méphistopheles

Citation:

Envoyé par Abdelite

Il n'y a pas un moyen de contourner cette règle des fonction inline et de remplir que le deuxième objectif cité ?

Ben si, il faut mettre les fonctions non-inline dans un .cpp...
01/03/2010, 15h28
3DArchi

Citation:

Envoyé par Abdelite

Et dans mon cas (cf. lien ci-dessus), ce serait, le deuxième objectif :

Oui.

Citation:

Envoyé par Abdelite

Et le premier alors ? Il est aussi remplit... l'appel de mon constructeur va être remplacé par son implémentation, et si j'ai 40 000 fonctions, 4000 constructeur, tous inline ? C'est mon exécutable qui va souffrir...

inline dans le premier objectif n'est qu'une indication. Le compilateur peut royalement l'ignorer et ne pas la prendre en compte. Mais, cf ci-dessous.

Citation:

Envoyé par Abdelite

Il n'y a pas un moyen de contourner cette règle des fonction inline et de remplir que le deuxième objectif cité ?

Peut être. En fonction du compilateur. Certains compilateurs proposent des options de compilation permettant de mieux 'tuner' les fonctions qui sont effectivement inlinées (disons que ce mot horrible veut dire que la définition remplace l'appel) ou pas.
Par exemple, sous visual, dans les options de compilations C/C++ - Optimisation, à la ligne Expansion des fonctions inline, tu peux préciser /Ob{0|1|2} :

Citation:

Envoyé par MSDN

0 Disables inline expansion, which is on by default.
1 Expands only functions marked as inline, __inline, __forceinline or __inline or, in a C++ member function, defined within a class declaration.
2 Expands functions marked as inline or __inline and any other function that the compiler chooses (expansion occurs at the compiler's discretion, often referred to as auto-inlining).

Idem sous gcc : tu as des options pour contrôler tout ça.
01/03/2010, 15h28
Invité

D'accord, ce fichiers .cpp, devra donc inclure ce fichier .hpp avec la définitions des inlines, templates etc...

Ça revient donc à la même chose que si on mettait les fonctions non-inline à la fin du .hpp non ?

PS : J'utilise MinGW.
01/03/2010, 16h15
Invité

Tient c'est bizare, je remarque que le mot clé inline peut juste être mis dans l'implémentation et pas dans la définition...
01/03/2010, 16h44
koala01

Citation:

Envoyé par Abdelite

D'accord, ce fichiers .cpp, devra donc inclure ce fichier .hpp avec la définitions des inlines, templates etc...

[EDIT]le fichier .cpp devra disposer, quelle qu'en soit l'origine, du code correspondant à tout fonction inline ou template à laquelle il fait appel

Cela peut soit être parce que les fonctions sont définie implicitement inline (dans la définition de la classe), soit parce qu'elles sont définie explicitement inline et en dehors de leurs classes, soit encore grace à l'inclusion du fichier dans lequel elles sont définies
[/EDIT]

Citation:

Ça revient donc à la même chose que si on mettait les fonctions non-inline à la fin du .hpp non ?

Non...

Parce qu'il y a de grandes chances pour qu'un fichier d'en-tête soit inclus dans de nombreux fichiers d'implémentations, et parfois même plusieurs fois...

Imagine simplement une fonction foo qui se trouve dans A.h

A. h est inclu par B.h et par C.h

Si tu dois, pour les besoin de la cause, inclure B.h et C.h dans un fichier D.cpp, A.h est inclus dans D.cpp d'une part à cause de l'inclusion de B.h et, d'autre part, à cause de l'inclusion de C.h.

Dans ce cas, tu ne peut éviter le premier écueil qui est d'avoir deux fois la fonction implémentée dans D.cpp que grâce aux gardes anti inclusion (ifndef A_H ... define A_H ... endif), mais, jusque là, foo peut effectivement n'être implémenté qu'une fois, et l'éditeur de liens peut s'en sortir sans *trop* raler.

Mais si, à coté de D.cpp, tu crées un fichier E.cpp qui inclut le fichier A.h, les gardes anti inclusions multiples n'agissent plus, parce que le compilateur "oublie" tous les symboles qu'il peut avoir créés pour un fichier une fois qu'il a fini de le traiter.

Quand il arrivera à la définition de foo, il créera, pour E.cpp... le code correspondant à foo... Et il ne se plaindra même pas outre mesure...

Par contre, quand l'éditeur de liens (ld, dans ton cas) va passer par là pour relier E.o et D.o (et tous les autres), il va... trouver une implémentation de foo dans E.o et... dans D.o... et il ne saura pas à quelle "version" de foo il doit faire correspondre les appels qu'il rencontre, parce que la règle de la définition unique aura été bafouée.

Le résutat, c'est qu'il sortira sur une erreur en te traitant de tous les noms et... sans avoir créé ton exécutable :P

Merci, tout est clair ^^

Pour résumer, je pourrais donc faire comme ceci :

Code:

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
 
#ifndef FILE__A
#define FILE__A
 
class A
{
	public:
		A();
		bool uu()
		inline int tt();
		template<typename T> T ch(T h = 0);
 
	protected:
		bool u;
		int t;
		int c;
 
};
 
A::A() : u(true), t(8), c(1)
{
 
}
#ifdef IMPLANTE
bool A::uu()
{
	return u;
}
#endif //IMPLANTE
inline int A::tt()
{
	return t;
}
 
template<typename T> T A::ch(T h)
{
	if(h == 1) return h + c;
}
 
#endif //FILE__A

Où je déclare IMPLANTE uniquement dans le main.cpp.

02/03/2010, 13h20
méphistopheles
Citation:
Envoyé par Abdelite

Code:

1 2 3 4 5 6 7 8 9 10 11 A::A() : u(true), t(8), c(1) { } #ifdef IMPLANTE bool A::uu() { return u; } #endif //IMPLANTE

Où je déclare IMPLANTE uniquement dans le main.cpp.
Il me semble qu'il y a deux problèmes : d'une part, à part dans le main, uu() ne sera pas défini donc inutilisable. en plus, là, il me semble que si ton compilateur accepte-ça, uu() sera inline.
quand à ton constructeur, il sera toujours inliné (si accepté)... je ne suis pas sûr que c'est ce que tu cherche à faire...

Citation:
Envoyé par Abdelite
Merci, tout est clair ^^

Pour résumer, je pourrais donc faire comme ceci :
Code:

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 28 29 30 31 32 33 34 35 36 37 38 39 40 41 #ifndef FILE__A #define FILE__A class A { public: A(); bool uu() inline int tt(); template<typename T> T ch(T h = 0); protected: bool u; int t; int c; }; A::A() : u(true), t(8), c(1) { } #ifdef IMPLANTE bool A::uu() { return u; } #endif //IMPLANTE inline int A::tt() { return t; } template<typename T> T A::ch(T h) { if(h == 1) return h + c; } #endif //FILE__A
Où je déclare IMPLANTE uniquement dans le main.cpp.
Non... Parce que le constructeur de ta classe sera, lui aussi, implémenté dans chaque fichier *.cpp dans lequel A.h serait inclus...

Le constructeur n'est jamais qu'une fonction comme les autres à ceci près... qu'il est appelé automatiquement lors de la création d'un objet ;)

Citation:

Envoyé par méphistopheles

Il me semble qu'il y a deux problèmes : d'une part, à part dans le main, uu() ne sera pas défini donc inutilisable. en plus, là, il me semble que si ton compilateur accepte-ça, uu() sera inline.
quand à ton constructeur, il sera toujours inliné (si accepté)... je ne suis pas sûr que c'est ce que tu cherche à faire...

Absolument pas, ni pour le problème évoqué au sujet de uu, ni au sujet du constructeur...

Comme le constructeur n'est pas déclaré inline, il sera implémenté... dans chaque fichier *.cpp incluant (de manière directe ou indirecte) le fichier d'en-tête, et donc, la règle de la définition unique ne sera pas respectée

Et, comme il n'y aurait, effectivement, qu'une seule implémentation de uu, l'édtieur de liens pourrait parfaitement retrouver ses jeunes...

Il y a cependant deux restrictions majeures:

IMPLEMENT doit être défini dans main.cpp avant l'inclusion du fichier d'en-tête de la classe mais
Il faut s'assurer que les gardes anti inclusions multiples soient correctement placés pour éviter... que le ifndef IMPLEMENT ne se retrouve deux fois dans main.cpp du fait des inclusions multiples

Tout cela pour dire que le plus simple est de toujours:

avoir au minimum un duo *.cpp par fichier d'en-tête (dans certains cas, cela peut devenir un quatuor:P)
définir les fonctions non inline ou non template dans le fichier *.cpp
définir, s'il y en a, les fonctions inline ou template dans le fichier d'en-tête ou,
éventuellement définir les fonctions inline ou template dans un fichier séparé (ayant une extension autre que *.h/*.hpp ou que *.cpp) en veillant à ce qu'il soit inclu dans tout fichier où un appel à ces fonction sera effectué
Soit en l'incluant à la fin du fichier d'en-tête
soit en l'incluant après le fichier d'en-tête correspondant dans le ficheir *.cpp

02/03/2010, 14h02
Invité
Citation:
Envoyé par koala01

Tout cela pour dire que le plus simple est de toujours:

avoir au minimum un duo *.cpp par fichier d'en-tête (dans certains cas, cela peut devenir un quatuor:P)
définir les fonctions non inline ou non template dans le fichier *.cpp
définir, s'il y en a, les fonctions inline ou template dans le fichier d'en-tête ou,
éventuellement définir les fonctions inline ou template dans un fichier séparé (ayant une extension autre que *.h/*.hpp ou que *.cpp) en veillant à ce qu'il soit inclu dans tout fichier où un appel à ces fonction sera effectué
Soit en l'incluant à la fin du fichier d'en-tête
soit en l'incluant après le fichier d'en-tête correspondant dans le ficheir *.cpp
Ok, merci pour votre aide les gars ;)
02/03/2010, 14h30
méphistopheles

Citation:

Envoyé par koala01

Absolument pas, ni pour le problème évoqué au sujet de uu, ni au sujet du constructeur...

Comme le constructeur n'est pas déclaré inline, il sera implémenté... dans chaque fichier *.cpp incluant (de manière directe ou indirecte) le fichier d'en-tête, et donc, la règle de la définition unique ne sera pas respectée

Et, comme il n'y aurait, effectivement, qu'une seule implémentation de uu, l'édtieur de liens pourrait parfaitement retrouver ses jeunes...

Autant pour moi, merci pour la leçon (même si ça fait mal :aie:).

bon, je vais retourner sur la doc de mon compilo moi :aie: