Discussion :

[Klaim]

Et encore, cela n'est pas totalement vrai, dans le cas d'un jeu avec de joueur sur un seul peripherique ... Il y aura bien deux objets sur un materiel. Et de plus, avec votre instance unique, il est difficile de differencier par la suite quel joueur aura fait l'action.

On s'est mal compris : je voulais dire qu'il y a une instance par matériel (par exemple un clavier,une souris) et que potentiellement il peut y en avoir plus, donc les classes correspondantes (et l'interface commune) ne peuvent pas être singleton.

En revanche, dans ce genre de système, il faut bien un objet qui :
1. détienne les différents objets représentants les matériels d'entrée;
2. les mettes à jour (sur demande) : traite les messages du matériel pour obtenir un "état" résultant des différents matériels.
3. fournisse l'accès à ces objets détenus.

Quel que soit cet objet, il doit être unique, soit parcequ'il n'est instancié qu'une fois dans un singleton, soit parcequ'il est lui même singleton. On peut faire sans, mais on reviens aux problèmes de communication et d'érreurs faciles (instancier plusieurs fois cet objet et se retrouver avec différents codes piochant dans des états pas toujours synchro...)

[LittleWhite]

On s'est mal compris : je voulais dire qu'il y a une instance par matériel (par exemple un clavier,une souris) et que potentiellement il peut y en avoir plus, donc les classes correspondantes (et l'interface commune) ne peuvent pas être singleton.

En revanche, dans ce genre de système, il faut bien un objet qui :
1. détienne les différents objets représentants les matériels d'entrée;
2. les mettes à jour (sur demande) : traite les messages du matériel pour obtenir un "état" résultant des différents matériels.
3. fournisse l'accès à ces objets détenus.

Quel que soit cet objet, il doit être unique, soit parcequ'il n'est instancié qu'une fois dans un singleton, soit parcequ'il est lui même singleton. On peut faire sans, mais on reviens aux problèmes de communication et d'érreurs faciles (instancier plusieurs fois cet objet et se retrouver avec différents codes piochant dans des états pas toujours synchro...)

Je continu a douter de l'utilite que cela soit unique. Pour les materiels d'acquisition, il est tres facile d'avoir les memes resultats, que je fasse une ou vingts instances de la classe utilisant le materiel. Ceci parce que c'est mon materiel qui met a jour les etats. Certes en avoir 20 est loin d'etre utile, mais ceci sont synchronise par rapport aux actions de l'utilisateur.
Tout de meme, je ne suis pas contre la classe englobante, qui permet un acces unifie a tous les materiels enregistres dans cette classe. Mais comme je l'ai dit, pour des raisons de multijoueur ... cette classe peut aussi avoir plusieurs instances.

[Emmanuel Deloget]

A première vue, j'ai l'impression que tout ce qui est décrit comme "préoccupation transversale" en programmation par aspect (cf http://skebir.developpez.com/tutoriels/java/aspectj/), est plus ou moins sujet à être un bon singleton.

Mais d'un autre coté, c'est surtout la facon de penser son programme qui amène à ce genre de design, dans une optique plus "C++" (ou programmation par objet "classique"), on essaie d'éviter l'apparition de "préoccupation transversale", de ne pas avoir de code qui sert partout.

Et je crois comprendre, en lisant son article, que c'est sur ce point que Emmanuel dit ne pas voir d'utilisation au singleton : pas de nécessité d'avoir à la fois un point d'accés global et une garantie d'unicité en même temps.

Vrai. Global et unique signifie généralement qu'on s'attaque à une ressource proposée par le système qui lui, garanti son unicité - pour l'instant. Je n'ai aucune garantie que ça continuera à être vrai d'ailleurs (DirectX et ses Swap Chains ; les premiers versions de DX ne les implémentaient pas, parce que les setup dual monitor étaient si rares que ce n'était pas utiles).

@Emmanuel: Pour un pool mémoire utilisé par un allocateur, tu ferais comment ? Monostate et initialisation au démarrage de l'appli ?

On touche un point super fin là. Si tu me le demande en tant que concepteur de librairie, alors ma réponse est : "très certainement un monostate". Ce monostate pourra alors me servir pour paramétrer les classes d'allocateurs qui je fournirait à mes ouailles.

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
22
23
 
class system_memory_pool
{
  static some_type m_realpool;
public:
  system_memory_pool();
  char* allocate();
  void liberate(char*);
};
 
// adapter to the standard allocator interface
template <class Pool>
class pool_allocator
{
  public:
    typedef Pool pool_type;
  private:
    pool_type m_pool;
  public:
    // reste de l'interface de std::allocator
};
 
typedef std::basic_string<char, std::char_traits<char>, pool_alocator<system_memory_pool> > sys_string;

Dans le cadre d'une application, je pense que j'utiliserais une stratégie similaire.

@guillaume07: 7 objets qui peuvent être utilisés n'importe où dans le code ca sent quand même le problème de conception. En avoir un ou deux et ne pas réussir à facotoriser ca peut être normal, mais avoir tout le coeur de l'application c'est quand même étrange. Et d'autre part ta classe main ne devrait pas être à mon avis, elle ne respecte pas le SRP.

Et tu parles de thread, mais n'oublie pas que MT et singleton c'est un problème qui n'est pas trivial, soit tu créés ton instance avant d'entrer dans les thread, soit tu mets en place quelque chose à base de CAS qui doit être une solution viable (mais c'est pas si évident que ca il me semble, par contre c'est lock-free et bien fait peut-etre wait-free).

Et enfin, tu as besoin d'accéder aux listes dans les différents thread, le problème c'est que si les listes sont aussi lié qu'elles semblent l'être, il risque d'y avoir beaucoup d'accés concurrentiel, et ca c'est pas bon, les mutex (ou autre) c'est pratiques, mais si il y en a trop ca sera pas plus performant qu'en non threader, AMHA.

Sur et certain même. Et le fait que le singleton soit un objet global signifie qu'il doit être protégé contre les accès concurrents (comme tous les objets globaux). Sauf que le point d'entrée du singleton, c'est getInstance(), et qu'il faut aussi le protéger pour éviter une double création du singleton (il y a un pattern qui marche très bien pour ça). Il faut donc deux niveaux de protection, avec deux systèmes de protection différents (généralement deux mutex). Et donc une bonne possibilité de deadlock.

Singleton et MT, c'est tout sauf trivial comme problème...

[titibete]

Ca y est ! La gestion des événements est maintenant conçue comme une sorte de pattern Observateur.

Suis-je atteint de singletonite aiguë ? Plus maintenant. Merci à vous.