Discussion :

[PyNub]

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

[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.

[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

[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.

[PyNub]

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...

[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.

[PyNub]

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

[PyNub]

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 ?

[Jean-Marc.Bourguet]

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").

[Aleph69]

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 :

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
// 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.

[PyNub]

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.

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.

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.

[Aleph69]

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).

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!

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 :

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

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.

[PyNub]

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

[PyNub]

Code :

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

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...

[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

[Jean-Marc.Bourguet]

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.

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é.

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.

[Aleph69]

Bonjour Jean-Marc,

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!

[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.

[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.

[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)