cacher l'implémentation des fonctions inline

Version imprimable

27/08/2012, 19h50
PyNub

cacher l'implémentation des fonctions inline

Bonjour,

je voudrais savoir s'il existe un moyen de cacher l'implémentation des fonctions inline. Apparemment non, puisque on est obligé de définir les fonctions qu'on souhaite inline dans le fichier d'entête. Est-ce à dire que si l'on souhaite cacher la structure réelle de la classe en utilisant un pointeur et en manipulant ce pointeur par l'intermédiaire des méthodes de la classe (comme ça), il faut renoncer au fonctions inline ?

Merci pour vos réponses
27/08/2012, 20h11
Jean-Marc.Bourguet

Les fonctions inline du C++ ne sont là que pour pouvoir avoir l'implémentation visible et faciliter l'implémentation de l'optimisation du même nom. Certains compilateurs sont capables de faire cette optimisation à l'édition de liens, donc sans avoir le code présent dans toutes les unités de compilation, mais les possibilités de contrôles sont spécifiques au compilateur, quand et si elles existent.
27/08/2012, 20h15
PyNub

Merci pour la réponse.

Donc autant laisser faire gcc qui se débrouille très bien tout seul j'ai l'impression...

PS: je n'en suis pas aux templates apparemment le mot clef inline a son utilité dans leurs utilisations
27/08/2012, 20h24
Aleph69

Bonjour,

je ne sais pas si cela répond vraiment à ta question mais tu peux toujours définir tes fonctions inline dans un fichier d'en-tête et l'inclure juste après la définition de ta classe.
27/08/2012, 20h49
PyNub

Citation:

Envoyé par Aleph69

Bonjour,

je ne sais pas si cela répond vraiment à ta question mais tu peux toujours définir tes fonctions inline dans un fichier d'en-tête et l'inclure juste après la définition de ta classe.

Oui bien sûr. Mais si je ne veux pas montrer aux développeurs clients mon code qu'il soit in situ ou hors de la classe dans le même fichier en tête, il apparaitra en clair...
27/08/2012, 21h00
Aleph69

Je ne sais pas si ça fonctionne mais peut-être qu'en déclarant tes fonctions inline lors de la définition de la structure Cheshire (cf ton exemple), donc dans le .cpp, tu obtiendrais ce que tu veux. :question:
27/08/2012, 21h51
PyNub

non ça ne marche pas car le compilateur a besoin de connaître la taille de la fonction lors du linkage.
27/08/2012, 21h54
PyNub

Citation:

Les fonctions inline du C++ ne sont là que pour pouvoir avoir l'implémentation visible

ne s'agit-il pas plutôt d'un effet de bord ?
27/08/2012, 21h57
Jean-Marc.Bourguet

Citation:

Envoyé par PyNub

ne s'agit-il pas plutôt d'un effet de bord ?

Et ce serait quoi alors l'objectif? (Note qu'il y a un "et" dans ma phrase, il aurait pu être "et donc").

Citation:

Envoyé par PyNub

non ça ne marche pas car le compilateur a besoin de connaître la taille de la fonction lors du linkage.

Qu'entends-tu par ça ne marche pas? Par curiosité, j'ai essayé :
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 // Handle implementation #include "Handle.h" // Define Handle's implementation: struct Handle::Cheshire { int i; int toto(int j){return j;}; int titi(int j); }; inline int Handle::Cheshire::titi(int j) { return j; } void Handle::initialize() { smile = new Cheshire; smile->i = 0; smile->i = smile->toto(smile->i); smile->i = smile->titi(smile->i); } void Handle::cleanup() { delete smile; } int Handle::read() { return smile->i; } void Handle::change(int x) { smile->i = x; } ///:~
Chez moi, ça s'exécute. En revanche, je n'ai pas vérifié si le compilateur refusait ou pas les expansions de code.

28/08/2012, 00h30
PyNub

Citation:

Qu'entends-tu par ça ne marche pas?

Je veux dire que le code que tu as cité compile, mais si on essaie de lier le fichier objet obtenu à un programme principal, on obtient une erreur car le compilateur ne connaît pas la taille de la fonction. C'est du moins ce que j'ai testé et il me semble que ça n'a pas marché. Je veux bien ressayé demain cependant. Merci de ton aide en tout cas.

Citation:

Et ce serait quoi alors l'objectif? (Note qu'il y a un "et" dans ma phrase, il aurait pu être "et donc").

Bien justement j'ai voulu dire par "effet de bord" un effet secondaire au but recherché. Le but est de demander au compilateur de rendre inline une fonction, mais avec pour effet secondaire de rendre le code de la fonction inline visible dans le fichier d'entête. Ce qui pour moi, contrevient à ce que j'ai pu apprendre jusque là. Pour moi, un des avantages des classes en C++ était de rendre invisible l'implémentation au programmeur client. Là je suis un peu décontenancé... D'autant que le compilateur que j'utilise (gcc) fais du "inlining" tout seul en fonction des options de compilation, c'est ce qui semble apparaître quand on explore un fichier assembleur généré par gcc avec l'option -O2. J'ai aussi noté que pour obtenir du compilateur l'inlining des fonction précédées du mot clef inline, on doit compiler son code avec l'option -O1, c'est à dire que par défaut gcc ne rend aucune fonction inline, même celle qui ont été spécifiée inline.

Citation:

Certains compilateurs sont capables de faire cette optimisation à l'édition de liens, donc sans avoir le code présent dans toutes les unités de compilation, mais les possibilités de contrôles sont spécifiques au compilateur, quand et si elles existent.

Je viens de relire cette phrase, je l'ai peut-être mal comprise la première fois veux-tu dire :
- certains compilateurs rendent inline des fonctions, qui n'ont pas été déclarées ni définies inline (c'est ce que j'ai compris la première fois)
- ou, il existe des compilateurs qui permettent de rendre inline des fonctions qui ne sont pas définies dans le fichier d'entête mais dans le fichier d'implémentation ?

Dans le dernier cas, j'ai essayé tout à l'heure de déclaré des fonctions dans une classe avec le mot clef inline et les définir avec le même mot clef dans un fichier d'implémentation à part. Bien que la compilation n'ait pas posée de problèmes (puisque, je pense, la classe et son implémentation étaient dans le même fichier du fait de l'inclusion de mon fichier d'entête), en revanche au moment du linkage avec un fichier main utilisant la classe j'ai obtenu une erreur.

Je vais reproduire l'erreur demain et posterai les fichiers et le résultat de leur linkage.

Merci à vous deux pour vos réponses.

Citation:

Envoyé par PyNub

Je veux dire que le code que tu as cité compile, mais si on essaie de lier le fichier objet obtenu à un programme principal on a une erreur car le compilateur ne connait pas la taille de la fonction. C'est du moins ce que j'ai testé et il me semble que ça n'a pas marché. Je veux bien ressayé demain cependant. Merci de ton aide en tout cas.

J'ai pris les trois fichiers Handle.cpp, Handle.hpp et UseHandle.cpp (contenant le main) et j'ai juste posté Handle.cpp puisque c'est le seul que j'ai modifié. Quand j'écris qu'il y a bien exécution du code, c'est au sens où j'obtiens un exécutable qui fonctionne sans erreur (il y a donc bien eu compilation et édition des liens). Maintenant, j'utilise Visual et il peut parfois être permissif donc à tester sous gcc. En particulier, il est possible que tout se passe bien parce qu'il ne fait pas ce que je lui demande (il refuse l'inlining).

Citation:

Envoyé par PyNub

Bien justement c'est ce que j'ai voulu dire par "effet de bord". C'est à dire que le but est de demander au compilateur de rendre inline une fonction, mais avec pour effet secondaire de rendre le code de la fonction inline visible dans le fichier d'entête. Ce qui pour moi, contrevient à ce que j'ai pu apprendre jusque là. Pour moi, un des avantages des classes en C++ était de rendre invisible l'implémentation au programmeur client. Là je suis un peu décontenancé... D'autant que le compilateur que j'utilise (gcc) fais du "inlining" tout seul en fonction des options de compilation.

Si je ne m'abuse, tu peux moralement voir une fonction inline comme une macro; ceci explique cela. A confirmer ou infirmer par les experts du forum quand même! ;)

Citation:

Envoyé par PyNub

Dans le dernier cas, j'ai essayé tout à l'heure de déclaré des fonctions dans une classe avec le mot clef inline et les définir avec le même mot clef dans un fichier d'implémentation à part. Bien que la compilation n'est pas posée de problèmes (puisque, je pense, la classe et son implémentation était dans le même fichier du fait de l'inclusion de mon fichier d'entête), en revanche au moment du linkage avec un fichier main utilisant la classe j'ai obtenu une erreur.

Sauf erreur de ma part, le mot clé inline ne peut pas apparaître dans la déclaration d'une classe et les fonctions inline ne peuvent pas apparaître dans un .cpp, c'est à dire qu'on a
Code:

1 2 3 4 5 6 7 8 class Foo { int toto(int i){return i;} // autorisé int titi(int); // autorisé inline int tata(int); // interdit }; inline int Foo::titi(int i){return i;} // interdit de mettre dans .cpp inline int Foo::tata(int i){return i;} // interdit de mettre dans .cpp
Note : cela est d'ailleurs contradictoire avec la version modifiée de Handle.cpp que je t'ai proposée (fonctions inline dans .cpp) mais vu que la déclaration de la structure est aussi dans le .cpp, je ne sais pas trop quoi en dire. :aie:

28/08/2012, 00h52
PyNub

Citation:

Sauf erreur de ma part, le mot clé inline ne peut pas apparaître dans la déclaration d'une classe et les fonctions inline ne peuvent pas apparaître dans un .cpp,

En effet c'est ce que j'ai fait tout à l'heure c'est pour ça je vais reesayer.

En effet si ça marche pour toi l'erreur devait venir de là... je vérifierai le résultat en assembleur voir si l'inlining se fait bien aussi.

Merci
28/08/2012, 01h07
PyNub
Citation:
Envoyé par Aleph69

Code:

1 2 3 inline int Foo::titi(int i){return i;} // interdit de mettre dans .cpp inline int Foo::tata(int i){return i;} // interdit de mettre dans .cpp
Dans Penser en C++, le livre de l'exemple du cheshire, l'auteur conseille de mettre les déclarations inline dans le fichier d'entête. Ce n'est pas interdit cependant, en tout cas je n'ai pas lu pour l'instant d'interdiction formelle. Ceci dit je ne suis qu'au chapitre 9...
28/08/2012, 01h17
Aleph69

Il me semble avoir essayé de mettre le mot-clé inline dans la déclaration d'une classe et avoir eu des problèmes... mais c'était il y a plusieurs années ma mémoire me fait peut-être défaut. En tous les cas, si tu t'en tiens à ce que dit la faq, tu as bien les deux possibilités de définition que j'ai mentionnées :
http://cpp.developpez.com/faq/cpp/?p...#INLINE_membre
http://cpp.developpez.com/faq/cpp/?p...tre_definition
28/08/2012, 02h52
Jean-Marc.Bourguet

Citation:

Envoyé par PyNub

Bien justement j'ai voulu dire par "effet de bord" un effet secondaire au but recherché. Le but est de demander au compilateur de rendre inline une fonction, mais avec pour effet secondaire de rendre le code de la fonction inline visible dans le fichier d'entête. Ce qui pour moi, contrevient à ce que j'ai pu apprendre jusque là. Pour moi, un des avantages des classes en C++ était de rendre invisible l'implémentation au programmeur client. Là je suis un peu décontenancé... D'autant que le compilateur que j'utilise (gcc) fais du "inlining" tout seul en fonction des options de compilation, c'est ce qui semble apparaître quand on explore un fichier assembleur généré par gcc avec l'option -O2. J'ai aussi noté que pour obtenir du compilateur l'inlining des fonction précédées du mot clef inline, on doit compiler son code avec l'option -O1, c'est à dire que par défaut gcc ne rend aucune fonction inline, même celle qui ont été spécifiée inline.

À nouveau il y a deux points de vue, le language et la génération de code.

Du point de vue du language, les fonctions inline, ça permet de déroger au fait qu'il ne peut avoir plus d'une définition d'une fonction dans un programme, on peut les définir dans plusieurs unités de compilation, on doit même les définir dans chaque unité de compilation qui les utilisent.

D'un point de vue génération de code, le fait qu'une fonction soit inline pour le langage ne veut pas dire qu'elle sera mise en ligne, ni qu'aucune autre fonctions ne le sera. La technique utilisée pour décrire le langage ne permet pas d'exprimer ce genre de contraintes (il y a une règle générale qui permet au compilateur de faire ce qu'il veut tant que le comportement est le même). Un aspect montre clairement qu'il y a une certaine indépendance: le langage permet d'avoir des fonctions inline qui sont récursives.

Oui, le fait qu'une fonction soit inline est une incitation, mais rien de plus. C'est comme avoir des variables register. Il y a des effets sur le langage qui ont été pensés pour permettre une certaine technique, mais le compilateur fait ce qu'il veut.

Citation:

Je viens de relire cette phrase, je l'ai peut-être mal comprise la première fois veux-tu dire :
- certains compilateurs rendent inline des fonctions, qui n'ont pas été déclarées ni définies inline (c'est ce que j'ai compris la première fois)
- ou, il existe des compilateurs qui permettent de rendre inline des fonctions qui ne sont pas définies dans le fichier d'entête mais dans le fichier d'implémentation ?

C'est le premier. Le second fait un programme mal formé.

Citation:

Envoyé par Aleph69

Sauf erreur de ma part, le mot clé inline ne peut pas apparaître dans la déclaration d'une classe et les fonctions inline ne peuvent pas apparaître dans un .cpp

L'inclusion de fichier est juste une inclusion de fichier rien de plus. Tu peux écrire tout dans un .cpp et ne pas faire d'include de fichiers, l'effet est le même.
28/08/2012, 13h58
Aleph69

Bonjour Jean-Marc,

Citation:

Envoyé par Jean-Marc.Bourguet

L'inclusion de fichier est juste une inclusion de fichier rien de plus. Tu peux écrire tout dans un .cpp et ne pas faire d'include de fichiers, l'effet est le même.

Merci pour ces précisions mais comme je ne suis pas un grand spécialiste de ces notions, je ne suis pas sûr de percevoir toute la portée de ton intervention. Je crois comprendre ceci :
1. si tout est dans un .hpp, il n'y a pas de problème;
2. si tout est dans un .cpp, il n'y a pas de problème;
3. s'il y a déclarations dans un .hpp et définitions dans un .cpp, alors les fonctions inline doivent être déclarées et définies dans le .hpp.
Est-ce que tu peux confirmer ou infirmer? C'est pour ma culture personnel! ;)
28/08/2012, 14h10
Jean-Marc.Bourguet

Une fois passe le preprocesseur, il n'y a plus qu'une unite de compilation et les regles du langage s'applique sur l'unite de compilation, la maniere dont le texte etait reparti en differents fichiers n'a aucune importance sur la validite ou non du programme.

Ce qu'il faut, c'est qu'une fonction inline soit definie (et de la meme maniere) dans toutes les unites de compilations qui l'utilisent. Le plus simple est de mettre la definition dans le .hpp qui la declare, mais ce n'est en rien obligatoire. Il est relativement courant quand on adopte l'organisation une classe=un .hpp et un .cpp de ne definir dans le .hpp que les fonctions inline publiques et protegees et definir dans le .cpp les fonctions inline privees qui ne sont pas utilisees par les fonctions inline presentes dans le .hpp.
28/08/2012, 15h43
Aleph69

Merci beaucoup pour ta réponse mais il y a encore une nuance qui doit m'échapper car je ne comprends plus ce qui empêche de cacher l'implémentation de fonctions inline si on peut les définir dans un .cpp.
28/08/2012, 15h51
screetch

Si tu as des fonctions utilisees en interne dans ta bibliotheque, qui ne sont PAS exposees pour un client (juste des fonctions utilitaires pour toi) alors elles peuvent etre en inline, dans des en-tetes (ou dans des sources) que tu ne publies pas.

Si tu as des fonctions que les clients peuvent appeler, alors pour les mettre en inline tu vas devoir donner le code source a tes clients (c'est a dire mettre la fonction inline dans un fichier header ou source, header surement, que tu donnes a tes clients)
28/08/2012, 16h04
Jean-Marc.Bourguet

Citation:

Envoyé par Aleph69

Merci beaucoup pour ta réponse mais il y a encore une nuance qui doit m'échapper car je ne comprends plus ce qui empêche de cacher l'implémentation de fonctions inline si on peut les définir dans un .cpp.

Il faut une definition d'une fonction inline dans toute unite de compilation qui l'utilise. Donc la definition ne peut etre cachee que pour des fonctions qui ne sont pas utilisees par les clients.

D'accord. Donc, si j'ai bien compris, on peut finalement cacher une partie des implémentations en imbriquant des fonctions inline comme ceci :
Code:

1 2 3 4 5 6 7 class Foo { public:int devoile(int); private:int cache(int); }; inline int Foo::devoile(int i){return cache(i);} // ne peut pas être caché inline int Foo::cache(int i){return i;} // peut-être caché
Le client verra effectivement l'implementation de "devoile" mais l'implémentation de "cache" pourra en revanche ne pas lui être montrée. Non?

Citation:
Envoyé par Aleph69
D'accord. Donc, si j'ai bien compris, on peut finalement cacher une partie des implémentations en imbriquant des fonctions inline comme ceci :
Code:

1 2 3 4 5 6 7 class Foo { public:int devoile(int); private:int cache(int); }; inline int Foo::devoile(int i){return cache(i);} // ne peut pas être caché inline int Foo::cache(int i){return i;} // peut-être caché
Le client verra effectivement l'implementation de "devoile" mais l'implémentation de "cache" pourra en revanche ne pas lui être montrée. Non?
devoile utilise cache, donc si devoile est utilise, cache aussi et il faut voir l'implementation de cache comme elle est inline. Et si elle ne l'est pas, l'interet de devoile tel qu'ecrit est a priori faible.

28/08/2012, 17h46
PyNub

Citation:

Ce qu'il faut, c'est qu'une fonction inline soit definie (et de la meme maniere) dans toutes les unites de compilations qui l'utilisent. Le plus simple est de mettre la definition dans le .hpp qui la declare, mais ce n'est en rien obligatoire. Il est relativement courant quand on adopte l'organisation une classe=un .hpp et un .cpp de ne definir dans le .hpp que les fonctions inline publiques et protegees et definir dans le .cpp les fonctions inline privees qui ne sont pas utilisees par les fonctions inline presentes dans le .hpp.

Mais si l'on veut permettre une utilisation des fonctions en ligne par les programmeurs client tout en leur cachant le code source de ces mêmes fonctions, comment peut-on s'y prendre ? Si la définition de la fonction inline doit être présente dans chaque unité de compilation on ne peut déclarer une fonction membre dans le fichier d'entête et fournir sa définition inline dans un fichier objet déjà compilé. Le résultat côté programme client sera forcément un appel de fonction. On est donc obligé de fournir le code des fonctions que l'on souhaite mettre en ligne. C'est cela qui me dérange...

A moins (je ne sais pas si ça fonctionne...) de déclarer une extern class et de définir celle-ci dans un fichier objet. Est-ce que ce genre de "manipulation" est possible ?:question:
28/08/2012, 18h37
PyNub

Citation:

Envoyé par PyNub

A moins (je ne sais pas si ça fonctionne...) de déclarer une extern class et de définir celle-ci dans un fichier objet. Est-ce que ce genre de "manipulation" est possible ?:question:

Non ça ne fonctionne pas, évidemment.
Je m'en doutais un peu ceci-dit.
28/08/2012, 18h55
Jean-Marc.Bourguet

Citation:

Envoyé par PyNub

Mais si l'on veut permettre une utilisation des fonctions en ligne par les programmeurs client tout en leur cachant le code source de ces mêmes fonctions, comment peut-on s'y prendre ?

On ne peut pas sauf à fournir les fichiers compilés avec une option du genre lto et donc à imposer aux clients cette option.

En passant, les fonctions qui ont un intérêt à être inline sont souvent triviales, quel est l'intérêt de les cacher? Je comprends un peu mieux le problème pour les templates, où il n'y a pas non plus de solution dans le cadre du langage. Mais même alors, l'absence généralisée de solution en dehors me fait penser que ce n'est pas un trop gros problème en pratique. Si ce l'était, les compilateurs fourniraient quelque chose depuis longtemps (ça se fait bien dans d'autres domaines).

Comme j'ai dit que j'allais refaire un test, le voici :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// carchain.h : Header classe chaine de caractères
#include <string.h>
#include <iostream>
#ifndef CARCHAIN_H
#define CARCHAIN_H
class CarChain{
  char* tab;
public:
  CarChain(int a);
  void print();
  void load (char *);
};
 
inline CarChain::CarChain (int a){
  tab = new char[a];
  memset(tab,' ',a);
}
 
inline void CarChain::print(){
  std::cout << tab << std::endl;
}
#endif

L'implémentation d'une fonction dans un fichier à part :

Code:

1
2
3
4
5
6
7
8
9
10
// carchain.cpp implémentation de Carchain::load
 
#include "carchain.h"
#include <string.h>
#include <iostream>
#ifdef line
inline void CarChain::load (char * src){memcpy(tab,src,strlen(src));}
#else
void CarChain::load (char * src){memcpy(tab,src,strlen(src));}
#endif

Le programme principal :

Code:

1
2
3
4
5
6
7
8
9
10
// exo7.cpp : fonction inline
 
#include "carchain.h"
 
int main(){
  CarChain test(54);
  test.load("test et retest");
  test.print();
  return 0;
}

Le résultat des deux compilations :

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
mikmak@linux-uf9h:~/Devel/C++/eckel/p246/exo7> g++ -c carchain.cpp -Wall -Dline
mikmak@linux-uf9h:~/Devel/C++/eckel/p246/exo7> ls -l
total 20
-rw-r--r-- 1 mikmak users  272 28 août  18:42 carchain.cpp
-rw-r--r-- 1 mikmak users  381 28 août  18:43 carchain.h
-rw-r--r-- 1 mikmak users 2168 28 août  18:45 carchain.o
-rw-r--r-- 1 mikmak users  148 27 août  19:54 exo7.cpp
-rw-r--r-- 1 mikmak users 3387 27 août  19:59 exo7.s
mikmak@linux-uf9h:~/Devel/C++/eckel/p246/exo7> g++ -o exo7 exo7.cpp carchain.o -Wall -O1
exo7.cpp: In function ‘int main()’:
exo7.cpp:8:29: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
/tmp/ccrSTqNa.o: In function `main':
exo7.cpp:(.text+0x49): undefined reference to `CarChain::load(char*)'
collect2: ld returned 1 exit status
mikmak@linux-uf9h:~/Devel/C++/eckel/p246/exo7> ls -l
total 20
-rw-r--r-- 1 mikmak users  272 28 août  18:42 carchain.cpp
-rw-r--r-- 1 mikmak users  381 28 août  18:43 carchain.h
-rw-r--r-- 1 mikmak users 2168 28 août  18:45 carchain.o
-rw-r--r-- 1 mikmak users  148 27 août  19:54 exo7.cpp
-rw-r--r-- 1 mikmak users 3387 27 août  19:59 exo7.s
mikmak@linux-uf9h:~/Devel/C++/eckel/p246/exo7> g++ -c carchain.cpp -Wall
mikmak@linux-uf9h:~/Devel/C++/eckel/p246/exo7> g++ -o exo7 exo7.cpp carchain.o -Wall -O1
exo7.cpp: In function ‘int main()’:
exo7.cpp:8:29: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
mikmak@linux-uf9h:~/Devel/C++/eckel/p246/exo7> ls -l
total 32
-rw-r--r-- 1 mikmak users   272 28 août  18:42 carchain.cpp
-rw-r--r-- 1 mikmak users   381 28 août  18:43 carchain.h
-rw-r--r-- 1 mikmak users  2440 28 août  18:46 carchain.o
-rwxr-xr-x 1 mikmak users 12211 28 août  18:46 exo7
-rw-r--r-- 1 mikmak users   148 27 août  19:54 exo7.cpp
-rw-r--r-- 1 mikmak users  3387 27 août  19:59 exo7.s
mikmak@linux-uf9h:~/Devel/C++/eckel/p246/exo7> ./exo7
test et retest

28/08/2012, 19h28
PyNub

Citation:

Envoyé par Jean-Marc.Bourguet

On ne peut pas sauf à fournir les fichiers compilés avec une option du genre lto et donc à imposer aux clients cette option.

Qu'est ce une option lto ?

Citation:

En passant, les fonctions qui ont un intérêt à être inline sont souvent triviales, quel est l'intérêt de les cacher?

Oui en effet, il s'agit la plupart du temps de fonction d'initialisation, restitution de données etc...
Le seul intérêt de les cacher serait dans l'exemple du cheshire que j'ai donnée au début tiré de "penser en c++" de Bruce Eckel. Dans cet exemple les données mêmes de la classe sont cachées au programmeur client, celui-ci ne voit qu'un pointeur vers une structure dont les détails font partie du fichier d'implémentation. Ce qui nous oblige a renoncer aux fonctions inline même pour le constructeur d'une telle classe, puisque montrer la façon dont le constructeur s'y prend pour initialiser la structure dévoilerai en même temps l'organisation de la structure.

Citation:

Je comprends un peu mieux le problème pour les templates, où il n'y a pas non plus de solution dans le cadre du langage.

Je n'en suis pas encore aux templates dans mon apprentissage, mais j'examinerai bientôt ce point.

Citation:

Mais même alors, l'absence généralisée de solution en dehors me fait penser que ce n'est pas un trop gros problème en pratique. Si ce l'était, les compilateurs fourniraient quelque chose depuis longtemps (ça se fait bien dans d'autres domaines).

Oui c'est ce qui m'a fait croire au début qu'il existait peut-être une solution à ce problème. Comme tu l'as dit précédemment le fait que les fonction inline sont la plupart du temps triviales réduit d'autant son importance.