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

[Médinoc]

Note: Pour les exceptions, Visual semble suivre les mêmes conventions que Borland.

D'ailleurs, j'ai du mal à voir l'intéret d'une méthode what() non-virtuelle, vu que d'après MSDN, la norme ne donne pas non plus de constructeur prenant une chaîne en paramètre...

[white_tentacle]

D'ailleurs, j'ai du mal à voir l'intéret d'une méthode what() non-virtuelle, vu que d'après MSDN, la norme ne donne pas non plus de constructeur prenant une chaîne en paramètre...

En fait, je pense que c'est surtout lié au "pas de surcoût inutile" qui prévaut en C++. Mettre what et le destructeur en virtuel par défaut, c'est imposer une vfptable à toutes les exceptions, sachant que le plus souvent, on s'en passerait.

Par contre, c'est étonnant la quantité de documentation qu'on trouve sur le net ou what() est définie en virtual (sous gcc, ce n'est pas virtual).

[Médinoc]

Le problème, c'est qu'il faut voir fonctionnellement ce que signifie what() sachant que la norme ne prévoit pas de constructeur avec const char * (Microsoft dit que ses propres constructeurs sont des extensions).

Avec cela, what() ne changerait jamais selon le type d'exception, rendant ce genre de code inutile:

Code C++ :

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

1
2
3
4
5
try {
	faireUnTruc();
} catch(exception const &) {
	cerr << e.what() << endl;
}

Ou bien, Microsoft se trompe, et il existe bel et bien dans la norme un constructeur std::exception(char const *), auquel cas ça marcherait.

[white_tentacle]

Sous gcc, pas de constructeur std::exception(const char*), donc je pense qu'il ne fait pas partie de la norme.

Je me demande à quel point what ne fait pas tout simplement partie de l'historique (ie, on l'a mis au départ, puis on s'est dit que mettre virtual par défaut était une mauvaise idée, mais what est resté quand même).

Cela dit, avoir une méthode "standardisée" pour récupérer une description sur une exception, même si cette méthode n'est pas virtuelle, me semble une bonne chose (notamment, utilisable dans des templates).

Il est clair, par contre, que ton code ne fera rien de très utile. Peut-être aussi, parce que les exceptions doivent en général se gérer plus "finement", et que quand tu en arrives à attraper std::exception, alors tu peux aussi faire un dump de l'adresse mémoire ou ce genre de choses pour ton output de debug...

[Jean-Marc.Bourguet]

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.

Reference STP? Je suis d'accord au sujet de l'absence d'exception, mais la norme de 98 et le CD de C++0X, que j'ai tous les deux sous les yeux, demandent bien que what() soit virtuel.

Il n'y a en effet pas de constructeur a base de char const* pour std::exception dans ces textes, mais les exceptions definies dans <stdexcept> (logic_error, domain_error, etc) ont un tel constructeur.

[white_tentacle]

Je rectifie ce que j'ai dit plus haut. what() est bien virtual sous gcc.

On ne m'y reprendra plus, à oublier des const dans mes tests .