cacher l'implémentation des fonctions inline

Version imprimable

Voir 40 message(s) de cette discussion en une page

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)

Voir 40 message(s) de cette discussion en une page