Discussion :

[JolyLoic]

J'était persuadé que la première chose que le compilateur faisait, s'était lire les instructions du preprocessor afin de savoir ce qu'il devait faire et ensuite, elles n'intervenaient plus, non ?

Oui, justement... Par exemple dans un A.h, imagines que tu as :

Code :

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

1
2
3
4
5
6
7
8
 
struct A
{
  int i;
#ifdef _DEBUG
  int j;
#endif
};

Dans un .cpp, tu as :

Code :

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

1
2
#define _DEBUG
#include "A.h"

Et dans l'autre, tu as

Code :

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

#include "A.h"

Alors, dans une de tes unités de compilation (le résultat de la compilation de ton cpp), A n'as pas le même, et est deux fois plus grand, que dans l'autre, d'où le soucis.

[Klaim]

Particulièrement fourbe.

[Arzar]

Particulièrement fourbe.

Oh bon sang j'ai eu exactement ce coup là une fois, sauf qu'au lieu d'un #define _DEBUG c'était un #define _SECURE_SCL 0 avec Visual Studio 2008 (pour désactiver les checks des iterateurs). Du coup la taille d'un std::vector passait de 24 à 16 octets.

Le pire étant que le #define avait été rajouté dans un header à dix mille lieux du bug, la sorte de header primitif qui se retrouve inclus en cascade dans *presque* tout le projet. Du coup un std::vector était censé avoir une taille de 16 octets *presque* partout sauf dans une poignée de .cpp où de banales fonctions prenant des std::vector& en paramètres se mettait à planter mystérieusement.

Tout ça quelques jours avant la deadline.

[zenux]

Ma dernière question était assez conne. En effet, l'erreur est facilement compréhensible.

Je crois que j'aurais encore pu chercher longtemps sans votre aide. Merci beaucoup.
Le pire, c'est que ça fait des mois que j'ai des "#ifdef _DEBUG" qui sont dans mes .h et je n'ai jamais eu de problème.