Discussion :

[tiger360]

Bonjour
j'aimerai savoir si c'était possible grâce a une variable d'environnement ou autre chose sur quel OS je tourne pour adapter un bout de programme

je suis sous codeblocks

Cordialement .

[Melem]

Les programmes C++ sont des programmes compilés c'est-à-dire natifs pour l'OS. Un .exe ne s'exécute pas sous linux et un exécutable elf de même sous Windows. C'est à la compilation donc que tu dois te poser la question : "pour quelle plateforme je compile ?" et adapter ton code en fonction de ta réponse. Généralement ça se fait à l'aide de #ifdef ... #else ... #endif, etc.

[ram-0000]

Le problème ne serait pas plutôt "Sous quelle version d'OS je tourne (2000, XP, Vista) ?"

En C++, il n'y a pas de réponse à ta question par contre, si tu donnes ta plateforme, tu sera redirigé dans le bon forum (Linux, Windows, ...)

[tiger360]

ah ok merci
et donc si je veux avoir un un exécutable elf pour linux
je dois le compiler sur un codeblocks qui tourne sur linux

et quand on parle de portabilité de programme ça voudrai dire qu'on peut le compiler sur les 2 OS et donner le même résultats
c'est bien ça ?

[loufoque]

Tu peux compiler sous un système A pour un système B.
Ça s'appelle la cross-compilation.

[koala01]

Salut,

Lorsque l'on parle de "programme portable" en C++ (tout comme en C, d'ailleurs), on veut effectivement indiquer le fait que, quel que soit le compilateur utilisé, quelle que soit l'OS (ex window / linux) ou la plateforme (il n'y a pas que les PC's ) la compilation réussira et fournira un exécutable qui réagira de manière identique.

Ceci dit, il existe effectivement une série de symboles préprocesseur définis qui permettent de connaitre l'OS ou le compilateur utilisé.

Ainsi, on trouve des directives précisant

• l'OS sur lequel la compilation s'effectue (ou auquel elle est destinée)
• La bibliothèque standard (similaire telle que MFC) utilisée
• Le compilateur utilisé
• le standard suivi par le langage
• L'architecture à laquelle le programme est destiné
• j'en passe, et de meilleures

Il est donc possible de décider certaines adaptations en fonction de la manière dont le compilateur respecte la norme, ou du type de socket - par exemple - utilisé par l'OS sous une forme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
if defined(_WIN32) || \
   defined(_WIN64) || \
   defined(__WIN32__) || \
   defined(__TOS_WIN__) || \
   defined(__WINDOWS__)
#include <winsok2.h>
/* il y a sans doute pas mal de truc à adapter à winsok ;) */
#elif defined(__linux)
/* tout ce qui sera adapté à linux */
#elif defined(/*un troisieme OS*/)
/*...*/
#endif

Dans le même ordre d'idée, le compilateur Borland présente certaines différences envers la norme en ce qui concerne la définition des exceptions...

En effet, la norme précise que le destructeur et la méthode what d'une exception ne doivent pas lancer d'exception, et que ni l'un ni l'autre ne doivent être virtuels.

Mais voilà, le compilateur de borland (du moins dans la version utilisée par BCB 6) demande à ce que ces deux méthodes soient virtuelles et... ne demande pas de thorw() déclaratif.

Il est donc possible d'écrire un code proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#if defined(__BORLANDC__)
    #define EXCEPTIONNEEDTHROW 
    #define EXCEPTINNEEDVIRTUAL virtual
#else
    #define EXCEPTIONNEEDTHROW throw()
    #define EXCEPTINNEEDVIRTUAL
#endif
 
class MyException : public std::exception
{
    public:
        MyException(/*...*/)/*:...*/
        {
        }
        EXCEPTINNEEDVIRTUAL ~MyException() EXCEPTIONNEEDTHROW 
        {
        }
        EXCEPTINNEEDVIRTUAL const char* what() const EXCEPTIONNEEDTHROW 
        {
        }
};

et l'on pourrait multiplier les exemples