IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

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


Sujet :

C++

  1. #1
    Membre actif
    Profil pro
    Inscrit en
    Février 2006
    Messages
    396
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Février 2006
    Messages : 396
    Points : 230
    Points
    230
    Par défaut 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

  2. #2
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    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...)

  3. #3
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    Citation Envoyé par zenux Voir le message
    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).
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  4. #4
    Membre expérimenté Avatar de SkyZoThreaD
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Juillet 2013
    Messages
    583
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Juillet 2013
    Messages : 583
    Points : 1 615
    Points
    1 615
    Par défaut
    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...
    La liberté est à la sociologie ce que l'instant présent est à la physique relativiste.

  5. #5
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    Citation Envoyé par JolyLoic Voir le message
    Ç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.

  6. #6
    Membre confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2015
    Messages
    294
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mars 2015
    Messages : 294
    Points : 558
    Points
    558
    Par défaut
    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)

  7. #7
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Citation Envoyé par bacelar Voir le message
    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)
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  8. #8
    Membre actif
    Profil pro
    Inscrit en
    Février 2006
    Messages
    396
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Février 2006
    Messages : 396
    Points : 230
    Points
    230
    Par défaut
    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

    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++) ?

  9. #9
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    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.

  10. #10
    Membre actif
    Profil pro
    Inscrit en
    Février 2006
    Messages
    396
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Février 2006
    Messages : 396
    Points : 230
    Points
    230
    Par défaut
    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.

  11. #11
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    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).

  12. #12
    Expert éminent sénior

    Avatar de dragonjoker59
    Homme Profil pro
    Software Developer
    Inscrit en
    Juin 2005
    Messages
    2 045
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Software Developer
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 2 045
    Points : 11 368
    Points
    11 368
    Billets dans le blog
    10
    Par défaut
    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.
    Si vous ne trouvez plus rien, cherchez autre chose...

    Vous trouverez ici des tutoriels OpenGL moderne.
    Mon moteur 3D: Castor 3D, presque utilisable (venez participer, il y a de la place)!
    Un projet qui ne sert à rien, mais qu'il est joli (des fois) : ProceduralGenerator (Génération procédurale d'images, et post-processing).

  13. #13
    Membre actif
    Profil pro
    Inscrit en
    Février 2006
    Messages
    396
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Février 2006
    Messages : 396
    Points : 230
    Points
    230
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 ?

  14. #14
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    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).

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. bits,bytes,bit word ?
    Par Battosaiii dans le forum C
    Réponses: 2
    Dernier message: 17/03/2006, 12h29
  2. Comment lire un char bit a bit ?
    Par damien99 dans le forum C++
    Réponses: 9
    Dernier message: 02/02/2006, 22h57
  3. Lire bit par bit
    Par The_Undertaker dans le forum C++
    Réponses: 8
    Dernier message: 01/07/2005, 12h43
  4. Conversion de handles 16 bits <--> 32 bits
    Par Alcatîz dans le forum Windows
    Réponses: 6
    Dernier message: 13/12/2003, 14h40
  5. Désassemblage à la main 16 bits / 32 bits
    Par le mage tophinus dans le forum Assembleur
    Réponses: 12
    Dernier message: 19/04/2003, 01h55

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo