Discussion :

[HanLee]

Ca pose des tonnes d'autres problèmes - que faire si tu ne compile que ton fichier cpp et aucun autre ? ou est-ce que le compilateur va trouver le code de la fonction inline ? D'ailleurs, dans quel fichier est-il censé le trouver ? (je rappelle que les options de compilation te permettent de renommer les fichiers .o en sortie de la compilation, donc le compilateur ne peut rien deviner par lui-même).

Ca pourrait être OK si c'est fait an link time, mais avec quel coût ?

Ah mais j'ai pas dit que ça serait simple sur le modèle de compilation actuel, qui est tout de même très vieillot.

Oui je pensais au link time, d'où une passe de préprocessing. Puis tu sais, le link-time c'est quand même très rapide par rapport à la compilation.

OCaml par exemple fait de l'inlining inter-unités de compilations, sachant que les compilateurs d'OCaml ont un modèle de compilation identique au C, à quelques détails près.

[JolyLoic]

Les compilateurs modernes font de l'inlining au link-time (par exemple, option whole program optimisation sous MsDev à partir de la version 8).

Par contre, un des buts initiaux du C++ était de pouvoir s'insérer dans les outils classiques du C, et il ne pouvait donc pas exiger ça d'un compilateur. D'où la contrainte de visibilité du code pour lequel l'utilisateur suggère un inlining.

[méphistopheles]

ne t'amuse pas à faire des fichiers-cpp-qui-ne-sont-pas-des-fichiers-cpp-en-fait. Je te promets que le premier que je trouve dans mon équipe à faire ça se prends une engueulade mémorable et humiliante devant tout le reste de l'équipe par le chef (en l'occurence, moi). Avec changement d'affectation le temps que cette personne apprenne la programmation.

hou là, j'ai rien fait moi!
c'étais juste une question suite à ce qu'avait dit Sylvain Togni:

N'oubliez pas qu'un compilateur n'a aucune notion de .cpp, .h, etc... Il a un fichier à compiler (peut importe son extension) qui en inclue potentiellement d'autres (peu importe leurs extensions). Cela forme une unité de compilation.

Je me demandais si justement, ça changeais quelque chose d'inclure un .ccp.

sinon, j'ai pas eu de formation de C++ (enfin si, le chat de dvp :p) donc j'ai des excuses

pour l'inlining au link time, est-ce que VC++ peut le faire ? (je suis pas adepte de VC++, mais c'est leu seul que j'ai pour l'instant)

merci

[nicroman]

hou là, j'ai rien fait moi!
c'étais juste une question suite à ce qu'avait dit Sylvain Togni: Je me demandais si justement, ça changeais quelque chose d'inclure un .ccp.

Ca change tellement rien qu'un compilo n'a même pas notion des #xxxxxx
Ca c'est le préprocesseur, un truc qui arrive avant même que le compilo ne soit appelé, avec, en entrée, juste une GROS fichier... (enfin... un gros stream de tous les fichiers ).
C'est aussi pour cette raison qu'ont été inventés les headers précompilés...

[gb_68]

Bonjour,
le danger de postfixer un fichier à inclure par ".cpp" c'est que le processus de compilation (makefile qui compile tous les cpp, IDE ...) ne le prenne pour une unité à compiler, ce qui n'est justement pas voulu ici.
Après c'est vrai que le compilateur ne voit que les fichiers de sortie du préprocesseur. On peut d'ailleurs complètement se passer des .h, mais bonjour la lisibilité et les problèmes.
En fait ce système d'inclusion hérité du C n'est à mon sens plus très adapté au C++ avec les fonctions inlines et les templates.

En C (et toujours en C++) on a :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
//Test1.c/cpp ////////////
void Test()
{ /*...*/}
 
//Test2.c/cpp ////////////
void Test()
{/*...*/}
 
//Test3.c/cpp ////////////
void Test();
//utilse Test();

Erreur à l'édition des liens car deux versions Test() possible pour Test3.c/cpp

Code :

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

1
2
3
4
5
6
7
8
9
10
11
//Test1.c/cpp ////////////
static void Test()
{ /*...*/}
 
//Test2.c/cpp ////////////
static void Test()
{/*...*/}
 
//Test3.c/cpp ////////////
void Test();
//utilse Test();

Erreur à l'édition des liens, aucune version de Test() visible pour Test3.c/cpp
Or avec les templates et le fonctions inlines, il faut le code à la compilation, donc ceci est permis (ce type de code résulte aussi de l'inclusion de .h avec des fonctions inlines - mais pas avec deux versions de Hello si on a bien écrit une seul fois la fonction dans un seul .h) :

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
28
29
30
31
32
33
34
35
//TestInline1.cpp ////////////
inline void Hello( const std::string & msg )
{
	std::cout << "Hello " << msg << std::endl;
}
class Test1
{
public:
	Test1()
	{ Hello( "Test1" ); }
};
Test1 test1;
 
//TestInline2.cpp ////////////
inline void Hello( const std::string & msg )
{
	std::cout << "???? " << msg << std::endl;
}
class Test2
{
public:
	Test2()
	{ Hello( "Test2" ); }
};
Test2 test2;
 
//TestUtilise.cpp ////////////
void Hello( const std::string & msg );
class TestUtilise
{
public:
	TestUtilise()
	{ Hello( "Utilise" ); }
};
TestUtilise testUtilise;

Résultat : Hello n'a pu être étendu dans TestUtilise et à l'édition des liens une des deux versions à été prise !

Hello Test1
???? Test2
Hello Utilise

Ce résultat (en Release sous VC++ 2005) n'est possible qu'en mettant Optimisation sur l'ensemble du programme à Non car sinon, en effet, à l'édition des liens Hello est étendu dans TestUtilise et la même version est prise dans TestInline2.cpp !

Hello Test1
Hello Test2
Hello Utilise

[loufoque]

Avec de la génération de code à l'édition de liens, avoir des fonctions inline dans les .cpp ou des définitions de templates dans ceux-ci (export template) ne pose aucun problème.