[Normes, standards] Programmation Multi Plateforme en C++

Bonsoir à tous,

Depuis quelques temps, j'essaie d'écrire le code le plus propre et professionnel possible, et c'est donc naturel que je veuille le rendre le "plus multiplateforme" possible. Le problème est que j'ai un peu de mal avec (je ne m'étais jamais réellement soucié du problème ...).

En fait, j'ai discuté un peu sur IRC avec des gens, et on m'a conseillé le man de feature_test_macros. J'y ai lu des choses intéressantes mais je dois avouer que ça me dépasse un peu. Par exemple définir ceci :

#define _POSIX_C_SOURCE 1

d'après le man, cela revient à certifier que tout le code est compatible avec la norme POSIX.1-1990 et ISO C ... Seulement j'aimerais bien arriver à savoir quelles fonctions sont sous cette norme en C/C++ par exemple ... Le même problème s'applique aux chemins : sys/* est un chemin UNIX, mais ça je l'ai découvert en demande sur IRC, je n'ai pas trouvé de document expliquant exactement ce qui est sous norme UNIX, etc etc ...

Aussi, dans le man, souvent, j'ai pu voir "Linux manual", "Unix manual" "POSIX manual" ... mais ce n'est pas une façon de savoir si une fonction est certifiée POSIX je suppose ... Bref, je suis un peu perdu, j'aimerais savoir si vous avez des tuyaux pour coder efficacement et en respectant parfaitement les normes des applications multiplateformes.

Merci de m'avoir lu, bonne soirées et bonne fêtes !

En ce qui concerne POSIX, Wikipedia est ton ami ! :)

En ce qui concerne Linux et les standard qui sont bâtis dessus, Wikipedia est aussi ton ami ! :)

(accordé : pour le dernier, encore faut-il être au courant de son existence. Et toutes les distributions ne sont pas basées sur le LSB).

Salut

tu peux trouver des informations précieuses sur le sujet... dans la doc de boost. Quand certains points sensibles aux variations d'OS, pas mal de notes expliquent ce qui se passe. Je l'ai directement constaté dans la doc de Boost.filesystem par exemple.

D'une manière générale, toutes les normes ne sont pas nécessairement bonnes et/ou compatibles entre elle. Ce qui est important c'est de conserver une bonne cohérence, un bon design et... que le code fonctionne ! De plus, la plupart des normes ne sont pas parfaitement implémentées selon les plateformes, sans parler des points des normes qui laissent libre court à plusieurs implémentations.

Ne te focalise d'ailleurs pas que sur le code C++ : une chaîne de compilation multiplateforme bien conçue est aussi nécessaire.

Je suis en ce moment en train de développer un outil que je veux multiplateforme (je ne peux tester que sur linux et windows pour l'instant), et je dois souvent ajuster de petits détails cités nulle part, à cause de différences dans l'implémentation de la STL ou de boost (lorsque des implémentations différentes selon les plateformes apparaissent, comme c'est le cas pour Boost.Regex, pour prendre un exemple parmis d'autres). J'arrive à un code multiplateforme, mais un minimum de test sur chacune et d'adaptations qui ne sont normalisées nulle part sont nécessaires...

Tout d'abord, merci de vos réponses. Ton expérience avec Boost.regex est intéressante, bien qu'elle me dérange un peu. Le code ne devrait-il pas être correctement documenté afin que nous puissions coder sur un maximum de machine ?

Un exemple simple : gettimeofday(). Le man dit que cette fonction est conforme à POSIX, mais je ne sais pas vraiment comment m'en servir dans mon code ... Par exemple, comment à partir de directives de préprocesseur savoir si la machine sur laquelle on compile le code est conforme à cette norme ?

J'ai un peu creusé et je suis tombé sur deux trois trucs, comme :

Code:

---

cpp -dM foo.cpp

---

qui permet de connaître tous les defines spécifiques set à la compilation. Un grep sur la liste ne m'a pas donné de POSIX, mais à unix, _unix, linux, _linux, etc etc ... Donc pour cette fonction (gettimeofday), j'ai quelque chose comme cela :

Code:

---

1 2 3 4 5

#ifdef unix gettimeofday(...) #elif WIN32 // ... #endif

---

Seulement je n'ai pas de preuve tangible que cela est conforme à la norme ...

Je voudrais quand même rebondir sur une phrase bien particulière de ton premier post :

Citation:

---

Depuis quelques temps, j'essaie d'écrire le code le plus propre et professionnel possible, et c'est donc naturel que je veuille le rendre le "plus multiplateforme" possible.

---

Il y a une différence notable entre du code professionnel et du code normal. Bien évidemment, le code pro se doit d'être propre, car il est censé avoir une durée de vie importante. Du coup, il doit pouvoir être maintenu, donc relu, modifié, etc.

Mais le code pro n'a pas besoin d'être du code de qualité exceptionnelle. Je m'explique, avant que Adam et Eve ne montent au créneaux.

Du code de qualité exceptionnelle, tel que je l'entends dans cette phrase (et l'expression est mal choisie ; mais faisons simple pour une fois), c'est du code portable, écrit dans le respect le plus scrupuleux des normes en vigueur, complètement documenté, suivant un guide d'écriture plus ou moins standard (par exemple le guide qui préside au développement des projets GNU). Une simple recompilation suffit pour que le programme s'exécute de manière indifférente sur tel ou tel OS, en prenant en compte les disparités de chaque OS cible.

Le problème d'un tel code, c'est qu'il prends un temps nécessairement long à écrire et à tester. Hors, dans le monde professionnel, le temps est un ennemi. Un projet doit respecter un budget, et être développé dans un temps fini - qui n'accepte pas nécessairement les dépassements (les projets pour les grandes institutions sont bien souvent accompagnés de pénalités de retard que le sous-traitant va devoir payer par jour de retard après la date de livraison convenue). Il est donc important d'aller non pas vers la complétude parfaite, mais vers l'adéquation parfaite avec les besoins du client. Hors le client demande rarement un code multiplateforme, car il sait de quoi est composé le parc des utilisateurs de ce logiciel. De plus, et dans le cas où le client ne saurais pas indiquer une plateforme cible, il va laisser le choix au développeur pour que celui-ci impose sa solution matérielle en même temps que le logiciel lui même. Du coup, en tant que pro, on n'écrit que très rarement du code multiplateforme (en 11 ans, ça m'est arrivé sur deux petits projets ; et pour simplifier le développement, c'est une plateforme Eclipse+Java qui a été choisie).

Bien que le C et le C++ standard soient portables, ces langages sont très rarement employés pour créer des programmes qui seront exécutés sur différents environnements. Si c'est nécessaire, on se heurte a un écueil majeur : la portabilité du système GUI utilisé. Aujourd'hui, on a plusieurs solutions tout à fait acceptables : Qt, wxWidgets, ... Ce n'était pas le cas il y a seulement 4 ans (Qt sous Windows n'était pas sous licence libre pour développer des outils de manière commerciale ; et la licence par siège coutait un bras).

Un autre écueil, de moindre importance, frappe aussi : la portabilité du système de build. autoconfig est censé réduire les problèmes de portabilité, mais il nécessite une plateforme ayant une base POSIX assez complète (linux, cygwin, mingw et une grosse partie des *nix existants). cmake peut être une solution viable, mais il reste encore très peu utilisé au niveau pro. Quand aux makefile simples, ils dépendent complètement du système utilisé. La chaine de compilation a donc une importance certaine dans le développement (comme dit plus haut par jblecanard), et ça ne simplifie pas le développement d'applications portables. Car les chaines de compilation complètes multiplateformes sont rares - et les utiliser n'est pas nécessairement souhaitable (par exemple, on va vouloir utiliser gcc sous linux et OS X, Visual C++ ou Intel C++ sous Windows - dans le but de profiter de ce qui se fait de mieux en génération de code sur les différentes plateformes supportées).

Je vais m'arrêter là sur ce sujet :)

Citation:

---

Bien que le C et le C++ standard soient portables, ces langages sont très rarement employés pour créer des programmes qui seront exécutés sur différents environnements. Si c'est nécessaire, on se heurte a un écueil majeur : la portabilité du système GUI utilisé. Aujourd'hui, on a plusieurs solutions tout à fait acceptables : Qt, wxWidgets, ... Ce n'était pas le cas il y a seulement 4 ans (Qt sous Windows n'était pas sous licence libre pour développer des outils de manière commerciale ; et la licence par siège coutait un bras).

---

C'est vrai, mais il faut aussi noter que la "récente" popularisation de tas de matériel embarqués (notamment les smartphones) rends du code portable plus interessant qu'auparavant pour les entreprises qui fournissent des logiciels qui doivent s'executer sur une panoplie de mantériels de différents constructeurs et environnements (OS entre autre).

Cela dit, c'est vrai qu'on demande rarement du code réellement portable. Personnellement j'en ai plus fait pour développer du jeu portable (que je n'ai meme pas encore eu le temps de tester autre part que sur linux) que dans tous mes jobs.

Oui, je conçois parfaitement que le multiplateforme n'est pas nécessairement quelque chose d'intrinsèque à un code pro. Notez aussi que je n'ai pas encore commencé à travailler en entreprise, je développe depuis quelques années sous GNU/Linux. En fait j'ai du mal m'exprimer dans mon premier post.

En fait, j'écris un moteur 3D depuis quelques temps. Il compile sous Linux, mais je n'ai jamais essayé sous un autre OS. Le jour où je présenterai le moteur à une communauté libre quelconque pour qu'elle le découvre, des gens utilisant OSX ou Windows ou une autre plateforme ne pourront tout simplement pas l'essayer, et ça me dérange. Donc la question majeure de ce post est : « Existe-t-il une manière correct et plus ou moins standard de faire du multiplateforme en C/C++ ? (cf. mon post un peu plus haut sur le #define unix) ».

Finalement, il y a aussi quelque chose sur quoi je voudrais rebondir dans ton post Emmanuel Deloget :

Citation:

---

Envoyé par Emmanuel Deloget

Il y a une différence notable entre du code professionnel et du code normal

---

Qu'est-ce que pour toi du "code normal" ?

Citation:

---

Envoyé par skypers

Finalement, il y a aussi quelque chose sur quoi je voudrais rebondir dans ton post Emmanuel Deloget :

Qu'est-ce que pour toi du "code normal" ?

---

C'est une expression très mal choisie de ma part, qui est censé regrouper tout ce qui n'est pas du code pro tout en restant du bon code.

Citation:

---

Envoyé par skypers

Tout d'abord, merci de vos réponses. Ton expérience avec Boost.regex est intéressante, bien qu'elle me dérange un peu. Le code ne devrait-il pas être correctement documenté afin que nous puissions coder sur un maximum de machine ?

---

Ce n'était pas censé arriver ! Il s'agissait d'une surcharge d'opérateur qui se révélait ambigue dans cl (le compilateur de visual c++) et pas dans gcc. J'ai utilisé une autre expression qui me donnait le même résultat et ça a marché. Mais c'est le genre de trucs qui font qu'on ne peut pas d'emblée écrire un code qui va marcher partout : il faut tester.

Citation:

---

Envoyé par Emmanuel Deloget

Car les chaines de compilation complètes multiplateformes sont rares - et les utiliser n'est pas nécessairement souhaitable (par exemple, on va vouloir utiliser gcc sous linux et OS X, Visual C++ ou Intel C++ sous Windows - dans le but de profiter de ce qui se fait de mieux en génération de code sur les différentes plateformes supportées). )

---

J'utilise CMake, je compile sous Linux avec GCC et sous Windows avec Visual Studio, donc je profite des meilleures optimisations des deux côtés. Mais je récupère des petites broutilles comme celle citée précédemment, qui se règlent facilement du moment qu'on dispose de toute les plateformes qu'on cible. Une bonne chaîne de compilation sait se décoreller de son compilateur, en théorie.

dans ma boite (pro, donc) on a eu un problème un peu inattendu (enfin moi je m'y attendais mais pas les gugusses qui ont codé ca il y a 10 ans ^^); on a du code spécifique a des plate formes (jusque la c'est normal) et on arrive a compiler avec plusieurs compilateurs, avec des directives préprocesseur.
En gros on a:

Code:

---

1 2 3 4 5 6

void doPlatformSpecifiStuff() { #ifdef _WIN32 #elif defined _LINUX #endif }

---

Les gogos qui ont codé ca ne s'attendaient pas a ce qu'on rajoute une troisieme plate-forme un jour (mettons, macOS X) et cette fonction compile mais est vide et ne fait rien.

Ce code la se promène un peu partout, des fois il y a un #else #error "plate forme non supportée" pour être sympa, des fois non. Même quand il y est, je trouve ca pas très propre; le code est dispersé et il est difficile de savoir quand on a fini de tout "porter"

Désormais pour empêcher ca, j'ai décidé (sur mon projet perso, pas dans cette boite malheureusement) de placer le code spécifique a des plate-formes ou a des architectures toujours dans des fichiers séparés

par exemple, pour "filesystem.cpp", il y a la partie "commune" et la partie "filesystem-win32.cpp" qui n'est compilée que sur win32
mieux, les fichiers sources peuvent se trouver dans un répertoire séparé. Ajouter une nouvelle plate-forme, en gros, c'est créer un repertoire et ajouter les implémentations qui manquent. Si il manque des définitions, le code ne compile pas (enfin, l'édition des liens echoue)

Si tu penses avoir beaucoup de plate-formes ca peut etre interessant d'investir dans ce genre de solutions. Si tu 'as pas beaucoup de sources bien sûr ca ne servira pas a grand chose.

Il me semble qu'effectivement c'est la solution la plus pronée par divers projets open-source, notemment OGRE. C'est certainement le meilleur moyen de réellement isoler "physiquement" le code spécifique aux différentes plateformes.

Citation:

---

Envoyé par Klaim

Il me semble qu'effectivement c'est la solution la plus pronée par divers projets open-source, notemment OGRE. C'est certainement le meilleur moyen de réellement isoler "physiquement" le code spécifique aux différentes plateformes.

---

Selon moi, il est nettement préférable d'avoir d'une part des define en fonction du support de certaines feature (à la configure : HAVE_DIRENT_H, HAVE_STRUCT_TM, ...) ; cela oblige le programmeur a écrire du code pour supporter les cas où la feature n'est pas présente de manière native.

Une autre solution est de mettre en place des librairies spécifiques par plateforme - qui implémente les mêmes fonctions quelle que soit la plateforme - pour chaque fonction posant un problème de portabilité (ce n'est hélas pas toujours possible : cf accept sous Linux, qui ne se comporte pas tout à fait pareil que le accept de BSD ; on ne peut pas l'encapsuler parce que c'est le traitement des erreurs qui est différents (sur l'un des plateforme, si une erreur est détectée sur la socket avant de sortir de accept, alors accept renvoie une erreur ; sur l'autre plateforme, l'erreur est remontée lorsqu'on travaille avec la socket. Franchement, je ne vois pas comment encapsuler ça... Et oui, les problèmes de portabilité, ça va jusque là)). Cette librairie est linkée statiquement en passant le bon -L au linker (le choix des headers dans le programme client se faisant en passant le bon paramètre -I au compilateur).

C'est plus lourd, mais ça évite de se retrouver avec plein de #if/#else dans le code client tout en regroupant le code mono-plateforme dans un seul endroit. On va au delà des fichiers -win32, -linux, ... bien que dans le concept, ça soit relativement similaire.

C'est ce que je fais pour ma librairie actuelle.

Compiler les fichiers selon la plateforme ? C'est un peu bizarre je trouve, ce n'est pas un peu plus lourd que d'utiliser le préprocesseur ?

Aussi, y'a-t-il une différence notable entre par exemple linux et __linux ? Vu que ce sont les compilateurs qui définissent ça d'eux-mêmes, il doit bien y avoir une raison, ou alors c'est juste pour laisser plus de "marge" dans le choix des #define ?

ta deuxieme remarque explique un peu la premiere :)
les compilateurs ne sont pas vraiment d'accord sur les macros, il n'y a pas qu'un standard. Et si on étend aux architectures (je compile du code pour x86, amd64, powerpc, powerpc 64, plusieurs ARM, et mips et SPU un jour...) la ca devient l'enfer:
x86 ou i386? x86_64 ou amd64??
d'ou ma préférence pour les fichiers séparés. C'est plus lourd au niveau du systeme de build, mais c'est beaucoup plus agréable.
A noter quand meme que la plupart du code n'a pas besoin de ce systeme, c'est utilisé uniquement dans les couches "basses" de l'application. Le reste compile plus facilement.

Autre bonne ressource predef.sourceforge.net

Salut,
J'aime beaucoup cette problématique multiplateforme. Je l'ai vu souvent comme un impératif dans beaucoup de projets pro aussi bien embarqués que débarqués. La contrainte multiplateforme se déclinant en isolation/limitation de l'adhérence à l'O.S., au compilateur, à l'HW.
Au final, assez peu de ces projets ont vraiment été déployés sur des plateformes différentes. Voir même pour certains, les architectures (logicielles) étaient si fragiles que changer même une option de compilation donnait des sueurs froides à certains :mouarf:.

Maintenant, je tend à préconiser une approche semblable à celle présentée par screetch : isolation du code spécifique dans des fichiers dédiés et différents selon la plateforme (hw/os/compil). Et non le mitage du code par des #ifdef ou autre.

Citation:

---

Envoyé par screetch

ta deuxieme remarque explique un peu la premiere :)
les compilateurs ne sont pas vraiment d'accord sur les macros, il n'y a pas qu'un standard. Et si on étend aux architectures (je compile du code pour x86, amd64, powerpc, powerpc 64, plusieurs ARM, et mips et SPU un jour...) la ca devient l'enfer:
x86 ou i386? x86_64 ou amd64??
d'ou ma préférence pour les fichiers séparés. C'est plus lourd au niveau du systeme de build, mais c'est beaucoup plus agréable.
A noter quand meme que la plupart du code n'a pas besoin de ce systeme, c'est utilisé uniquement dans les couches "basses" de l'application. Le reste compile plus facilement.

---

Hum, il faudra que j'essaie ça en effet, l'idée me plait assez finalement. Le point important est : comment adapter par exemple un CMakeLists.txt à une telle configuration de build ? (j'utilise cmake).

Citation:

---

Envoyé par Joel F

Autre bonne ressource predef.sourceforge.net

---

Merci ! C'est exactement ce dont j'avais besoin !

je n'utilise pas CMake, j'utilise Waf et j'ai codé en python le parcours des sources pour les ajouter ou pas. Je n'aime pas respécifier les sources dans un fichier texte séparé; si il y a un fichier source, il faut le compiler.
Je suis sur que ca existe sous CMake cependant; j'ai trouvé cet exemple de code:

Code:

---

1 2 3 4 5 6 7 8

... # If we build for windows systems, we also include the resource file # containing the manifest, icon and other resources if(WIN32) set(SRCS ${SRCS} minimal.rc) endif(WIN32) ...

---

donc ca doit marcher :) reste a savoir ce que CMake utilise pour les autres plate-formes.

Citation:

---

Envoyé par skypers

Compiler les fichiers selon la plateforme ? C'est un peu bizarre je trouve, ce n'est pas un peu plus lourd que d'utiliser le préprocesseur ?

---

Pas tant que ça. J'utilise configure sur les OS plus ou moins POSIX (y compris cygwin), et il me suffit d'ajouter une règle qui modifie le path des includes en fonction de uname. Sur Windows, les projets VS piochent directement là où ils doivent piocher.

Du coup, au niveau du build, ça ne se voit pas.

Avec cmake, il doit être possible de faire aussi bien, voire encore mieux (il faut vraiment que je m'y mette d'ailleurs).

Citation:

---

Envoyé par Emmanuel Deloget

Avec cmake, il doit être possible de faire aussi bien, voire encore mieux (il faut vraiment que je m'y mette d'ailleurs).

---

c'est ce que je fait dans les cmake de mes projets: tu detecte tout un patatras d'infos sur la plateforme+le compilo et ca genere les sources_list qui vont bien.

Bon, il va falloir que je me penche un peu plus sur cmake alors. Merci à tous de vos réponses :)

EDIT: J'ai trouvé ça : http://www.cmake.org/cmake/help/cmake_tutorial.html#s4

Je suppose que c'est ce dont vous parliez, non ?

Salut,
Introduction au système de construction logicielle CMake par Florian Goujeon

Déjà lu, mais merci.