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 :(
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 :(
QQn aurait-il une idee ? Meme crade... :)
mettre la déclaration de la variable dans un .cpp ?
"mderie" <mderie@gmail.com> a écrit dans le message de news:
1132217830.338031.115410@f14g2000cwb.googlegroups.com...
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 :(
QQn aurait-il une idee ? Meme crade... :)
mettre la déclaration de la variable dans un .cpp ?
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 :(
QQn aurait-il une idee ? Meme crade... :)
mettre la déclaration de la variable dans un .cpp ?
Falk Tannhäuser
Alexandre wrote:
"mderie" a écrit dans le message de news:
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. mettre la déclaration de la variable dans un .cpp ?
Plutôt mettre la déclaration (avec "extern") dans le .h, et la définition dans exactement un .cpp - le grand classique, quoi.
Falk
Alexandre wrote:
"mderie" <mderie@gmail.com> a écrit dans le message de news:
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.
mettre la déclaration de la variable dans un .cpp ?
Plutôt mettre la déclaration (avec "extern") dans le .h, et la
définition dans exactement un .cpp - le grand classique, quoi.
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. mettre la déclaration de la variable dans un .cpp ?
Plutôt mettre la déclaration (avec "extern") dans le .h, et la définition dans exactement un .cpp - le grand classique, quoi.
Falk
mderie
Oui bien sur... Helas ce que je voulais eviter c'est de changer le makefile ou le fichier projet pour inclure le fichier .cpp
Merci quand meme et A+
Oui bien sur... Helas ce que je voulais eviter c'est de changer
le makefile ou le fichier projet pour inclure le fichier .cpp
Oui bien sur... Helas ce que je voulais eviter c'est de changer le makefile ou le fichier projet pour inclure le fichier .cpp
Merci quand meme et A+
Jean-Marc Bourguet
"mderie" writes:
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...
Une technique parfois utilisee -- du moins pour les variables, pour du code ca me semble encore plus douteux -- c'est d'avoir les variables declarees comme ceci:
Note que ca pose des problemes quand "lefichier.hpp" fait ses propres includes qui utilise la meme technique.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
"mderie" <mderie@gmail.com> writes:
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...
Une technique parfois utilisee -- du moins pour les variables, pour du
code ca me semble encore plus douteux -- c'est d'avoir les variables
declarees comme ceci:
Note que ca pose des problemes quand "lefichier.hpp" fait ses propres
includes qui utilise la meme technique.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
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...
Une technique parfois utilisee -- du moins pour les variables, pour du code ca me semble encore plus douteux -- c'est d'avoir les variables declarees comme ceci:
Note que ca pose des problemes quand "lefichier.hpp" fait ses propres includes qui utilise la meme technique.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Aurelien Regat-Barrel
Oui bien sur... Helas ce que je voulais eviter c'est de changer le makefile ou le fichier projet pour inclure le fichier .cpp
C'est sale, mais un truc de ce genre:
// .h class Toto {};
inline Toto* GetToto() { static Toto t; return &t; }
?
-- Aurélien Regat-Barrel
Oui bien sur... Helas ce que je voulais eviter c'est de changer
le makefile ou le fichier projet pour inclure le fichier .cpp
C'est sale, mais un truc de ce genre:
// .h
class Toto {};
inline Toto* GetToto()
{
static Toto t;
return &t;
}
Oui bien sur... Helas ce que je voulais eviter c'est de changer le makefile ou le fichier projet pour inclure le fichier .cpp
C'est sale, mais un truc de ce genre:
// .h class Toto {};
inline Toto* GetToto() { static Toto t; return &t; }
?
-- Aurélien Regat-Barrel
Aurelien Regat-Barrel
C'est sale, mais un truc de ce genre:
// .h class Toto {};
inline Toto* GetToto() { static Toto t; return &t; }
En fait, en me relisant, je ne comprends pas ce que j'ai écrit :) J'ai testé : ça marche. Mais je m'interroge : quel est le comportement du C++ par rapport aux membres statiques des fonctions inline ?
-- Aurélien Regat-Barrel
C'est sale, mais un truc de ce genre:
// .h
class Toto {};
inline Toto* GetToto()
{
static Toto t;
return &t;
}
En fait, en me relisant, je ne comprends pas ce que j'ai écrit :)
J'ai testé : ça marche. Mais je m'interroge : quel est le comportement
du C++ par rapport aux membres statiques des fonctions inline ?
inline Toto* GetToto() { static Toto t; return &t; }
En fait, en me relisant, je ne comprends pas ce que j'ai écrit :) J'ai testé : ça marche. Mais je m'interroge : quel est le comportement du C++ par rapport aux membres statiques des fonctions inline ?
-- Aurélien Regat-Barrel
Jean-Marc Bourguet
Aurelien Regat-Barrel writes:
C'est sale, mais un truc de ce genre: // .h class Toto {}; inline Toto* GetToto() { static Toto t; return &t; }
En fait, en me relisant, je ne comprends pas ce que j'ai écrit :) J'ai testé : ça marche. Mais je m'interroge : quel est le comportement du C++ par rapport aux membres statiques des fonctions inline ?
Ca marche correctement. Au contraire du C pour lequel si j'ai bonne memoire le comportement est indefini.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
C'est sale, mais un truc de ce genre:
// .h
class Toto {};
inline Toto* GetToto()
{
static Toto t;
return &t;
}
En fait, en me relisant, je ne comprends pas ce que j'ai écrit :)
J'ai testé : ça marche. Mais je m'interroge : quel est le comportement du
C++ par rapport aux membres statiques des fonctions inline ?
Ca marche correctement. Au contraire du C pour lequel si j'ai bonne
memoire le comportement est indefini.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
C'est sale, mais un truc de ce genre: // .h class Toto {}; inline Toto* GetToto() { static Toto t; return &t; }
En fait, en me relisant, je ne comprends pas ce que j'ai écrit :) J'ai testé : ça marche. Mais je m'interroge : quel est le comportement du C++ par rapport aux membres statiques des fonctions inline ?
Ca marche correctement. Au contraire du C pour lequel si j'ai bonne memoire le comportement est indefini.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Aurelien Regat-Barrel
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.
-- Aurélien Regat-Barrel
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.
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.
-- Aurélien Regat-Barrel
Jean-Marc Bourguet
Aurelien Regat-Barrel writes:
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.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
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.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
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.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Aurelien Regat-Barrel
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.
Je ne le savais pas, je me demandais justement comment il décidait où placer la fonction... donc il la duplique, tout simplement.
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 ce que je me suis dit en écrivant. Je ne connaissais pas cette notion de symbole dupliqué, je pensais qu'il se débrouillait pour maintenir un seul symbole quelque part, mais je ne voyais pas comment.
Merci bien c'est clair maintenant.
-- Aurélien Regat-Barrel
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.
Je ne le savais pas, je me demandais justement comment il décidait où
placer la fonction... donc il la duplique, tout simplement.
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 ce que je me suis dit en écrivant. Je ne connaissais pas cette
notion de symbole dupliqué, je pensais qu'il se débrouillait pour
maintenir un seul symbole quelque part, mais je ne voyais pas comment.
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.
Je ne le savais pas, je me demandais justement comment il décidait où placer la fonction... donc il la duplique, tout simplement.
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 ce que je me suis dit en écrivant. Je ne connaissais pas cette notion de symbole dupliqué, je pensais qu'il se débrouillait pour maintenir un seul symbole quelque part, mais je ne voyais pas comment.
