[FAQ] Comment éviter les pièges qui font un programme non portable ?

Bonjour,

J'ai un peu du mal à trouver la bonne question. En même temps, Melem m'a dit que le sujet est très vaste. Je l'admet, mais tant que je n'aurais pas écrit l'article en question (ou quelqu'un d'autre :whistle:) je propose un récapitulatif des quelques points qui me viennent en tête.

Question : Comment éviter qu'une application soit non portable ?
Réponse :
En fait, il est simple de faire en sorte qu'une application soit portable. Pour cela, il suffit de respecter quelques règles simples :

• Éviter d'inclure les fichiers conio.h ou ceux liés à la WinAPI (tel que windows.h) ;
• Éviter les include contenant le séparateur de chemin de fichier '\' (qui est autocomplété par VS2010) ;
• Privilégiez les bibliothèques multiplateformes ;
• Affichez les avertissements maximums des compilateurs (permet de se rapprocher de la norme du langage et donc d'être compatible avec plus de compilateurs)
• Écrivez du code respectant la norme du langage et non du code qui compile par chance ;
• Évitez les #pragma (même s'ils sont maintenant reconnus / ignorés par la plupart des compilateurs).

---


Donc, voilà un premier essai. Je ne suis peut être pas le meilleur pour ce genre de choses.
Petit rappel du pourquoi je trouve cette Q/R importante ->
J'ai déjà vu du code sur le forum, ayant des #include <windows.h> alors que cette entête n'était pas nécessaire. Un peu pareil avec conio.h et sa superbe fonction getchar() :tronçonneuse:. Étant sous GNU/Linux (non, ce n'est pas pour troller), la conversion de leur code me prends du temps (pour voir que cela bogue à toute les lignes :roll:). Alors qu'il suffit de respecter quelques règles simples pour avoir un programme portable.
(Bon, ils me font aussi rager les gens qui disent que produire un programme portable est compliqué. Cela l'est que lorsque l'on commence par programmer sous Windows :aie: (bizarrement). La transition Linux -> Windows est largement plus simple à faire).
Donc, après mon coup de rage :zen:; le but final de cette FAQ (et peut être d'un article ?) est de faire en sorte que plus de programmeur fasse que leurs programmes compilent facilement sur tout les systèmes, donc, faisant que les programmes tournant sous GNU/Linux ou MAC OS X soit plus importants.

Même dans l'autre sens il y a des pièges, surtout avec POSIX, en gros MT et réseau (et les infos système ...). Mais aussi sur les démangling, l'affichage des exceptions qui se sont échappées, etc.
(et ne pas oublier les 150 tests sur le support des (s)(n)printf, itoa & cie réalisés par les autotools.

Privilégier les COTS portables au détriment des API limitées est en effet la première règle. Vu qu'il ont déjà fait abstraction des aspects propriétaires.

Mais il y aurait quantité d'autres choses à détailler pour quand il y a besoin de faire ce boulot nous même. -> les points de variabilités à coup de #ifdef et ceux gérés au niveau des makefiles (qui vont choisir un fichier plutôt qu'un autre)

Salut,
Le premier point a peut être l'air trivial mais mérite probablement d'être souligné : faire du code sans comportement indéfini ni comportement dépendant de l'implémentation du compilateur.
Dans la même veine, éviter les extensions des compilateurs.

#pragma est supposé être (silencieusement?) ignoré par les compilateurs qui ne supportent pas l'option, non ?

Les COTS contraindront de toute façon la portabilité. Qt, wxWidget, POSIX ou Windows seront toujours de la science fiction quand on développe pour un v850 par exemple. Il faut donc éviter leur 'contagion' à des portions de code où ils ne sont pas utiles (c'est cette contagion que je reproche souvent aux framework type Qt ou MFC).

Après tout dépend jusqu'où on pousse la portabilité. On peut aussi recommander de ne pas utiliser les types de bases ([signed|unsigned] char, [signed|unsigned] short, [signed|unsigned] int, [signed|unsigned] long, float, double) vu que le standard ne garantie pas de vrai représentation. Préférer alors les [u]intN_t. Mais ceux-ci ne sont disponibles qu'à partir de C++11 alors que déjà présent dans C99 (mais absent de C visual :aie:)

Je pense qu'il y a encore d'autres recommandation et comme le dit Melem, c'est probablement assez vaste comme sujet. Les règles de codage ou les règles type MISRA visent justement à produite du code normalement plus portable.

Puis, il y a les sujets tabous : doit-on vraiment faire de la programmation générique très poussée qui bien que conforme d'un point de vue standard peut donner du code non compilable par des compilateurs plus anciens ou moins conformes au standard. Ca peut être une vrai question et un vrai problème en industrie.

Je vois bien que je soulève un problème assez compliqué là.

:oops: Pouvez vous me dire ce qu'est que les "COTS" ?

Pour le #pragma oui, cela sera ignoré, mais du coup, le code ne sera pas interprété de la même façon, avec risque de programme ne se comportant plus pareil.


Pourtant cela me dégoute toujours un peu, de voir qu'un programme pourrait fonctionner chez moi, pour quelques petits détails ...

Citation:

---

Envoyé par LittleWhite

:oops: Pouvez vous me dire ce qu'est que les "COTS" ?

---

Le contraire du NIH :aie:


COTS = commercial off-the-shelf = 'produit sur étagère', en gros bibliothèque tierce.

Citation:

---

Envoyé par 3DArchi

On peut aussi recommander de ne pas utiliser les types de bases ([signed|unsigned] char, [signed|unsigned] short, [signed|unsigned] int, [signed|unsigned] long, float, double) vu que le standard ne garantie pas de vrai représentation. Préférer alors les [u]intN_t. Mais ceux-ci ne sont disponibles qu'à partir de C++11 alors que déjà présent dans C99 (mais absent de C visual :aie:)

---

Non plus. Le C++11 standardise juste (u)fast_int{taille}_t (ou int_fast?) et pareil avec least.

Et il y a deux aspects à considérer : la garantie de taille (min et max) pour les point d'interface (fichier binaire, socket). Et la garantie de taille (min) pour les calculs. Et parfois aussi le besoin de rapidité (le contrat de int, IIRC).