Ca ne me parait pas une bonne idée : tu devrais avoir deux versions de ton binaire avec potentiellement des différences de comportement en mode debug et en mode "classique". Tu auras deux runtimes différents, donc potentiellement deux comportements différents. Quand tu fais du multithread, ça peut suffire à ne pas pouvoir reproduire des bugs que tu aurais dans un environnement et pas dans un autre. Et si tu voulais utiliser fil-c pour la phase de test, effectivement ça pourrait te permettre de détecter certaines choses en amont, mais le problème c'est que tes tests ne couvrent pas forcément tous les cas que tu vas rencontrer en prod. Ca peut donc aider, mais ce n'est pas non plus la panacée. Ta prod qui tourne en C classique pourra toujours planter salement.
[^] # Re: ch'tite dépêche ?
Posté par totof2000 . En réponse au lien Fil-C : un C sûr de sa mémoire. Évalué à 4.
Ca ne me parait pas une bonne idée : tu devrais avoir deux versions de ton binaire avec potentiellement des différences de comportement en mode debug et en mode "classique". Tu auras deux runtimes différents, donc potentiellement deux comportements différents. Quand tu fais du multithread, ça peut suffire à ne pas pouvoir reproduire des bugs que tu aurais dans un environnement et pas dans un autre. Et si tu voulais utiliser fil-c pour la phase de test, effectivement ça pourrait te permettre de détecter certaines choses en amont, mais le problème c'est que tes tests ne couvrent pas forcément tous les cas que tu vas rencontrer en prod. Ca peut donc aider, mais ce n'est pas non plus la panacée. Ta prod qui tourne en C classique pourra toujours planter salement.