Discussion :

[phi1981]

Bonjour !

Voilà je maintiens un programme assez important en C++ dont 99.9% du code est très portable (je veux dire par là qu'il ne dépend que de la librairie Standard C++, ce qui inclut la STL).
Le 0.1% non-portable concerne une toute petite classe qui permet d'écrire des données vers une sorte de périphérique.
Cette classe était définie jusqu'à présent sous Linux un peu de cette façon :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
// OutputDevice.h
 
class OutputDevice
{
public:
// .... Diverses méthodes, constructeurs & destructeur
//
      void Write (const std::string& out);
private:
   int m_fd; // Descripteur de fichier
};

Je dois réimplementer cette classe sous Windows, et ce qu'elle doit faire est tellement simple que l'api native Win32 suffit parfaitement à mes besoins.
Mon problème, c'est que pour obtenir une classe similaire je dois faire ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#include <windows.h>

class OutputDevice
{
public:
// .... Diverses méthodes, constructeurs & destructeur
//
      void Write (const std::string& out);
private:
   HANDLE m_fd; // Descripteur de fichier, version Windows
};

HANDLE est un type définit par Windows.h (ou un header inclut par ce dernier), et inclure Windows.h pollue le namespace global d'un tas de trucs qui rendent le reste du code (censé être portable) pas forcément évident à maintenir. Parmis ces nuisances figurent énormément de macros comme min()/max() et un tas de noms de fonctions comme CreateFile() qui est implémenté comme une macro pour CreateFileA() et CreateFileW().

Je pourrais tout à fait utiliser un pImpl (pointeur sur implémentation) et donc avoir une autre classe qui se charge d'allouer un objet opaque contenant un HANDLE:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class OutputDevice
{
     class Impl;

public:
// .... Diverses méthodes, constructeurs & destructeur
//
      void Write (const std::string& out);
private:
   std::unique_ptr<Impl>    m_Impl; // Pointe vers une classe opaque qui manipule mon HANDLE
};

Mais mince quoi !! ça voudrait dire qu'à chaque fois que j'instancie cette classe OutputDevice, je force une allocation mémoire pour stocker une variable HANDLE de 4 octets ???? Pfff .... C'est pas vraiment un problème pour les performances mais je trouve ça lourd.

Puis j'ai réfléchi : un rapide coup d'oeil à la définition de HANDLE m'apprend qu'il s'agit d'un typedef vers void*. Pourquoi est-ce que je ne définirais pas alors ma classe comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class OutputDevice
{
typedef void* SystemHandle;

public:
// .... Diverses méthodes, constructeurs & destructeur
//
      void Write (const std::string& out);
private:
   SystemHandle    m_Handle; // Type spécifique au système 
};

Je ne pense pas casser quoi que ce soit de cette façon. Je n'empêche pas mon compilateur de faire de la vérification de type: lorsque, dans mon code non-portable, j'appelle une fonction comme WriteFile(), je peux lui passer un SystemHandle, puisqu'il s'agit du même type que celui auquel il s'attend. Et si ça venait à changer demain (si Microsoft définit HANDLE comme étant un int par exemple), j'aurais une erreur de compilation, mais facile à fixer.
Je suis juste surpris de pas avoir vu ça plus souvent dans le source que je lis un peu partout, alors j'aimerais bien des avis extérieurs.

Merci !!!

[koala01]

Salut,

Le pimple idiom est, à mon sens, plus adapté, car il permet de centraliser tout ce qui est réellement spécifique à une implémentation donnée.

Le problème, c'est que, si tu veux utiliser HANDLE (sous la forme d'un typedef perso ou sous sa forme "réelle"), tu vas devoir jalonner ton code de directives de compilation conditionnelles, car tu auras un void* pour l'implémentation sous windows et un int pour l'implémentation sur d'autres architectures.

Alors que, si tu utilises le pimple idiom, tout ce qui est spécifique à windows (et donc à l'utilisation de HANDLE) sera regroupé dans une classe spécifique, et il en ira de même pour tout ce qui est spécifique à une autre architecture, le tout, de manière totalement transparente pour l'utilisateur . La facilité de développement est sans doute au bout de cette méthode qui peut paraître un peu "overkill" vu que ce n'est que pour changer un int en void *

[phi1981]

Le problème, c'est que, si tu veux utiliser HANDLE (sous la forme d'un typedef perso ou sous sa forme "réelle"), tu vas devoir jalonner ton code de directives de compilation conditionnelles, car tu auras un void* pour l'implémentation sous windows et un int pour l'implémentation sur d'autres architectures.

J'arrive à implémenter ma pseudo-solution sans un seul #ifdef (j'ai jamais beaucoup aimé ces bêtes là, pourtant je suis un programmeur C à la base).
Pour ça, mon source est divisé avec un répertoire principal qui contient le source portable, et deux sous-répertoires : win32 et posix.
Chaque sous-répertoire contient sa version de "OutputDevice.h". Dans le source portable j'include <OutputDevice.h>, et c'est mon environnement de build (Visual Studio sous Windows, Scons sous Linux) qui définit le répertoire où aller chercher les includes.

Alors que, si tu utilises le pimple idiom, tout ce qui est spécifique à windows (et donc à l'utilisation de HANDLE) sera regroupé dans une classe spécifique, et il en ira de même pour tout ce qui est spécifique à une autre architecture, le tout, de manière totalement transparente pour l'utilisateur . La facilité de développement est sans doute au bout de cette méthode qui peut paraître un peu "overkill" vu que ce n'est que pour changer un int en void *

Si je dois en arriver là, alors pourquoi ne pas carrément utiliser l'héritage ?
avoir une classe de base abstraite OutputDevice, laisser chaque plateforme implémenter un OutputDeviceWin32 et un OutputDevicePosix, et avoir pour chaque plateforme une fonction factory qui me génère celui qui est approprié.
Après tout, cela n'a rien d'illogique : un OutputDeviceWin32 est un (is a) OutputDevice, donc un héritage public peut se justifier.
Ce que j'aime, c'est que si ma fonction factory est du genre :

Code :

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

1
2
 
std::unique_ptr<OutputDevice>   CreateOutputDevice();

Alors je laisse l'appelant gérer la durée de vie. Il peut même convertir le unique_ptr en shared_ptr si besoin.
Je crois même être tombé sur un article d'Herb Sutter qui proposait ça comme alternative à un pImpl...

[dragonjoker59]

un HANDLE est un typedef sur void *
T'est-il possible de passer ton membre m_fd en ptrdiff_t (ou size_t) sous Linux ?
Car si ça t'est possible, tu le fais, et tu n'inclues Windows.h que dans ton fichier .cpp, avec juste un cast sur la définition du handle et un sur son utilisation. (j'aime bien les solutions bêtes et connes)

[phi1981]

Oui je peux le faire, je peux même faire encore plus simple et définir un type abstrait, un peu comme SystemHandle dans mon exemple, qui varie suivant la plateforme, et ainsi éviter un cast.
Mais est-ce sain et raisonnable de reposer sur la connaissance du fait que HANDLE est juste un synonyme de void* ? Il me semble que je brise une abstraction établie par Microsoft.

[white_tentacle]

Si j’ai bien compris :

- à la compilation, en fonction de la plateforme, tu vas utiliser OutputDevice qui est dans le répertoire linux, ou OutputDevice qui est dans le répertoire windows
- chaque OutputDevice est spécifique à la plateforme
- le client doit pouvoir utiliser indifféremment un OutputDevice ou l’autre sans faire la différence.

Conclusion : OutputDevice est une structure opaque, du coup pimpl me semble tout à fait adapté.

Maintenant, si ce qui te gêne, c’est l’allocation dynamique que ça implique, tu peux faire de la micro-optimisation.

La seule chose que les clients ont besoin de connaître, c’est la taille de ta structure (et encore, tu peux t’arranger pour que ce ne soit pas le cas). Donc, dans ta classe, tu peux mettre un :

Code :

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

1
2
3
4
class OutputDevice {
char reserved[sizeof(void*)]; // ou sizeof(long long), ou 8, ou 12
…
};

Ensuite, dans ton cpp :

Code :

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

1
2
3
4
5
 
HANDLE& getHandle(OutputDevice& d) {
    static_assert(sizeof(HANDLE) <= sizeof(OutputDevice::reserved), "Size mismatch :*HANDLE too big");
    return reinterpret_cast<HANDLE&>(d.reserved);
}

Le static_assert te permet de t’assurer que dans tous les cas, tu as réservé assez d’espace pour stocker ton HANDLE. Côté client, c’est totalement opaque : il sait juste qu’il y a X octets réservés pour la structure, qui sont privés.

[JolyLoic]

Si je dois en arriver là, alors pourquoi ne pas carrément utiliser l'héritage ?

Parce que l'héritage est aussi peu performant, et impose à l'utilisateur de ton type de manipuler des pointeurs, alors qu'avec le pimpl, il peut sans soucis manier des objets.

[jblecanard]

Le problème, c'est que, si tu veux utiliser HANDLE (sous la forme d'un typedef perso ou sous sa forme "réelle"), tu vas devoir jalonner ton code de directives de compilation conditionnelles, car tu auras un void* pour l'implémentation sous windows et un int pour l'implémentation sur d'autres architectures.

Ce qu'on peut aussi faire, c'est configurer la chaîne de compilation pour choisir le bon *.cpp en fonction de la plateforme sur laquelle on compile. Ce qui donne un *.cpp Linux et un *.cpp Windows, comme ça pas de macro dégueux pour faire de la compile conditionnelle. Par contre, il faudra quand même se taper tous les cast dans le *.cpp, et bien surveiller que la taille du membre "générique" correspond bien une fois casté.

Et en effet, tu briserais une abstraction, et l'idéal reste un bon pimp bien propret.