Discussion :

[méphistopheles]

Bonsoir.

Je me demandais (suite à de nombreuses récriminations contre mon compilateur que la décence m'interdit de citer) pourquoi il est impossible de définir une fonction inline en dans un .ccp qui puisse être appelée d'un autre .ccp (je déteste mettre autre chose que des définitions dans les .h)...

D'autre part, j'esperais savoir si le fait de mettre ces définitions dans un .h externe (du genre finline.h ) permettait de garder la propriété inline sans que l'éditeur de lien ne lâche une flopée d'injure dont la lecture abime la molette horizontale de ma souris... (et m'apprenne l'existence de nombre de charactères insoupsonés )

En attendant vos réponses, je continue à faire des fonctions monoligne dans mes .h (gnark! les fonctions sont sur la même ligne que la définition).

Merci

[Charlemagne]

Parce que tu inclus des fichiers .h et non des .cpp.
Le compilateur doit connaitre le contenu d'une fonction inline pour le mettre directement dans le code appelant (sans appel de fonction donc, par définition).

Mets toi à la place du compilateur, comment tu ferais pour généré du code assembleur dont tu ignorerais le code source?...

[wiztricks]

Le but d'une fonction "inline" c'est que le compilo va remplacer les appels à cette fonction par le corps de la fonction elle même.
Lorsqu'on va effectuer l'edition de lien, la fonction n'existe plus.
On peut donc inclure sa définition dans des .h sans que l'edition de lien ne rale.
- W

[Alp]

On peut donc inclure sa définition dans des .h sans que l'edition de lien ne rale.
- W

C'est plutôt que l'on doit mettre sa définition dans un en-tête

[wiztricks]

C'est plutôt que l'on doit mettre sa définition dans un en-tête

Hello Alp,
Ma description essaie de faire comprendre que, si nécessaire, une fonction inline peut être partagée en la définissant dans un .h
Ta prescription laisse entendre que toutes les fonctions inline devraient être dans des .h, mais je suis sur que ce n'est pas ce que tu as voulu dire.
-W

[Alp]

Effectivement. Mais en la séparant, le compilo je crois risque de faire sauter l'inline.

[HanLee]

Parce que tu inclus des fichiers .h et non des .cpp.
Le compilateur doit connaitre le contenu d'une fonction inline pour le mettre directement dans le code appelant (sans appel de fonction donc, par définition).

Mets toi à la place du compilateur, comment tu ferais pour généré du code assembleur dont tu ignorerais le code source?...

Ben, techniquement c'est pas impossible.

Tu fais un code assembleur intermédiaire avec des marqueurs spéciaux, et tu refais une seconde passe en cherchant le code source dans tous les .o générés.

C'est plus long certes.

[Emmanuel Deloget]

Ben, techniquement c'est pas impossible.

Tu fais un code assembleur intermédiaire avec des marqueurs spéciaux, et tu refais une seconde passe en cherchant le code source dans tous les .o générés.

C'est plus long certes.

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 ?

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

[befalimpertinent]

Bonsoir.
[..]je déteste mettre autre chose que des définitions dans les .h[..]
[..]D'autre part, j'esperais savoir si le fait de mettre ces définitions dans un .h externe (du genre finline.h ) permettait de garder la propriété inline [..])

Un bon usage est en effet de mettre les inline dans une en-tête séparée .inl ou .i.hpp ou ce que tu veux.
Exemple: tropclasse.hpp

Code :

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

1
2
3
4
5
6
7
8
9
#ifndef TROP_CLASSE_HPP
#def TROP_CLASSE_HPP
Class tropclasse
{
  tropclasse();
/*declarations*/
};
#include "tropclasse.i.hpp"
#endif

tropclasse.i.hpp:

Code :

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

1
2
3
4
5
6
#include "tropclasse.hpp"
 
inline
tropclasse::tropclasse()
{
}

Enfin c'est juste une des nombreuses (et bonne) façons de faire.

[méphistopheles]

Un bon usage est en effet de mettre les inline dans une en-tête séparée .inl ou .i.hpp ou ce que tu veux.

mais est-t'il possible de mettre un hpp par .h (je penssait à un .h regroupant plusieurs h....) et, dans ce cas, à quoi servent les .cpp ?