Comment passer des informations entre deux unitees de compilation ?
11 réponses
mderie
J'explique, je voudrais implementer une bidouille dans un .h qui serait
partage entre
plusieurs .cpp. Jusque la OK mais, dans mon .h, il y a du code (beurk
:) et notemment
une variable statique... Je voudrais trouver une astuce pour qu'a la
premiere inclusion
dans un .cpp la variable soit definie et qu'ensuite elle soit juste
partagee avec les autres .cpp
L'idee serait de contourner la notion de extern...
Je crois savoir que lorsque l'on compile un projet contenant plusieurs
.cpp, les #define et compagnie sont reinitialises entre chaque
fichiers. Donc c'est l'impasse :(
Ca marche correctement. Au contraire du C pour lequel si j'ai bonne memoire le comportement est indefini.
C'est ce que j'ai pu constater. Disons que c'est conceptuellement que ça me titille. Je trouve cette notion de static incompatible avec celle de inline. Pour moi inline était un substitut plus élégant aux macros (copier-coller), mais apparement ça va plus loin.
En C++, une fonction inline ne fait rien de plus mais rien de moins qu'une fonction qui ne l'est pas. La seule difference formelle c'est qu'elle *doit* etre definie dans toutes les unites de compilation qui l'utilisent. Ce qui permet en pratique au compilateur d'effectivement substituer son corps au lieu de l'appel, mais ce n'est en rien une obligation pour ce dernier. Apres comment il s'arrange pour eviter les duplicatats (une fonction inline doit avoir la meme adresse dans toutes les unites de compilations, une autre difference qu'avec le C si j'ai toujours bonne memoire), c'est son affaire. C'est pas trop genant, le mecanisme est vraissemblablement deja en place pour traiter les templates.
C'est vrai aujourd'hui, mais ça ne l'a pas toujours été. Dans les premières versions de C++, « inline » faisait que la fonction était implicitement static, c-à-d qu'elle n'avait pas de linkage. Seulement... qu'est-ce que ça signifie pour une fonction membre, par exemple ? Et qu'est-ce qui se passe si je déclare la fonction explicitement « inline extern » ?
Entre temps, comme tu dis, il y a eu des templates (qui n'étaient pas présents dans les premiers C++). Et effectivement, pour un compilateur qui sait gérer les templates, les problèmes d'« inline » ne sont rien. Alors, le comité a fait proprement (chose que Bjarne n'aurait probablement pas pû faire dans les premiers C++, vu l'état de la technologie alors).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ca marche correctement. Au contraire du C pour lequel si
j'ai bonne memoire le comportement est indefini.
C'est ce que j'ai pu constater. Disons que c'est
conceptuellement que ça me titille. Je trouve cette notion
de static incompatible avec celle de inline. Pour moi inline
était un substitut plus élégant aux macros (copier-coller),
mais apparement ça va plus loin.
En C++, une fonction inline ne fait rien de plus mais rien de
moins qu'une fonction qui ne l'est pas. La seule difference
formelle c'est qu'elle *doit* etre definie dans toutes les
unites de compilation qui l'utilisent. Ce qui permet en
pratique au compilateur d'effectivement substituer son corps
au lieu de l'appel, mais ce n'est en rien une obligation pour
ce dernier. Apres comment il s'arrange pour eviter les
duplicatats (une fonction inline doit avoir la meme adresse
dans toutes les unites de compilations, une autre difference
qu'avec le C si j'ai toujours bonne memoire), c'est son
affaire. C'est pas trop genant, le mecanisme est
vraissemblablement deja en place pour traiter les templates.
C'est vrai aujourd'hui, mais ça ne l'a pas toujours été. Dans
les premières versions de C++, « inline » faisait que la
fonction était implicitement static, c-à-d qu'elle n'avait pas
de linkage. Seulement... qu'est-ce que ça signifie pour une
fonction membre, par exemple ? Et qu'est-ce qui se passe si je
déclare la fonction explicitement « inline extern » ?
Entre temps, comme tu dis, il y a eu des templates (qui
n'étaient pas présents dans les premiers C++). Et effectivement,
pour un compilateur qui sait gérer les templates, les problèmes
d'« inline » ne sont rien. Alors, le comité a fait proprement
(chose que Bjarne n'aurait probablement pas pû faire dans les
premiers C++, vu l'état de la technologie alors).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ca marche correctement. Au contraire du C pour lequel si j'ai bonne memoire le comportement est indefini.
C'est ce que j'ai pu constater. Disons que c'est conceptuellement que ça me titille. Je trouve cette notion de static incompatible avec celle de inline. Pour moi inline était un substitut plus élégant aux macros (copier-coller), mais apparement ça va plus loin.
En C++, une fonction inline ne fait rien de plus mais rien de moins qu'une fonction qui ne l'est pas. La seule difference formelle c'est qu'elle *doit* etre definie dans toutes les unites de compilation qui l'utilisent. Ce qui permet en pratique au compilateur d'effectivement substituer son corps au lieu de l'appel, mais ce n'est en rien une obligation pour ce dernier. Apres comment il s'arrange pour eviter les duplicatats (une fonction inline doit avoir la meme adresse dans toutes les unites de compilations, une autre difference qu'avec le C si j'ai toujours bonne memoire), c'est son affaire. C'est pas trop genant, le mecanisme est vraissemblablement deja en place pour traiter les templates.
C'est vrai aujourd'hui, mais ça ne l'a pas toujours été. Dans les premières versions de C++, « inline » faisait que la fonction était implicitement static, c-à-d qu'elle n'avait pas de linkage. Seulement... qu'est-ce que ça signifie pour une fonction membre, par exemple ? Et qu'est-ce qui se passe si je déclare la fonction explicitement « inline extern » ?
Entre temps, comme tu dis, il y a eu des templates (qui n'étaient pas présents dans les premiers C++). Et effectivement, pour un compilateur qui sait gérer les templates, les problèmes d'« inline » ne sont rien. Alors, le comité a fait proprement (chose que Bjarne n'aurait probablement pas pû faire dans les premiers C++, vu l'état de la technologie alors).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
