Discussion :

[screetch]

je ne comorend pas trop ou tu veux en venir; j'ai arrete ma position ici:
tu as des unites de compilation qui voient un header different, avec du code different, mais avec la meme signature.
Je dis que dans ce cas la, le linker est libre de choisir la version qui lui plait. Il y a deux cas ou c'est autorisé: les fonctions inline )qui seront surement en plusieurs exemplaires dans les fichiers sources, puisque copiees au besoin) et les fonctions templates (comme les fonctions inline, elles sont instanciees sur demande, donc il se peut qu'elles soient dans deux unites de compilation separees). Sinon, il ne doit y avoir qu'une seule definition de la methode pour toutes les unites de compilation.

donc je te dis que dans ce cas (inline ou template) le linker est susceptible de choisir nimporte quelle version, surtout la mauvaise. Il a le droit de choisir si il instancie les methodes comme il veut, et il a le droit de choisir la version qui lui plait, en fonction des dernieres elections legislatives ou de la position de Jupiter.

Ce que tu me décris la c'est un des problemes possibles, tu bidouilles un fichier et il utilise une autre methode dans un fichier qui n'a rien a voir, ca ne m'etonne pas puisque le linker est en droit de choisir. En modifiant un fichier, tu as pu
* changer la liste des fichiers sur la ligne de commande, du coup le linker rencontre une autre implementation en premier
* retirer une des implementations (pour certaines methodes, comme un constructeur ou un destructeur, le compilateur genere automatiquement pour chaque fois ou il voit la classe peut etre, encore une fois si ca lui fait plaisir, c'est lui qui a raison de toute facon)
* ajouter une implementation differente en appelant une methode ou ajoutant un include

c'est sensible, il n'y a pas de regle ni de garantie, il n'y a pas a expliquer pourquoi ca devrait marcher ou ca devrait pas marcher, ca depend de parametres completement inconnus. La seule possibilite c'est de compiler avec TOUJOURS la meme definition des methodes inline.


Si la solution de jabbounet ne fonctionne pas a cause de visual studio 6, je recommende ma version qui te force a definir la macro partout. ainsi si un fichier inclut le code sensible sans avoir inclu la definition de la macro, ca ne compilera pas au lieu d'inserer des methodes moisies.
Ou sinon definir ta macro au niveau du projet

[ternel]

J'ai envie de dire...

Quel que soit ton outil, il doit faire ce que tu ferais sans lui. Sinon, c'est un traitre.

Autrement dit, que tu utilise Visual Studio, make, scons ou pray-for-compile, la compilation du projet devrait être équivalente à :
g++ *.cpp -o programme

(bon d'accord, un poil plus complexe pour tenir compte de l'arborescence, et des -Dmacro)

Toute bidouille qui l'empèche est pour moi la promesse d'une crise de larmes

[Bousk]

C'est exprès, j'ai juste recompilé un seul cpp, celui qui me fait deux types pour une même instance. Il n'y a qu'un seul cpp qui utilise cette classe spécifique.

Comment un cpp qui n'est compilé qu'une seule fois se retrouverait-il par magie compilé 2 fois chez toi ?
Un .cpp ça définit une unité de compilation, et jusqu'à preuve du contraire, ou à moins que le forum partage des sujets avec un forum philosophique, unité ça veut dire 1.

[camboui]

On parle du code qui se trouve dans les headers, pas dans les cpp.

[Bousk]

On parle du code qui se trouve dans les headers, pas dans les cpp.

Et après ?

Si "problème" il y a c'est parce que plusieurs unités de compilation voient un header différent.
Compiler un unique cpp ne montrera jamais aucune erreur comme ça.
C'est à toi de t'assurer de la cohérence du header, et la solution la plus simple est donnée depuis le début : les define au niveau du projet.

C'est exprès, j'ai juste recompilé un seul cpp, celui qui me fait deux types pour une même instance. Il n'y a qu'un seul cpp qui utilise cette classe spécifique.
La compilation des cpp, quand on n'utilise pas les entêtes précompilées, est complêtement indépendante entre les cpp et recompile tous les h qui en dépendent, non ?

Etant donné qu'un header n'est pas compilé mais inclus, ce qui signifie copié/collé tel quel dans l'unité de compilation, je ne comprends rien.
De la même manière, une unité de compilation ne pourra pas inclure 2 fois le même header comme présenté où une class est déclarée ou tu auras des erreurs multiple definition.