• [^] # Re: 2003 / AGC / Bombardier / Alstom

    Posté par . En réponse au lien Des lignes de métro, tramway et RER de la RATP concernées par le bogue de 2038. Évalué à 3.

    Le problème se pose si on a quelque chose du genre dans le .h :

    // Ze big boolette
#define true 0
#define false 1
// Le contrat dont j'ai demandé l'implémentation
class A
{
 public:
 ...
 // quiDependeDe est optionel, et prend une valeur par défaut
 // valeur qui embêtait l'implémenteur, d'où ze big boolette
 bool faireUnTruc(bool quiDependeDe = true);
 ...
};

    Et dans le .cpp, faireUnTruc(...) retourne true ou false selon le sens du vent et l'âge du capitaine.

    C'est à l'endroit où j'exploite le code sous-traité que se pose le problème :

     ...
 if( zeA.faireUnTruc(peuImporteMonBool) )
 {
 // Code exécuté si true, mais ...
 }else{
 // Code exécuté si false, mais ...
 }
 ...

    faireUnTruc(...) peut renvoyer true, on peut même le debugger pas à pas et observer le return true.
    Au retour, le test deviendra if( 0 ) et l'exécution partira dans le else, et quelques neurones partent dans le néant.

    La première hypothèse qui vient quand on observe ça, c'est : ah, je suis dans l'une de ces rares situations où l'IDE a loupé des choses, oublié de recompiler certains morceaux de code, etc (réellement vécu, mais c'est une autre histoire). On vire tout le build, et on recompile, on re-debug pas à pas, et on grille à nouveau quelques neurones.

    La seconde hypothèse, c'est : wow, le compilo est buggé ???

    Et une demi-journée plus tard, on s'aperçoit que deux lignes ont été ajoutées, et que le compilo a encore raison ...
    Ensuite, on décroche son téléphone, et on gueule ...