Je pensais pas que ce genre de code était problématique (unités de
compilations différentes), mais apparement si (dixit la one definition
rule).
Vous confirmez ?
Je pensais pas que ce genre de code était problématique (unités de
compilations différentes), mais apparement si (dixit la one definition
rule).
Vous confirmez ?
Je pensais pas que ce genre de code était problématique (unités de
compilations différentes), mais apparement si (dixit la one definition
rule).
Vous confirmez ?
Bonjour,
J'ai eu affaire à un drôle de bug dans mon programme, provoqué par un code
de ce genre:
// montemplate.h
template<typename T>
class montemplate
{
#ifdef MODIF
// quelque chose
#else
// autre chose
#endif
};
// test.cpp
#define MODIF
#include "montemplate.h"
// utilisation de montemplate...
// main.cpp
#include "montemplate.h"
// utilisation de montemplate...
Je pensais pas que ce genre de code était problématique (unités de
compilations différentes), mais apparement si (dixit la one definition
rule).
Vous confirmez ?
Merci.
Bonjour,
J'ai eu affaire à un drôle de bug dans mon programme, provoqué par un code
de ce genre:
// montemplate.h
template<typename T>
class montemplate
{
#ifdef MODIF
// quelque chose
#else
// autre chose
#endif
};
// test.cpp
#define MODIF
#include "montemplate.h"
// utilisation de montemplate...
// main.cpp
#include "montemplate.h"
// utilisation de montemplate...
Je pensais pas que ce genre de code était problématique (unités de
compilations différentes), mais apparement si (dixit la one definition
rule).
Vous confirmez ?
Merci.
Bonjour,
J'ai eu affaire à un drôle de bug dans mon programme, provoqué par un code
de ce genre:
// montemplate.h
template<typename T>
class montemplate
{
#ifdef MODIF
// quelque chose
#else
// autre chose
#endif
};
// test.cpp
#define MODIF
#include "montemplate.h"
// utilisation de montemplate...
// main.cpp
#include "montemplate.h"
// utilisation de montemplate...
Je pensais pas que ce genre de code était problématique (unités de
compilations différentes), mais apparement si (dixit la one definition
rule).
Vous confirmez ?
Merci.
Oui. Ca peut ou pas causer des problemes suivant les modifications,
mais c'est a chaque fois du comportement indetermine. Pense par
exemple a
template <typename T>
class c {
public:
~c() {
#ifdef MODIF
delete[] m_;
#endif
}
private:
#ifdef MODIF
char* m_;
#endif
int k;
};
et que tu liberes dans l'unite avec MODIF un exemplaire alloue dans
une unite sans MODIF.
Oui. Ca peut ou pas causer des problemes suivant les modifications,
mais c'est a chaque fois du comportement indetermine. Pense par
exemple a
template <typename T>
class c {
public:
~c() {
#ifdef MODIF
delete[] m_;
#endif
}
private:
#ifdef MODIF
char* m_;
#endif
int k;
};
et que tu liberes dans l'unite avec MODIF un exemplaire alloue dans
une unite sans MODIF.
Oui. Ca peut ou pas causer des problemes suivant les modifications,
mais c'est a chaque fois du comportement indetermine. Pense par
exemple a
template <typename T>
class c {
public:
~c() {
#ifdef MODIF
delete[] m_;
#endif
}
private:
#ifdef MODIF
char* m_;
#endif
int k;
};
et que tu liberes dans l'unite avec MODIF un exemplaire alloue dans
une unite sans MODIF.
Eh bien si "quelque chose" et "autre chose" sont suffisamment différents, il
y aura forcément un problème à l'édition de liens (lorsqu'on essaye de lier
ensemble test.o et main.o).
Eh bien si "quelque chose" et "autre chose" sont suffisamment différents, il
y aura forcément un problème à l'édition de liens (lorsqu'on essaye de lier
ensemble test.o et main.o).
Eh bien si "quelque chose" et "autre chose" sont suffisamment différents, il
y aura forcément un problème à l'édition de liens (lorsqu'on essaye de lier
ensemble test.o et main.o).
Oui. Ca peut ou pas causer des problemes suivant les modifications,
mais c'est a chaque fois du comportement indetermine. Pense par
exemple a
template <typename T>
class c {
public:
~c() { #ifdef MODIF
delete[] m_;
#endif
}
private:
#ifdef MODIF
char* m_;
#endif
int k;
};
et que tu liberes dans l'unite avec MODIF un exemplaire alloue dans
une unite sans MODIF.
Ca je comprends tout à fait. Là où je suis davantage surpris c'est si les 2
unités ont chacune leur propre "version" et qu'elles ne se mélangent pas.
Oui. Ca peut ou pas causer des problemes suivant les modifications,
mais c'est a chaque fois du comportement indetermine. Pense par
exemple a
template <typename T>
class c {
public:
~c() { #ifdef MODIF
delete[] m_;
#endif
}
private:
#ifdef MODIF
char* m_;
#endif
int k;
};
et que tu liberes dans l'unite avec MODIF un exemplaire alloue dans
une unite sans MODIF.
Ca je comprends tout à fait. Là où je suis davantage surpris c'est si les 2
unités ont chacune leur propre "version" et qu'elles ne se mélangent pas.
Oui. Ca peut ou pas causer des problemes suivant les modifications,
mais c'est a chaque fois du comportement indetermine. Pense par
exemple a
template <typename T>
class c {
public:
~c() { #ifdef MODIF
delete[] m_;
#endif
}
private:
#ifdef MODIF
char* m_;
#endif
int k;
};
et que tu liberes dans l'unite avec MODIF un exemplaire alloue dans
une unite sans MODIF.
Ca je comprends tout à fait. Là où je suis davantage surpris c'est si les 2
unités ont chacune leur propre "version" et qu'elles ne se mélangent pas.
Eh bien si "quelque chose" et "autre chose" sont
suffisamment différents, il y aura forcément un problème à
l'édition de liens (lorsqu'on essaye de lier ensemble test.o
et main.o).
Le problème est effectivement survenu à l'édition de liens,
mais pas de manière systématique (avec VC++ 8). En DEBUG pas
de problème, en RELEASE sans optimisation globale non plus.
Avec optimisation globale (/GL), ça crée des problèmes.
Pour info, j'ai eu ce problème "à l'insu de mon plein grès"
avec std::vector sous VC++ 8 en définissant _SECURE_SCL à 0
dans 1 fichier de mon projet pour éviter d'avoir des warnings
(ailleurs que dans std::vector). Sauf que ça modifie pas mal
de choses dans std::vector aussi, et voilà.
Eh bien si "quelque chose" et "autre chose" sont
suffisamment différents, il y aura forcément un problème à
l'édition de liens (lorsqu'on essaye de lier ensemble test.o
et main.o).
Le problème est effectivement survenu à l'édition de liens,
mais pas de manière systématique (avec VC++ 8). En DEBUG pas
de problème, en RELEASE sans optimisation globale non plus.
Avec optimisation globale (/GL), ça crée des problèmes.
Pour info, j'ai eu ce problème "à l'insu de mon plein grès"
avec std::vector sous VC++ 8 en définissant _SECURE_SCL à 0
dans 1 fichier de mon projet pour éviter d'avoir des warnings
(ailleurs que dans std::vector). Sauf que ça modifie pas mal
de choses dans std::vector aussi, et voilà.
Eh bien si "quelque chose" et "autre chose" sont
suffisamment différents, il y aura forcément un problème à
l'édition de liens (lorsqu'on essaye de lier ensemble test.o
et main.o).
Le problème est effectivement survenu à l'édition de liens,
mais pas de manière systématique (avec VC++ 8). En DEBUG pas
de problème, en RELEASE sans optimisation globale non plus.
Avec optimisation globale (/GL), ça crée des problèmes.
Pour info, j'ai eu ce problème "à l'insu de mon plein grès"
avec std::vector sous VC++ 8 en définissant _SECURE_SCL à 0
dans 1 fichier de mon projet pour éviter d'avoir des warnings
(ailleurs que dans std::vector). Sauf que ça modifie pas mal
de choses dans std::vector aussi, et voilà.
Ca je comprends tout à fait. Là où je suis davantage surpris c'est si les 2
unités ont chacune leur propre "version" et qu'elles ne se mélangent pas.
En es-tu sur qu'il n'y a pas de melange (du genre partage de code)?
Ca je comprends tout à fait. Là où je suis davantage surpris c'est si les 2
unités ont chacune leur propre "version" et qu'elles ne se mélangent pas.
En es-tu sur qu'il n'y a pas de melange (du genre partage de code)?
Ca je comprends tout à fait. Là où je suis davantage surpris c'est si les 2
unités ont chacune leur propre "version" et qu'elles ne se mélangent pas.
En es-tu sur qu'il n'y a pas de melange (du genre partage de code)?
Le problème est effectivement survenu à l'édition de liens,
Sois content. Moi, aussi, je l'ai rencontré, mais seulement à
l'exécution, quand le programme s'est mis à faire des cores
dumps inexplicables.
mais pas de manière systématique (avec VC++ 8). En DEBUG pas
de problème, en RELEASE sans optimisation globale non plus.
Avec optimisation globale (/GL), ça crée des problèmes.Pour info, j'ai eu ce problème "à l'insu de mon plein grès"
avec std::vector sous VC++ 8 en définissant _SECURE_SCL à 0
dans 1 fichier de mon projet pour éviter d'avoir des warnings
(ailleurs que dans std::vector). Sauf que ça modifie pas mal
de choses dans std::vector aussi, et voilà.
_SECURE_SCL, ça ne serait pas un peu comme _GLIBCXX_DEBUG sous
G++ ? C'était exactement mon problème, sauf que ça linkait bien.
(Dans mon cas, c'était une erreur dans le fichier de make.
J'étais convaincu que je me servais des bibliothèques de debug,
alors que ce n'était pas le cas. J'avais un vecteur qui était
créer dans la bibliothèque, mais dont je me servais des
itérateurs dans une fonction templatée instantiée dans main.)
En régle générale : il faut que toutes les unités de compilation
soient compilées avec exactement les mêmes options, y compris
les mêmes -D. Et que tu ne définisses jamais de macro dans ton
code avant d'inclure les en-têtes, et que les en-têtes aussi ne
définissent que les macros qui les concernent.
Plus ou moins. Il y a des options qui spécifient les fichiers de
sortie, par exemple, et là, évidemment, il vaut mieux qu'elles
soient différentes d'une unité de compilation à l'autre:-). Des
variations dans le niveau d'avertissements ne doivent pas poser
de problèmes non plus. (Avec VC++, si tu fais cl /help, les
options dans « -OUTPUT FILES- », et quelques unes dans
« -MISCELLANEOUS- », vont bien. Les autres non.)
Il faut aussi se rappeler que certains compilateurs peuvent
instantier les templates lors de l'édition des liens, et que
dans ce cas-là, il faut passer aussi toutes les options à
l'édition de liens aussi. De même, certains compilateurs (Sun
CC, par exemple, mais probablement d'autres qui se servent d'un
repositoire) peuvent instantier les templates lors de la
génération des bibliothèques -- dans ce cas-là, il faut aussi
les mêmes options alors.
Le problème est effectivement survenu à l'édition de liens,
Sois content. Moi, aussi, je l'ai rencontré, mais seulement à
l'exécution, quand le programme s'est mis à faire des cores
dumps inexplicables.
mais pas de manière systématique (avec VC++ 8). En DEBUG pas
de problème, en RELEASE sans optimisation globale non plus.
Avec optimisation globale (/GL), ça crée des problèmes.
Pour info, j'ai eu ce problème "à l'insu de mon plein grès"
avec std::vector sous VC++ 8 en définissant _SECURE_SCL à 0
dans 1 fichier de mon projet pour éviter d'avoir des warnings
(ailleurs que dans std::vector). Sauf que ça modifie pas mal
de choses dans std::vector aussi, et voilà.
_SECURE_SCL, ça ne serait pas un peu comme _GLIBCXX_DEBUG sous
G++ ? C'était exactement mon problème, sauf que ça linkait bien.
(Dans mon cas, c'était une erreur dans le fichier de make.
J'étais convaincu que je me servais des bibliothèques de debug,
alors que ce n'était pas le cas. J'avais un vecteur qui était
créer dans la bibliothèque, mais dont je me servais des
itérateurs dans une fonction templatée instantiée dans main.)
En régle générale : il faut que toutes les unités de compilation
soient compilées avec exactement les mêmes options, y compris
les mêmes -D. Et que tu ne définisses jamais de macro dans ton
code avant d'inclure les en-têtes, et que les en-têtes aussi ne
définissent que les macros qui les concernent.
Plus ou moins. Il y a des options qui spécifient les fichiers de
sortie, par exemple, et là, évidemment, il vaut mieux qu'elles
soient différentes d'une unité de compilation à l'autre:-). Des
variations dans le niveau d'avertissements ne doivent pas poser
de problèmes non plus. (Avec VC++, si tu fais cl /help, les
options dans « -OUTPUT FILES- », et quelques unes dans
« -MISCELLANEOUS- », vont bien. Les autres non.)
Il faut aussi se rappeler que certains compilateurs peuvent
instantier les templates lors de l'édition des liens, et que
dans ce cas-là, il faut passer aussi toutes les options à
l'édition de liens aussi. De même, certains compilateurs (Sun
CC, par exemple, mais probablement d'autres qui se servent d'un
repositoire) peuvent instantier les templates lors de la
génération des bibliothèques -- dans ce cas-là, il faut aussi
les mêmes options alors.
Le problème est effectivement survenu à l'édition de liens,
Sois content. Moi, aussi, je l'ai rencontré, mais seulement à
l'exécution, quand le programme s'est mis à faire des cores
dumps inexplicables.
mais pas de manière systématique (avec VC++ 8). En DEBUG pas
de problème, en RELEASE sans optimisation globale non plus.
Avec optimisation globale (/GL), ça crée des problèmes.Pour info, j'ai eu ce problème "à l'insu de mon plein grès"
avec std::vector sous VC++ 8 en définissant _SECURE_SCL à 0
dans 1 fichier de mon projet pour éviter d'avoir des warnings
(ailleurs que dans std::vector). Sauf que ça modifie pas mal
de choses dans std::vector aussi, et voilà.
_SECURE_SCL, ça ne serait pas un peu comme _GLIBCXX_DEBUG sous
G++ ? C'était exactement mon problème, sauf que ça linkait bien.
(Dans mon cas, c'était une erreur dans le fichier de make.
J'étais convaincu que je me servais des bibliothèques de debug,
alors que ce n'était pas le cas. J'avais un vecteur qui était
créer dans la bibliothèque, mais dont je me servais des
itérateurs dans une fonction templatée instantiée dans main.)
En régle générale : il faut que toutes les unités de compilation
soient compilées avec exactement les mêmes options, y compris
les mêmes -D. Et que tu ne définisses jamais de macro dans ton
code avant d'inclure les en-têtes, et que les en-têtes aussi ne
définissent que les macros qui les concernent.
Plus ou moins. Il y a des options qui spécifient les fichiers de
sortie, par exemple, et là, évidemment, il vaut mieux qu'elles
soient différentes d'une unité de compilation à l'autre:-). Des
variations dans le niveau d'avertissements ne doivent pas poser
de problèmes non plus. (Avec VC++, si tu fais cl /help, les
options dans « -OUTPUT FILES- », et quelques unes dans
« -MISCELLANEOUS- », vont bien. Les autres non.)
Il faut aussi se rappeler que certains compilateurs peuvent
instantier les templates lors de l'édition des liens, et que
dans ce cas-là, il faut passer aussi toutes les options à
l'édition de liens aussi. De même, certains compilateurs (Sun
CC, par exemple, mais probablement d'autres qui se servent d'un
repositoire) peuvent instantier les templates lors de la
génération des bibliothèques -- dans ce cas-là, il faut aussi
les mêmes options alors.
Ca je comprends tout à fait. Là où je suis davantage surpris c'est si les 2
unités ont chacune leur propre "version" et qu'elles ne se mélangent pas.
En es-tu sur qu'il n'y a pas de melange (du genre partage de code)?
Le problème surgit avec l'option d'optimisation globale (/GL) qui en
gros compile tout les différents fichiers sources comme si c'était
un seul fichier unique.
Je cherche à savoir si cette erreur est une conséquence de cette
optimisation globale, ou si c'est juste la manifestation d'un
problème qui relève bien du code.
Cette histoire de template instanciée de manière identique à
l'ensemble des codes sources compilés, ça fait un peu effet de bord
je trouve...
Ca je comprends tout à fait. Là où je suis davantage surpris c'est si les 2
unités ont chacune leur propre "version" et qu'elles ne se mélangent pas.
En es-tu sur qu'il n'y a pas de melange (du genre partage de code)?
Le problème surgit avec l'option d'optimisation globale (/GL) qui en
gros compile tout les différents fichiers sources comme si c'était
un seul fichier unique.
Je cherche à savoir si cette erreur est une conséquence de cette
optimisation globale, ou si c'est juste la manifestation d'un
problème qui relève bien du code.
Cette histoire de template instanciée de manière identique à
l'ensemble des codes sources compilés, ça fait un peu effet de bord
je trouve...
Ca je comprends tout à fait. Là où je suis davantage surpris c'est si les 2
unités ont chacune leur propre "version" et qu'elles ne se mélangent pas.
En es-tu sur qu'il n'y a pas de melange (du genre partage de code)?
Le problème surgit avec l'option d'optimisation globale (/GL) qui en
gros compile tout les différents fichiers sources comme si c'était
un seul fichier unique.
Je cherche à savoir si cette erreur est une conséquence de cette
optimisation globale, ou si c'est juste la manifestation d'un
problème qui relève bien du code.
Cette histoire de template instanciée de manière identique à
l'ensemble des codes sources compilés, ça fait un peu effet de bord
je trouve...
Cette histoire de template instanciée de manière identique à
l'ensemble des codes sources compilés, ça fait un peu effet de bord
je trouve...
On pourrait desirer que le non respect de l'ODR soit detecte, mais a
part ca je vois mal ce que tu veux. Tu peux mettre la definition du
template dans un namespace anonyme, mais alors tu ne peux plus
passer tes objets d'une unite de compilation a l'autre.
Cette histoire de template instanciée de manière identique à
l'ensemble des codes sources compilés, ça fait un peu effet de bord
je trouve...
On pourrait desirer que le non respect de l'ODR soit detecte, mais a
part ca je vois mal ce que tu veux. Tu peux mettre la definition du
template dans un namespace anonyme, mais alors tu ne peux plus
passer tes objets d'une unite de compilation a l'autre.
Cette histoire de template instanciée de manière identique à
l'ensemble des codes sources compilés, ça fait un peu effet de bord
je trouve...
On pourrait desirer que le non respect de l'ODR soit detecte, mais a
part ca je vois mal ce que tu veux. Tu peux mettre la definition du
template dans un namespace anonyme, mais alors tu ne peux plus
passer tes objets d'une unite de compilation a l'autre.