Discussion :

[titibete]

Je développe un petit RTS, et plus j'avance, plus je crée des singletons. Comme c'est un dp très impopulaire, je me demande si tous ces singletons sont justifiés...

Donc j'ai un premier singleton qui gère tous les évènements de l'appli, un deuxième qui gère toute interaction avec la carte et enfin une douzaine () d'autres qui sont des états concrets (cf l'article de r0d : III-D).

Bien que variables globales, tous ces singletons sont "encapsulés" dans leur namespace respectif.

Mon utilisation des singletons est-elle justifiée ?

Une autre question pendant que j'y suis : mieux vaut une fonction membre static ou une fonction amie ?

Merci.

[screetch]

pour la deux, je dirai membre statique, sauf dans le cas d'opérateurs peut-être. Ca dépend. Si tu dois acceder a un état privé d'une instance, alors autant en faire une fonction membre statique.

pour la question 1, je vais répondre aisin :
il peut être légitime d'avoir une seule instance de quelque chose
il est très rarement legitime que tout le monde y ait acces
il est encore plus rarement legitime que personne n'en ait la responsabilité

dans une application très solide, tu pourrais par exemple etre capable de gérer une deuxieme carte avec son systeme d'evenement et d'autres etats concrets.

Un exemple tout con: la ou je bosse, on nous a demandé recemment de voir si on pouvait faire tourner un jeu en coop a deux sur le meme ecran. Notre systeme c'est ecroulé car on a toujours supposé un ecran, une manette, un joueur, une connection reseau. On a des tonnes de singletons qui soudainement nous ont pété a la gueule.

Meme si ca n'a pas beaucoup de sens, demande toi ce qui se passerait si tu voulais faire tourner deux jeux en parallele dans la meme application

[Mat007]

Salut,

Mon utilisation des singletons est-elle justifiée ?

Non.

La seule justification d'un singleton c'est pour des raisons de performances pour charger/initialiser des gros volumes de données qui sont constantes et se retrouvent encapsulées dans une façade unique.

mieux vaut une fonction membre static ou une fonction amie ?

Je ne vois pas trop le rapport entre les deux, tu as un exemple ?

MAT.

[titibete]

Je ne vois pas trop le rapport entre les deux, tu as un exemple ?

Code :

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

1
2
3
4
5
6
7
8
class A
{
    private:
        int i;
 
    public:
        static int doThat(A& a1, A& a2) { return a1.i - a2.i; }
};

ou

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
class B
{
    private:
        int i;
 
    friend class doThat;
};
 
struct doThat
{
    int operator() (B& b1, B& b2)
    {
        return a1.i - a2.i;
    }
};

[LittleWhite]

Bonjour,

Bon, pour les Singletons (même si j'étais un grand fan (et là, je trouve que vous exagéré)) c'est: NON !
Pour cela je vais sortir mes sources préférées:
Le blog d'Emmanuel Deloget () -> http://blog.emmanueldeloget.com/inde...e-singletonite
La documentation que mes profs donnent -> http://c2.com/cgi-bin/wiki?CppSingleton

Bon, après avoir lu tout cela, vous savez quoi faire

Pour la deuxième question, je suis très perplexe du besoin pour ce genre de chose.
Dans votre exemple du static, c'est si la fonction est static, le membre de la classe qu'utilise la fonction se doit de l'être tout autant (logique je pense). Donc, je pense (encore) que cela invalide ce que vous vouliez faire.
Maintenant pour l'histoire du friend ... je ne vois absolument pas pourquoi on en viendrai à de telles choses. Peut être voir du coté des foncteur ... (il faudra que je revois ce principe, un jour )

Sinon, je propose tout simplement:

Code :

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

1
2
3
4
5
6
7
8
 
class MyClass
{
private:
    int i;
public:
    int myFunct(const MyClass& mc) { /* le code */ } ;
};

(cela évitera toujours la copie d'un pointeur )

[Mat007]

cela évitera toujours la copie d'un pointeur

Le this a beau être un peu masqué, il est bien là.

Sinon la question n'est-elle pas plutôt entre :

Code :

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

1
2
3
4
struct A
{
    void do_that( const A& a ) const;
};

Et :

Code :

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

1
2
3
4
struct A
{
};
void do_that( const A& a1, const A& a2 );

?

MAT.

[titibete]

Le this a beau être un peu masqué, il est bien là.

Sinon la question n'est-elle pas plutôt entre :

Code :

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

1
2
3
4
struct A
{
    void do_that( const A& a ) const;
};

Et :

Code :

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

1
2
3
4
struct A
{
};
void do_that( const A& a1, const A& a2 );

?

MAT.

Sub doit etre dans la classe A, ou comme la classe B a l'extérieur :

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
class B
{
    private:
        int i;
 
    friend class Sub;
};
 
struct Sub
{
    int operator() (B& b1, B& b2)
    {
        return b1.i - b2.i;
    }
};

dans une application très solide, tu pourrais par exemple etre capable de gérer une deuxieme carte avec son systeme d'evenement et d'autres etats concrets.

Pour ce qui est des singletons, j'ai gardé celui pour ma gestion d'événements (c'est plus simple comme ça pour le moment), pas la gestion de la carte.

Quant à mes singletons pour mes différents états, au vu du nombre et de la fréquence du changement d'états, je pense que c'est mieux que new/delete... J'anticipe un peu sur l'optimisation.

[LittleWhite]

Quant à mes singletons pour mes différents états, au vu du nombre et de la fréquence du changement d'états, je pense que c'est mieux que new/delete... J'anticipe un peu sur l'optimisation.

Il devrait etre possible de precharger les etats (si changement frequent)
Sinon, un ecran de chargement (oh ... un etat en plus )
(Peut etre que je ne parle pas de meme etats que vous )

[Emmanuel Deloget]

Mon utilisation des singletons est-elle justifiée ?

La réponse est : jamais, quel que soit le contexte.

* Si le singleton est utilisé pour éviter de penser à la localité de l'objet (c'est à dire qui l'utilise et pourquoi), et bien il faut arrêter et penser à la localité de l'objet. Il ne sert à rien que le gestionnaire de son (hic) ait accès au moteur de rendu graphique.

* Si le singleton est utilisé pour contrôler l'ordre de construction des variables globales, et bien il faudrait voir à éviter les variables globales.

* Si le singleton est utilisé pour permettre l'accès à un ensemble de fonctions qui ont un intérêt pour tout le code (par exemple des fonctions de log) alors pourquoi ne pas tout simplement définir des fonctions libres de log ? Et si ces fonctions libres ont besoin de faire référence à un état (par exemple une instance particulière d'une classe logger) et bien là encore le singleton est un mauvais amis : autant passer le logger en paramètre à la fonction libre, ou prévoir des paramètres supplémentaires aux fonctions de log pour avoir un meilleur contrôle de ce qui se passe. Dans les deux cas, ça veut dire qu'il y a plusieurs logger, donc pourquoi les stocker dans un singleton ? Autant en faire des variables globales, pour autant qu'elles respectent un certain nombre de conditions.

Je remercie Gamma & al. pour l'introduction de ce mortel pattern

[NoIdea]

La réponse est : jamais, quel que soit le contexte.

Être aussi catégorique me parait être une position dure à maintenir.
Cependant, je concède qu'il est rarement nécessaire. Personnellement, je n'en ai encore jamais utilisé mais je n'irais pas jusqu'à "il ne peut y avoir un cas ou il est utile". Considère-tu que variable globale/statique (non constante) sont aussi "nocif" que les singletons ?

Quant à mes singletons pour mes différents états, au vu du nombre et de la fréquence du changement d'états, je pense que c'est mieux que new/delete... J'anticipe un peu sur l'optimisation.

Pourquoi un singleton diminuerait le nombre de new/delete ?

[Emmanuel Deloget]

Être aussi catégorique me parait être une position dure à maintenir.

Oui et non. Je penses très sincèrement pouvoir trouver une alternative sans singleton à n'importe quel design qui m'est proposé et qui utilise des singletons. Du coup, et vu les problèmes que les singletons impliquent,

Considère-tu que variable globale/statique (non constante) sont aussi "nocif" que les singletons ?

C'est pour ça que j'ai cité mon article "L'hérésie des variables globales", qui pose la question suivante : si les variables globales sont aussi mauvaise qu'on le dit, pourquoi y-en-a-t-il dans la librairie standard ? (cout, cin, ...).

La réponse à ta question passe par l'examen des variables en question, car il y a des cas où elles peuvent être tout à fait correcte - même si après, il faut aussi évaluer le design pour voir si une autre solution est envisageable - les variables globales souffre quand même du syndrome "c'est trop facile de les utiliser partout").

Du coup, selon moi, mon expérience et ma gentille petite tête, les variables globales sont très très très légèrement moins nocives que les singletons

[titibete]

Pourquoi un singleton diminuerait le nombre de new/delete ?

Etude de cas : dp state en c++
Par r0d

III-D. Les états sous forme de singleton

Une implémentation fréquente du design pattern State est d'implémenter les états sous forme de singletons. On la trouve par exemple sur cet article de Stephen B. Morris[en].

Il y a plusieurs avantages à procéder ainsi. Tout d'abord, puisque chaque état est unique, c'est assez logique d'en faire des singletons. Ensuite, ça évite de faire des new et des delete pendant l'exécution.

[jblecanard]

Ensuite, ça évite de faire des new et des delete pendant l'exécution.

Je trouve cet argument complètement fallacieux. Le nombre de new/delete étant un N fixe et particulièrement limité (puisqu'une classe par état, il ne vas pas y en avoir des centaines !), c'est totalement négligeable, à moins qu'on ne soit pas fichu de gérer sa mémoire comme il faut. Dans ce cas autant apprendre à le faire

[NoIdea]

Etude de cas : dp state en c++
Par r0d

Pourquoi ne pas faire :

Code :

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

1
2
3
4
std::container<States*> vect;//Conteneur que tu souhaites
vect.push_back(new State1);
vect.push_back(new State2);
Game g(vect.begin(), vect.end());

il suffit ensuite de delete tous les éléments de vect dans le destructeurs de Game.

Il y a un nombre fixe d'allocation (qu'au début du programme et sa ne devrait pas prendre plus de 0.3 ms sur le temps d'exécution).

[titibete]

Pourquoi ne pas faire :

Code :

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

1
2
3
4
std::container<States*> vect;//Conteneur que tu souhaites
vect.push_back(new State1);
vect.push_back(new State2);
Game g(vect.begin(), vect.end());

J'aime bien Du coup, il ne me reste plus que le singleton qui gère les évènements.

Merci NoIdea.

[NoIdea]

De rien. Préconiser les singletons pour ce genre de choses est quand même déconseillé. Par contre, un singleton pour un context OpengGL, ne me parait pas absurde.

[Emmanuel Deloget]

De rien. Préconiser les singletons pour ce genre de choses est quand même déconseillé. Par contre, un singleton pour un context OpengGL, ne me parait pas absurde.

Sauf que tu crées un contexte par fenêtre. En créant un singleton, tu empêche l'utilisateur d'avoir plus d'une fenêtre de rendu (pratique pour faire des comparaisons qualitatifs sur des expériences algorithmique).

[NoIdea]

Pas tout à fait faux, mais s'il s'agit d'un jeu en plein écran, et qu'on est sur de ne pas le faire évoluer, alors un singleton reste valide. Sinon, un singleton sur un pointeur avec un GetInstance(int Fenetre) peut marcher. Mais je doute d'être le plus compétent pour justifier l'utilité d'un singleton (n'ayant encore jamais utilisé de variable globale/statique dans un projet fini. Bien sur, certaines bibliothèques que j'utilise en utilisent).

[jblecanard]

et qu'on est sur de ne pas le faire évoluer

Là est l'erreur, on ne peut jamais en être sûr. Cf une expérience décrite plus haut dans laquelle l'auteur croyait ne jamais avoir à faire évoluer son jeu. Autant se passer du singletonn, car l'architecture sera plus facile à faire évoluer. Et si elle n'évolue pas, ça n'aura pas coûté cher de réfléchir un peu pour bien la concevoir sans singleton.

[Emmanuel Deloget]

Pas tout à fait faux, mais s'il s'agit d'un jeu en plain écran, et qu'on est sur de ne pas le faire évoluer, alors un singleton reste valide. Sinon, un singleton sur un pointeur avec un GetInstance(int Fenetre) peut marcher. Mais je doute d'être le plus compétent pour justifier l'utilité d'un singleton (n'ayant encore jamais utilisé de variable globale/statique dans un projet fini. Bien sur, certaines bibliothèques que j'utilise en utilisent).

Jusqu'au jour où tu auras deux écrans, et tu te diras "tiens, et si j'utilisais la seconde pour afficher une autre vue, par exemple une vue en fil de fer, ou le zbuffer, ou des infos de performance ?"

Et le coup du GetInstance(in fenetre) suppose qu'en fait, tu crées plusieurs instances du même objet. Ce qui, pour un singleton, serait tout à fait original