Qui De La Croix-Plate-Forme De Préprocesseur? (__WIN32__ ou __WIN32 ou WIN32 )?

Je vois souvent des __WIN32, WIN32 ou __WIN32__. Je suppose que cela dépend du préprocesseur (un à partir de visual studio, ou gcc, etc).

Faire maintenant, je dois d'abord vérifier pour les os et puis pour le compilateur utilisé? Nous sommes ici à l'aide de G++ 4.4.x, Visual Studio 2008 et Xcode (qui je suppose est un ccg) et de l'ATM, nous sommes juste en utilisant la __WIN32__, __APPLE__ et __LINUX__.

  • _WIN32 est systématique, plus offen que d'autres orthographes. Voir sourceforge.net/p/predef/wiki/OperatingSystems . La bonne pratique est de tester ce qui est pertinent dans chaque situation (OS, archi, compilateur,...) et de ne pas tester l'un pour l'autre. Et aussi de ne pas redéfinir votre propre.
InformationsquelleAutor math | 2010-06-07
  1. 14

    Cela dépend de ce que vous essayez de faire. Vous pouvez vérifier le compilateur si votre programme veut faire usage de certaines fonctions (à partir de la chaîne de compilation gcc par exemple). Vous pouvez vérifier le système d'exploitation ( _WINDOWS, __unix__ ) si vous souhaitez utiliser certains OS des fonctions spécifiques (quel que soit le compilateur par exemple CreateProcess sur Windows et la fourche sur unix).

    Les Macros Visual C

    Macros pour gcc

    Vous devez vérifier la documentation de chaque compilateur afin d'être en mesure de détecter les différences lors de la compilation. Je me souviens que la chaîne d'outils gnu(gcc) a certaines fonctions de la bibliothèque C (libc) qui ne sont pas sur d'autres toolchains (comme Visual C par exemple). De cette façon, si vous voulez utiliser ces fonctions de base que vous devez détecter que vous utilisez GCC, donc le code que vous devez utiliser sont les suivantes:

    #ifdef __GNUC__
//do my gcc specific stuff
#else
//... handle this for other compilers
#endif
    InformationsquelleAutor INS
  2. 36

    Cet article répond à votre question:

    L'article est assez long, et comprend des tableaux qui sont difficiles à reproduire, mais voici l'essentiel:

    Vous pouvez détecter de style Unix, OS avec:

    #if !defined(_WIN32) && (defined(__unix__) || defined(__unix) || (defined(__APPLE__) && defined(__MACH__)))
    /* UNIX-style OS. ------------------------------------------- */

#endif

    Une fois que vous savez que c'est Unix, vous pouvez trouver si c'est la norme POSIX et la version POSIX avec:

    #include <unistd.h>
#if defined(_POSIX_VERSION)
    /* POSIX compliant */
#endif

    Vous pouvez vérifier les systèmes dérivés BSD avec:

    #if defined(__unix__) || (defined(__APPLE__) && defined(__MACH__))
#include <sys/param.h>
#if defined(BSD)
    /* BSD (DragonFly BSD, FreeBSD, OpenBSD, NetBSD). ----------- */

#endif
#endif

    et Linux avec:

    #if defined(__linux__)
    /* Linux  */
#endif

    et Apple systèmes d'exploitation avec

    #if defined(__APPLE__) && defined(__MACH__)
    /* Apple OSX and iOS (Darwin) */
#include <TargetConditionals.h>
#if TARGET_IPHONE_SIMULATOR == 1
    /* iOS in Xcode simulator */
#elif TARGET_OS_IPHONE == 1
    /* iOS on iPhone, iPad, etc. */    
#elif TARGET_OS_MAC == 1
    /* OS X */
#endif
#endif

    Windows avec Cygwin

    #if defined(__CYGWIN__) && !defined(_WIN32)
    /* Cygwin POSIX under Microsoft Windows. */
#endif

    Et non-POSIX Windows avec:

    #if defined(_WIN64)
    /* Microsoft Windows (64-bit) */
#elif defined(_WIN32)
    /* Microsoft Windows (32-bit) */
#endif

    L'intégralité de l'article répertorie les symboles suivants et indique les systèmes de définir et quand: _AIX, __APPLE__, __CYGWIN32__, __CYGWIN__, __DragonFly__, __FreeBSD__, __gnu_linux, hpux, __hpux, linux, __linux, __linux__, __MACH__, __MINGW32__, __MINGW64__, __NetBSD__, __OpenBSD__, _POSIX_IPV6, _POSIX_MAPPED_FILES, _POSIX_SEMAPHORES, _POSIX_THREADS, _POSIX_VERSION, sun, __sun, __SunOS, __sun__, __SVR4, __svr4__, TARGET_IPHONE_SIMULATOR, TARGET_OS_EMBEDDED, TARGET_OS_IPHONE, TARGET_OS_MAC, UNIX, unix, __unix, __unix__, WIN32, _WIN32, __WIN32, __WIN32__, WIN64, _WIN64, __WIN64, __WIN64__, WINNT, __WINNT, __WINNT__.

    Un article connexe (archive.org lien) couvre la détection des compilateurs et des versions de compilateur. Il répertorie les symboles suivants: __clang__, __GNUC__, __GNUG__, __HP_aCC, __HP_cc, __IBMCPP__, __IBMC__, __ICC, __INTEL_COMPILER, _MSC_VER, __PGI, __SUNPRO_C, __SUNPRO_CC pour la détection des compilateurs, et __clang_major__, __clang_minor__, __clang_patchlevel__, __clang_version__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__, __GNUC__, __GNUG__, __HP_aCC, __HP_cc, __IBMCPP__, __IBMC__, __ICC, __INTEL_COMPILER, __INTEL_COMPILER_BUILD_DATE, _MSC_BUILD, _MSC_FULL_VER, _MSC_VER, __PGIC_MINOR__, __PGIC_PATCHLEVEL__, __PGIC__, __SUNPRO_C, __SUNPRO_CC, __VERSION__, __xlC_ver__, __xlC__, __xlc__ pour la détection des versions de compilateur.

    • Liens brisés, et je viens de poster le lien sans la moindre explication, je considère pas une bonne QA style. Même quand ce serait juste un commentaire. S'il vous plaît essayer de résumer l'article.
    • Bon appel. J'ai mis à jour l'article pour donner beaucoup plus de détails, et également fournir des liens vers d'archive.org afin de mieux gérer le site en voie de disparition.
    InformationsquelleAutor Charphacy
  3. 3

    Ne vois pas pourquoi vous devez. Vous pourriez avoir à n'oubliez pas de préciser la définition manuellement sur votre compilateur de ligne de commande, mais c'est tout. Pour l'enregistrement, Visual Studio définition est _WIN32 (avec un trait de soulignement) plutôt que de __WIN32. Si ce n'est pas définie, alors il n'est pas défini et il ne sera pas question.

    • Donc je pourrais écrire la #ifdef __WIN32__ seule fois et non pas #ifdef WIN32 || __WIN32 || __WIN32__
    • Oui, mais vous devez n'oubliez pas de mettre dans la définition de préprocesseur-vous sur la ligne de commande si vous avez décidé d'utiliser un autre compilateur.
    • Autant que je sache _WIN32 est définie pour tous (moderne) des compilateurs pour Windows (à l'exclusion de la Crispation bien sûr). Pas besoin de le définir vous-même...
    • Votre #ifdef-l'expression est fausse. Il devrait être #if defined(WIN32) || defined(__WIN32) || defined(__WIN32__). Voir C les directives de Préprocesseur et les opérateurs booléens de référence.
    • Ou peut-être #if WIN32 || _WIN32 || __WIN32__. Undefined noms sont traités comme zéro. La question est de savoir ce qui doit être fait en cas de #define _WIN32 0.
    • Vous avez déjà répondu, pourquoi votre proposition de #if-l'expression est inappropriée. Si vous voulez vérifier si un symbole de préprocesseur est défini, il est préférable de vérifier si un symbole de préprocesseur est défini.
    • Mais pourquoi pensez-vous qu'il est plus approprié de traiter les #define _WIN32 0 le même que #define _WIN32 1, plutôt que de #undef _WIN32 ?
    • Parce que c'est la façon dont il est spécifié et documenté. Macros Prédéfinies: "_WIN32 Défini pour les applications Win32 et Win64."

    InformationsquelleAutor Billy ONeal
  4. 2

    J'ai reconstruire ma réponse... Merde, édition berserk :P:

    Vous n'avez pas besoin d'utiliser partical un. Et probablement pour MacOSX, Linux et autres Unix-aime vous n'avez pas besoin d'utiliser du tout.

    Plus populaire est (autant que Google dit la vérité) est _WIN32.

    Vous jamais définir "à la main" dans votre code source. Il est défini dans l'une de ces façons:

    comme une ligne de commande préprocesseur/compilateur drapeau (comme g++ -D _WIN32)

    ou il est prédéfini par le compilateur lui-même (la plupart des compilateurs pour Windows prédéfinir _WIN32, et parfois d'autres comme WIN32 ou _WIN32_ trop. - Alors vous n'avez pas besoin de s'inquiéter à propos de la définition, à tous, compilateur ne l'ensemble des travaux.

    Et mon ancienne réponse:

    Vous ne pas "avoir à" quoi que ce soit. C'est juste pour le multi-compatibilité de plate-forme. Souvent, la version de code pour tous les Unix-aime (y compris Linux, Mac, BSD, Solaris...) et d'autres POSIX plate-forme sera tout à fait la même et il doit y avoir quelques changements pour Windows. Donc les gens à écrire leur code, en général, pour Unix aime et de mettre Windows uniquement (par exemple. DirectX instructions, les Fenêtres, les chemins de fichiers...) les pièces entre #ifdef _WIN32 et #endif.

    Si vous avez quelques pièces, par exemple. X-Window-system uniquement, ou MacOS-seulement, vous n'avez semblable à quelque chose comme #ifdef X_WINDOW ou #ifdef MACOS. Ensuite, vous devez définir une bonne définition de préprocesseur lors de la compilation (gcc à l'aide de drapeau-D, comme par exemple. gcc -D _WIN32).

    Si vous n'écrivez pas tout dépend de la plateforme, code, alors vous n'avez pas besoin de soins pour un #ifdef, #else, #endif blocs. Et la plupart des compilateurs pour Windows/préprocesseurs autant que je sache prédéfinies et certains symboles comme _WIN32 (le plus populaire, aussi loin que google dit la vérité), WIN32, _WIN32_, etc. Donc le compiler sous Windows, plus probablement, vous n'avez pas besoin de faire autre chose que juste de la compilation.

    • Probablement ma question est très floue: je ne veux pas définir WIN32, mais à utiliser avec #ifdef. Et je me demandais pourquoi il ya tellement de nombreuses variantes et si il y en a un qui devrait fonctionner avec la plupart des compiliers.
    • Comme je l'ai dit, les gens utilisent ce qu'ils aiment, il n'y a pas de norme. De toute façon, vous pouvez le définir lors de la compilation de vous-même en ligne de commande (et aussi en IDE options, etc.), donc, à l'aide de "non pris en charge" WIN32__ au lieu de "bon" _WIN32 n'est pas un problème. Et, comme je l'ai dit, la plupart des compilateurs de soutien _WIN32 et un certain soutien de nombreux autres (mingw soutien WIN32 _WIN32 WIN32 __WIN32 MINGW32 WINNT WINNT __WINNT). Voir celui-ci: stackoverflow.com/questions/142508/...
    InformationsquelleAutor silmeth
  5. 0

    Soupir - ne comptez pas sur le compilateur n'importe quoi - spécifier la plate-forme de construction de dans votre Makefile. Tout simplement, quelque chose commençant par _ est dépendant de l'implémentation et de ne pas portable.

    J'ai essayé votre méthode une fois, sur un très gros projet, et entre rebondir entre Soleil-C++ et GCC nous avons juste décidé d'aller avec le Makefile de contrôle, plutôt que d'essayer d'en déduire ce que les compilateurs allaient faire.

    • Vous pouvez créer des wrappers pour des comportements différents et l'utilisation de ces emballages. Cette façon de traiter avec plate-forme/compilateur différences en seulement quelques fichiers source, qui est (à mon avis) mieux que de traiter avec les makefiles pour chaque plate-forme.
    • Vous avez un argument valable. Cependant, je ne peux pas imaginer une situation où vous êtes à la prise en charge de plusieurs plates-formes et ne sont pas en utilisant des fichiers "Makefile" d'une certaine sorte (gmake/cmake/qmake) de toute façon. La bibliothèque Windows définitions link.exe ne sont pas les mêmes que gcc -L-L. Ni les paramètres d'optimisation du compilateur. Je préfère m'occuper de mes plate-forme de drapeaux dans un Makefile (ou un peu plus par l'inclusion) que d'avoir à ne pas oublier d'inclure platform_magic.h dans chaque en-tête/fichier source. Boost t-il votre manière en boost/system/config.php il détermine quelle plate-forme il est en cours d'exécution sur. Nous devons simplement accepter d'être en désaccord. 😀
    InformationsquelleAutor Chris K