Discussion :

[dragonjoker59]

Bonjour, j'ai un problème pour compiler un bout de code sous Gcc, alors qu'il compile sous Visual Studio 2010 :

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
 
// Manager.hpp
namespace Castor
{	namespace Templates
{
	template <typename obj, typename key>
	class Manager
	{
	public:
		typedef std::shared_ptr<obj> obj_ptr;
		typedef std::map<key, obj_ptr> obj_map;
 
		static obj_map m_objectMap;
	};
}
}

Code :

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

1
2
//FontManager.cpp
Castor::Templates::Manager<Font, std::string>::obj_map Castor::Templates::Manager<Font, std::string>::m_objectMap;

Sous Gcc cette erreur me tombe dessus :

error: specializing member 'Castor::Templates::Manager<Font, std::string>::m_objectMap' requires 'template<>' syntax

Donc, quelle bêtise ai-je faite ? déclarer un memebre statique dans une classe template, ou autre chose ?

[Goten]

(le message d'erreur est assez clair pourtant) :

Code :

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

1
2
3
 
template <>
Castor::Templates::Manager<Font, std::string>::obj_map ...;

ou si tu veux que ça soit pour tout type

Code :

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

1
2
3
 
template <typename obj, typename key>
Castor::Templates::Manager<obj, key>::obj_map ...;

[dragonjoker59]

C'est ce que j'ai fait au début, par contre si je fais ça, il sort en erreur au link en me faisant la bonne vieille

undefined reference to Castor::Templates::Manager<Font, std::string>::m_objectMap

(oublié de le préciser dans le message d'origine)

[dragonjoker59]

Bon, je vais me cacher, je sais maintenant pourquoi ça ne fonctionnait pas.
Je ne peux pas utiliser la spécialisation partielle parce que je ne connais à l'avance pas les types qui pourront être managés, donc il faut que j'utilise la déclaration 'pour tout type'.
Mais surtout, il ne faut pas que je fasse comme d'habitude avec les membres statiques (que j'initialise dans le .cpp ). Vu que c'est du template, il faut que je le fasse dans le .h

[3DArchi]

Code a.h :

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
#include <memory>
#include <map>
 
struct Font{};
 
namespace Castor
{	namespace Templates
{
	template <typename obj, typename key>
	class Manager
	{
	public:
		typedef std::shared_ptr<obj> obj_ptr;
		typedef std::map<key, obj_ptr> obj_map;
 
		static obj_map m_objectMap;
	};
}
}

Code a.cpp :

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

1
2
3
4
5
6
#include "a.h"
 
#include <string>
 
	template <>
    typename Castor::Templates::Manager<Font,std::string>::obj_map Castor::Templates::Manager<Font,std::string>::m_objectMap =Castor::Templates::Manager<Font,std::string>::obj_map();

Code main.cpp :

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

1
2
3
4
5
6
7
8
9
10
#include <string>
 
#include "a.h"
 
 
int main()
{
    Castor::Templates::Manager<Font, std::string>::m_objectMap["tutu"] = std::shared_ptr<Font>(new Font());
    return 0;
}

[dragonjoker59]

@3dArchi : Je ne peux justement pas écrire le fichier a.cpp, car je ne sais pas à ce moment là quels sont les différents types managés. J'avais donc mis cette ligne

Code :

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

template <> typename Castor::Templates::Manager<Font,std::string>::obj_map Castor::Templates::Manager<Font,std::string>::m_objectMap = Castor::Templates::Manager<Font,std::string>::obj_map();

dans le cpp de mon FontManager, et j'avais alors l'erreur de link citée plus haut.

[3DArchi]

@3dArchi : Je ne peux justement pas écrire le fichier a.cpp, car je ne sais pas à ce moment là quels sont les différents types managés. J'avais donc mis cette ligne

Code :

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

template <> typename Castor::Templates::Manager<Font,std::string>::obj_map Castor::Templates::Manager<Font,std::string>::m_objectMap = Castor::Templates::Manager<Font,std::string>::obj_map();

dans le cpp de mon FontManager, et j'avais alors l'erreur de link citée plus haut.

Il te suffit d'écrire dans FontManager.cpp :

Code :

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

1
2
template <>
    typename Castor::Templates::Manager<Font,std::string>::obj_map Castor::Templates::Manager<Font,std::string>::m_objectMap =Castor::Templates::Manager<Font,std::string>::obj_map();

L'important étant : =Castor::Templates::Manager<Font,std::string>::obj_map();

De la même façon que tu peux faire :

Code a.h :

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
#include <memory>
#include <map>
 
struct Font{};
 
namespace Castor
{	namespace Templates
{
	template <typename obj, typename key>
	class Manager
	{
	public:
		typedef std::shared_ptr<obj> obj_ptr;
		typedef std::map<key, obj_ptr> obj_map;
 
		static obj_map m_objectMap;
	};
}
}

Code a.cpp :

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

1
2
3
4
5
6
#include "a.h"
 
#include <string>
 
template <typename obj, typename key>
typename Castor::Templates::Manager<obj,key>::obj_map Castor::Templates::Manager<obj,key>::m_objectMap;

Code main.cpp :

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

1
2
3
4
5
6
7
8
9
10
#include <string>
 
#include "a.h"
 
 
int main()
{
    Castor::Templates::Manager<Font, std::string>::m_objectMap["tutu"] = std::shared_ptr<Font>(new Font());
    return 0;
}

[3DArchi]

ceci dit, cette variable statique ressemble méchamment à un singleton qui ne veut pas dire son nom (parce qu'il en a honte ??).

[dragonjoker59]

En fait c'est pour virer les singleton, et passer en monostate design pattern.

[3DArchi]

Au début, on utilise des variables globales
... et on se fait taper sur les doigts
Tout penaud, on lit le GoF et on utilise .... des singletons
.... et on se prend "Why Singletons are Evil" ou Etes-vous atteint de Singletonite ?
On retourne à ses classiques et on trouve .... mono state pattern
se fera-t-on bientôt reprendre ???
.


Variable globales, singletons, mono state partagent les mêmes inconvénients à plus ou moins grand degré : pb couplage (=> flexibilité, reuse, maintenance), pb de multitâche, pb de réentrance, durée de vie mal maîtrisée, cohérence difficile à assurer.... In fine, ca rend les fonctions impures, c'est dire si c'est dégueulasse comme truc

=> injection de dépendance ?

hors toutes ces considérations, les noms utilisés dans un code sont souvent un indicateur sur des questions d'architecture à se poser d'urgence. Parmi ces noms, j'ai un avis très tranché sur manager : manager en développement, c'est comme en entreprise : responsabilités mal définies, veut en faire trop, du coup fait mal ce qu'il fait, fout le b..del dans le design et finit par être court-circuité.

[Flob90]

Bonsoir,

Parmi ces noms, j'ai un avis très tranché sur manager : manager en développement, c'est comme en entreprise : responsabilités mal définies, veut en faire trop, du coup fait mal ce qu'il fait, fout le b..del dans le design et finit par être court-circuité.

A ce sujet je crois que Emmanuel avait fait un message assez conséquent sur le forum où quelqu'un avait justement poster un de ces codes impliquant un "manager" pour essayer de refaire tout ca sans celui-ci.

La conclusion de Emmanuel était la même que toi : le nom manager est un nom fourre-tout derrière lequel se retrouve divers composants (conteneur/factory entre autre). Et qu'une classe "manager" c'est un indicateur qui doit nous dire "attention je suis peut-être en train d'aller contre le SRP".

Je ne sais plus quel était le titre du topic, si quelqu'un d'autre s'en souvient, les codes d'exemples étaient assez instructifs je crois (le sujet de départ était peut-être bien le singleton).

[Goten]

http://www.developpez.net/forums/d82...r/#post4745900
?

[Flob90]

Oui cette discussion, le message que tu pointes d'Emmanuel et les suivants.

[dragonjoker59]

En fait, ma classe template Manager est essentiellement une classe de collection, par exemple j'ai un FontLoader en plus de mon FontManager, de même pour les classes Image, Material et Mesh.
Il faudrait peut-être que je change le nom de Manager vers autre chose.
Par contre, le côté mono state me plaît bien, actuellement je n'ai pas le besoin d'avoir plusieurs 'Manager' d'objets de même type.

[3DArchi]

Salut,

En fait, ma classe template Manager est essentiellement une classe de collection, par exemple j'ai un FontLoader en plus de mon FontManager, de même pour les classes Image, Material et Mesh.
Il faudrait peut-être que je change le nom de Manager vers autre chose.

Le nom est juste un indicateur. Le problème demeure dans un... Comment c'était dit dans la discussion ? Ah oui, le problème est l'existence de God Object.

Par contre, le côté mono state me plaît bien, actuellement je n'ai pas le besoin d'avoir plusieurs 'Manager' d'objets de même type.

Je voulais juste souligner que variable globale, singleton ou mono state, c'est la même chose avec les mêmes faiblesses apportées à l'architecture.