Compatibilité C++11, C++14, 32 bits, 64 bits

Bonjour,

J'ai une application C++ qui tourne parfaitement sur Linux => aucun crash, aucun problème signalé par Valgrind.
Lorsque que je compile cette application avec Mingw/G++ sur Windows et que je l'exécute, parfois elle fonctionne très bien et parfois j'ai des crashs de façon aléatoire.
J'ai essayé de voir si je n'avais pas fait d'erreur dans les parties de code source qui crash mais je ne vois rien (je pourrais montrer des bouts de code source mais je doute que le problème viennent directement de là).

Par contre, je me pose pas mal de questions à propos des compatibilités.
En effet, j'ai Mingw 64bits et je compile mon application en C++14. J'utilise aussi quelques bibliothèques dont certaines sont en 64bits (SFML...) et d'autres en 32bits (glew32, opengl32...), en C++98, C++11 ou C++14, je n'en sais rien. Est-ce que cela peut poser des problèmes d'instabilités dans une application?

Merci d'avance.
Grégory

Citation:

---

Est-ce que cela peut poser des problèmes d'instabilités dans une application?

---

Oui, si on ne fait pas gaffe.

Le fait que votre programme fonctionne correctement sur une plateforme ne veut pas dire qu'elle est exempte de bugs.

La combo "Mingw/G++ sur Windows" n'est qu'un outil fort pratique pour voir ce bug latent.

Il vous reste à identifier ce bug, comme n'importe quel bug (débuggeur, coredump, etc...)

Citation:

---

Envoyé par zenux

je compile mon application en C++14. J'utilise aussi quelques bibliothèques dont certaines sont en 64bits (SFML...) et d'autres en 32bits (glew32, opengl32...),

---

Ça n'est pas possible. Un programme est soit entièrement 32 bits, soit entièrement 64 bits. Si tu veux un mélange des deux, c'est forcément dans deux process séparés (qui peuvent communiquer entre eux par divers mécanismes, qui eux peuvent franchir la frontière 32/64).

Tu peux essayer de forcer la compilation en 32b pour vérifier. Le commutateur doit être -m32 si je me souvient bien.
Si tu arrives à le faire fonctionner comme ça, méfie toi, les variables ne font pas la même taille en 32 et 64b...

Citation:

---

Envoyé par JolyLoic

Ça n'est pas possible. Un programme est soit entièrement 32 bits, soit entièrement 64 bits. Si tu veux un mélange des deux, c'est forcément dans deux process séparés (qui peuvent communiquer entre eux par divers mécanismes, qui eux peuvent franchir la frontière 32/64).

---

Le "chunking" entre 32 et 64 bits n'est pas possible ?
Il l'est bien entre 16bits et 32bits pourtant.

personnellement je ne melange pas du 32 bits et du 64 bits.tes crashs viennent peut etre de là.
tu as la librairie opengl32 en 64 bits fournie avec mingw64 (repertoire x86_64-w64-mingw32\lib de ton repertoire de mingw64,fichier libopengl32.a),quant à glew tu peux aussi le compiler en 64 bits à partir des sources à priori. (avec ou sans msys2, à voir)

Citation:

---

Envoyé par bacelar

Le "chunking" entre 32 et 64 bits n'est pas possible ?
Il l'est bien entre 16bits et 32bits pourtant.

---

Tu veux dire "thunking", non?

Hélas, ce n'est pas possible en 32/64 bits. (Edit: En fait, pour *n*x, je ne sais pas. Mais ce n'est pas possible sous Windows)

Par contre, un projet conçu en 32 bits peut être compilé pour 64 bits; tant qu'il ne fait pas de bêtises comme stocker un pointeur dans un entier autre que intptr_t, il n'est pas censé y avoir de problème. Les programmes non-compatibles 64 bits sont ceux qui ne respectent pas ce critère... (ceux qui mettent des pointeurs dans des int ou, sous Windows, des long)

Merci beaucoup pour vos réponses.
Je viens de vérifier les DLLs que j'utilise avec un petit script PERL et elles sont bien en 64 bits d'après le header. C'est juste le nom qui contient le chiffre "32" qui m'a fait croire que j'avais certaines DLL en 32 bits :aie:

Concernant les différentes DLL qui sont compilés en C++98, C++11 ou C++14: est-ce que cela peut engendrer des problèmes ?
Par exemple, la classe std::string a changé depuis C++11 (nouveau constructeur...): est-ce que ça se passe bien si une DLL utilisant std::string a été compilé avec C++98 et mon code source avec C++14 (-static-libstdc++) ?

Oui, cela pose problème.
C'est pour cela qu'il faut plutôt privilégier les API C qui n'échangent que des types simples pour les Dll, et qui ne passe pas la responsabilité de la libération des objets à d'autres modules binaires.

Merci pour l'info. Les bibliothèques que j'utilise semblent bien fournir une API C.
Tout ce que je compile (DLL & exe) est en C++14. Donc je suppose que je ne devrais pas avoir de problème à ce niveau là.

Je viens de trouver mon problème:
- Quand je compile mes DLL, je fais un #define de _DEBUG dans la configuration Eclipse
- Quand je compile mon exe, je fais un #define de D_DEBUG dans la configuration Eclipse (petite faute de frappe que je n'ai pas sur Linux).
Vu que ce _DEBUG est utilisé dans les .h, je me retrouve donc à compiler des headers différents entre mes DLL et l'exe => crash.

Encore merci pour toutes ces infos.

Citation:

---

je me retrouve donc à compiler des headers différents entre mes DLL et l'exe => crash.

---

Les headers ne se compilent pas, ils s'incluent.
Si ça compile mais que cela plante au runtime quand on mélange du DEBUG et du RELEASE, c'est assez souvent un défaut étanchéité mémoire entre les modules (malloc dans un module avec un free dans un autre).

Is je ne me trompe pas, _DEBUG n'est pas standard, mais NDEBUG l'est (pour Not Debug), je me base généralement sur ce flag.

Citation:

---

c'est assez souvent un défaut étanchéité mémoire entre les modules

---

Oui mais je ne crois pas que c'est mon cas. Un exemple sans allocation mémoire dynamique qui peut planter:

Code:

---

1 2 3 4 5 6 7

struct MyStruct{ int a; #ifdef _DEBUG int b; #endif int c; }

---

Si j'ai un module A qui a définit _DEBUG et un module B qui ne le définit pas: dans ce cas, je suppose que je peux avoir un problème si les deux modules se transmettent MyStruct, non ?

Effectivement, c'est un cas très artificiel de plantage sans problèmes d'allocation mémoire dynamique.

Mais il y a clairement une couille dans le potage pour la définition des éléments de l'API C, qui doivent clairement ne pas être fonction de constantes de compilation d'un module (et donc pas forcément les mêmes pour les autres).