Code source commun Unix/Windows

Dans mon projet, certaines fonctions ne sont pas compatibles entre les systemes et j'aimerai donc savoir comment mettre ces fonctions dans les memes fichiers et ainsi savoir comment faire pour que les bonnes fonctions compilent sous le bon systeme sans generer d'erreur.

Vous avez une idée ?

En utilisant des bibliothèques qui font déjà abstraction de ces détails ?
En utilisant des outils qui vont aider à reconnaitre les bons fichiers à compiler ? (autotools, bjam, aap, ...)

Tu veux faire quoi ? (ta fonction fait quoi)

tu peux entrer les directives

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#define UNIX //#define WINDOWS   #ifdef UNIX //mes fonction unix compatible ... #endif   #ifdef WINDOWS //mes fonction ... #endif

---

ainsi tu nas qu'une seulle ligne a metre en commentaire ou a decommenter pour complier sur les different systeme

il y a possiblement un moyen de savoire sur quelle systeme tu tente de complier mais je ne le connait pas

desole

ce sont ces defines precisement qu'il faut utiliser pour que ca marche ?

Pas forcément besoin de #define. Cela dépend de comment tu arrives à isoler les traitements spécifiques.
D'où le "que veux tu faire exactement" ?

il me semble qu'un pattern "Façade" serait approprié.
Tu peux ainsi encapsuler les dépendances, et les rendre transparentes pour le reste du logiciel.
Ce n'est que ta façade qui gère les dépendances, à chacun ses responsabilités.

Je pense separer mon code exactement le preconise philippe V, avec des define.

Mais ce que je veux savoir c'est comment s'appelle le define qui correspond a Windows et egalement le nom qui correspond a celui d'UNIX (NetBSD plus precisement)...

Pour Windows c'est WIN32, pour UNIX je dirais POSIX vu que ça doit être ce que tu utilises.
Mais en général c'est

Code:

---

1 2 3 4 5 6

#ifdef WIN32 // Windows   #else // le reste, UNIX en particulier   #endif

---

Ce n'est pas aussi simple que windows vs *nix avec deux malheureux symboles qui se battraient en duel. Pour voir le genre de symbôles que l'on pourrait tester et comment cela marche en version brute, regarde n'importe quel projet aux sources publiques qui utiliserait les autotools (p.ex. vim, mutt, wxWidgets, ...) ou des projets tout template comme boost.

Pour ce genre de trucs, ce sont plutôt des bridges et non pas des façades (qui "fusionnent" des interfaces) que l'on utilise vu que l'on a des trucs aux interfaces différentes qui servent à remplir un même rôle. Le choix des unités de traductions à compiler se faisant au niveau du "gestionaire de compilation" (-> make, scons, bjam, aap, ...) qui aura une vision des trucs propres à la plateforme (-> 0 utilisation du preprocesseur).

(tu n'as toujours pas répondu à ma question)

C'est aussi un cas typique de la factory, et dans le .cpp de ta factory, il faut bien que tu fasses ce genre de choses pour savoir quelle classe inclure / instancier.
Utiliser des libs qui font l'abstraction ça part d'une bonne intention, mais si l'utilisation de fonctions non portables que tu fais est minime (genre lister le contenu d'un répertoire etc...), je comprend tout à fait qu'on veuille isoler de cette manière le code incriminé plutto que de demander à l'utilisateur d'installer telle(s) ou telle(s) lib(s) en plus souvent bien plus grosse que son projet.

Effectivement, le "pont" est mieux adapté.
Maintenant, il faut voir le but recherché s'il ne s'agit que de gérer Windows/unix-like, les deux symboles qui se battent en duel peuvent suffire.
Précise ce que tu veux faire et (Luc||Aurélien||Loulou) te répondra.
:D

Citation:

---

Envoyé par tut

Maintenant, il faut voir le but recherché s'il ne s'agit que de gérer Windows/unix-like, les deux symboles qui se battent en duel peuvent suffire.

---

Même pas. Les unix font exploser ce nombre.
As-tu déjà vu la quantité de tests réalisés par des ./configure ?

@Aurélien : Pas nécessairement besoin de tests dans le .cpp. P.ex.

Code:

---

1 2 3 4 5 6 7 8

// toto.hpp void f();   // toto-nix.cpp void f() { code spécifique aux *nix }   // toto-win32.cpp void f() { code spécifique à win32 }

---

Au niveau du make/app/... on ne compilera qu'un seul des deux toto-xxx.cpp -> celui adapté à la platerforme.
Avec des classes, c'est pareil.
Je trouve ça bien plus maintenable qu'une seule fonction au corps n fois plus gros et farci de #ifdef.

alors Windows / Posix peut-être ?
un truc qui me dérange avec les configure/make et compagnie, c'est que tu rends le code dépendant de la chaîne de compilation.
Si sous windows, tu utilises C++ Builder ou Visual ou DevCpp, qu'est-ce qui se passe ?

Citation:

---

Envoyé par Luc Hermitte

@Aurélien : Pas nécessairement besoin de tests dans le .cpp. P.ex.

Code:

---

1 2 3 4 5 6 7 8

// toto.hpp void f();   // toto-nix.cpp void f() { code spécifique aux *nix }   // toto-win32.cpp void f() { code spécifique à win32 }

---

Au niveau du make/app/... on ne compilera qu'un seul des deux toto-xxx.cpp -> celui adapté à la platerforme.
Avec des classes, c'est pareil.
Je trouve ça bien plus maintenable qu'une seule fonction au corps n fois plus gros et farci de #ifdef.

---

Hehe, je savais bien que t'avais une astuce derrière la tête. Je connaissais pas, effectivement c'est élégant. Mais j'en reviens à ma factory, typiquement on a:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#include "Factory.h"   // MyWindowBase est la classe abstraite de base // MyWindowWin32 est son implémentation sous Windows // MyWindowX11 est son implémentation sous systèmes X11   #ifdef WIN32 #include "MyWindowWin32.h" #else #include "MyWindowX11.h" #endif   MyWindowBase * NewWindow() { #ifdef WIN32 return new MyWindowWin32; #else return new MyWindowX11; #endif }

---

Donc l'astuce du makefile pour compiler uniquement MyWindowWin32.cpp ou MyWindowX11.cpp ok, mais dans factory.cpp, je vois pas comment se passer d'une inclusion conditionnelle.

Citation:

---

Envoyé par tut

alors Windows / Posix peut-être ?
un truc qui me dérange avec les configure/make et compagnie, c'est que tu rends le code dépendant de la chaîne de compilation.
Si sous windows, tu utilises C++ Builder ou Visual ou DevCpp, qu'est-ce qui se passe ?

---

Ben c'est pareil avec n'importe lequel de ces outils : ton projet est dépendant de l'IDE utilisé. Si tu utilises VC++, tu ne peux compiler qu'avec ce dernier...

Une solution c'est d'utilise un truc genre cmake, qui te génère au choix un makefile UNIX, MS (nmake), un projet VC++, BCB, etc...
Y'en a un autre écrit en python aussi je crois

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Si tu utilises VC++, tu ne peux compiler qu'avec ce dernier...

---

pourquoi donc ?
je crois que l'on ne se comprend pas trop.

Je suis partisant de la solution bridge + #define, comme ça on ne se rend pas dépendant d'option de make ou autre, et on peut utiliser ce que l'on veut comme IDE.
De toute façon, on pourrait continuer ce genre de débat interressant pendant des heures, mais tant que l'on ne sait pas éxactement ce que l'on veut faire, ça ne sert à rien de commencer à le faire. Problème récurrent du Génie Logiciel :roll:

En ce moment, je m'amuse avec A-A-P, il y a aussi scons (en python aussi), bjam et quelques d'autres qui une fois installés sont capables de s'adapter à l'outil que tu utilises pour compiler ton C++. Et ils gèrent pour toi toutes les dépendances et c'est beau. Certains comme A-A-P savent aussi échanger avec le serveur CVS, publier des sites WWW, ...

Pour le factory .cpp, c'est au choix. Soit effectivement tu fais un #ifxxx, soit tu scindes le factory.cpp en plusieurs unités de traductions "exclusives". Mais dans un exemple pareil, on a typiquement des ponts plus gros qu'une seule petite fonction comme celle là. -> On a plusieurs fonctions dans le genre qui vont justifier de scinder l'unité de traduction.

Le truc est de trouver le bon compromis entre le nombre de paramètres qui peuvent varier et les TU que l'on pourrait extraire, pour la partie bas niveau.
D'où ma question de "quelle est la fonction à spécialiser ?".

Après, au fil des développements, on commence à avoir une ou plusieurs bibliothèques qui font déjà tout ça de manière transparente. Ce qui nous permet de nous proccuper de moins en moins de ces détails, et de nous concentrer sur le coeur de l'appli.

A voilà, scons.
J'ai pas testé ce que tu as donné, mais ce que j'apprécie avec cmake c'est sa bonne intégration sous Windows. On a une interface graphique pour configurer le build, et il est bien intégré avec VC++ (utilise pas mal de ses possibilités). Par exemple là je lutte avec qmake (un autre truc du genre mais de chez Qt) qui me génère des projets VC++ que je dois reprendre à la main :x
cmake sait aussi tester l'installation de certaines libs en allant chercher leur path dans la base de registres et configurant automatiquement l'include path, etc...
http://www.codeproject.com/tools/cmake.asp