class template membre statique

Version imprimable

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

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:

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 :

Citation:

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 ?

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

1 2 3 template <> Castor::Templates::Manager<Font, std::string>::obj_map ...;
ou si tu veux que ça soit pour tout type
Code:

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

29/06/2011, 09h28
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

Citation:

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

(oublié de le préciser dans le message d'origine)
29/06/2011, 10h34
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 :aie:). Vu que c'est du template, il faut que je le fasse dans le .h

Code:

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:

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:

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;
}

29/06/2011, 12h39
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:

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.

Citation:

Envoyé par 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:

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:

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:

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:

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:

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; }

29/06/2011, 14h13
3DArchi

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

En fait c'est pour virer les singleton, et passer en monostate design pattern.
29/06/2011, 18h47
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 ???
:aie:.

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 :mouarf:

=> 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é.
29/06/2011, 19h00
Flob90

Bonsoir,

Citation:

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).
29/06/2011, 21h43
Goten

http://www.developpez.net/forums/d82...r/#post4745900
?
29/06/2011, 22h02
Flob90

Oui cette discussion, le message que tu pointes d'Emmanuel et les suivants.
30/06/2011, 09h53
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.
30/06/2011, 13h50
3DArchi

Salut,

Citation:

Envoyé par 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.

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.

Citation:

Envoyé par dragonjoker59

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.