Discussion :

[victor_gasgas]

Bonjour,

En fait j'ai une classe abstraite avec des fonctions virtuelles pures redefinies dans les classes filles. Et comme ces fonctions se devraient statiques. Seulement le compilo, ici g++-4.5, me dis que virtualite et static ne vont pas ensemble.

Donc j'aurais aime connaître votre avis decu, si c'est une erreur de design, comment y remedier, etc.

Merci d'avance!

[oodini]

http://www.codeguru.com/forum/archiv.../t-343277.html

[victor_gasgas]

Ah oui effectivement c'est clair maintenant!

Merci!

[LittleWhite]

Comme nous sommes sur un forum français, je me permet de traduire la réponse que l'on trouvera sur l'autre site:

Voici un extrait de la norme du langage (ISO/IEC14882 - 2003-10-15)

7 [Note: the virtual specifier implies membership, so a virtual function cannot be a nonmember (7.1.2) function. Nor can a virtual function be a static member, since a virtual function call relies on a specific object for determining which function to invoke. A virtual function declared in one class can be declared a
friend in another class.]

La traduction (sommaire):

Le spécificateur "virtual" implique l'appartenance, donc une fonction virtuelle ne peut être une fonction non membre (7.1.2). Ainsi, une fonction virtuelle ne peut être un membre statique, car l'appel à la fonction virtuelle repose sur un objet spécifique afin de déterminer la fonction a invoqué. Une fonction virtuelle déclaré dans une classe peut être déclaré amie d'une autre classe.

[3DArchi]

Salut,

Donc j'aurais aime connaître votre avis decu, si c'est une erreur de design, comment y remedier, etc.

C++ a fait le choix de ne pas mélanger fonctions de classe (static) et liaisons tardives (fn virtuelles), donc ce n'est pas possible. Pourquoi as-tu eu besoin de fonctions statiques virtuelles ?

[victor_gasgas]

En fait j'ai une collection de fonctions qui font partis de la même "famille", à savoir qu'elles me servent à effectuer des opérations sur les textures contenues dans la mémoire du GPU, comme l'allocation, l'upload de données, etc.

Or il existe plusieurs types de texture : 1D, 2D, CubeMap, 2D_Array, etc.

Donc j'ai tout regroupé dans une classe TextureOperation sous de fonctions statiques celles présentées ci-dessus puisqu'elles ne modifiaient pas l'instance et n'avait pas besoin de créer une instance. A partir de là j'ai dérivé pour chaque type; et ayant mis en virtuelle pure dans la classe de base il ne restait plus qu'à redéfinir.

J'ai donc choisis le design suivant : Il y a une classe texture qui peut prendre comme type n'importe lequel. Ensuite en fonction de ce type j’appelais le bon TextureOperation (grâce a un std::find_if car j'ai un std::vector possédant une instance de chacun des classes dérivées).

Il m’a donc fallut enlevé le static pour que sa compile et je pense bien avoir une erreur de design...

Si ce n'est pas trop clair je peux poster un bout de code pour résumer un peu mieux.

[3DArchi]

Salut,
Je vois à priori 2 approches :
* Tu as une seule classe texture et elle peut alors utiliser une fabrique d'opération. Cette fabrique peut simplement s'appuyer sur un std::map<key,std/tr1/boost::function<void (void)>>.

* Tu as une hiérarchie de classes texture et à chaque classe correspond une opération. Tu peux t'inspirer du double dispatch:

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
24
25
26
27
28
class base
{
public:
   virtual ~base(){}
   void operation()const
   {
      do_operation();
   }
private:
   virtual void do_operation()const=0;
};
 
class A;
 
template<class T> struct operation_policy;
template<> struct operation_policy<A>
{
   void do_it(A const&);
};
 
class A : public base
{
private:
   virtual void do_operation() const
   {
      operation_policy<A>().do_it(*this);
   }
};

ou en t'inspirant du CRTP:

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
template<class T> struct operation_policy;
 
template<class Derive>
class base
{
public:
   virtual ~base(){}
   void operation()const
   {
      operation_policy<Derive>().do_it(static_cast<Derive const&>(*this));
   }
};
 
class A : public base<A>
{
};
 
template<> struct operation_policy<A>
{
   void do_it(A const&);
};

[victor_gasgas]

Je suis plutôt dans la première approche.

Ayant plusieurs fonctions à redéfinir à chaque fois, il me faut au tant de std::map que de fonction (j'utilise c++0x donc c'est bon pour std::function)

Et y aurait-il un moyen de remplir ces map tout seul où je tout faire a la main comme actuellement quand je rempli mon std::vector.

Merci pour votre intérêt!

[3DArchi]

Si ton compilateur le permet, tu peux utiliser les initialisations à la C++11:

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#include <functional>
#include <map>
#include <iostream>
#include <algorithm>
 
void function_1()
{
    std::cout<<"1\n";
}
 
void function_2()
{
    std::cout<<"2\n";
}
 
void function_3()
{
    std::cout<<"3\n";
}
 
int main()
{
    enum key {
        key_1,
        key_2,
        key_3
    };
    std::map<key,std::function<void(void)>> const my_map={
    {key_1, function_1}
    ,{key_2, function_2}
    ,{key_3, function_3}
    };
 
    std::for_each(my_map.begin(),my_map.end(),[](std::pair<const key,std::function<void(void)> > const&par )
    {
        par.second();
    }
    );
}

[victor_gasgas]

Oui oui je suis sous g++-4.6 donc je peux quand même bien utiliser le c++0x.

Mais bon le problème avec ça c'est que je vais devoir avoir une std::map pour chacune des fonctions, et je pense qu'en cas d'ajout de nouvelles fonctions ça peut être compliqué pour la maintenance (comprendre par là pas la façon la plus aisé)

[pyros]

J'avoue ne pas avoir tout saisi de ton problème, mais est-ce qu'un (genre de) singleton ne pourrai pas t'aider ?

Au lieu d'avoir un TextureOperation avec des méthodes static, tu as un TextureOperation::getInstance("1D") par exemple, qui retourne l'unique instance de TextureOperation1D, et tu appel TextureOperation::getInstance("1D")->alloc() au lieu de TextureOperation1D::alloc.

Le singleton n'est peut-être pas ce qu'il y a de plus propre (surtout détourné de cette manière), mais il est tellement pratique

[3DArchi]

Mais bon le problème avec ça c'est que je vais devoir avoir une std::map pour chacune des fonctions, et je pense qu'en cas d'ajout de nouvelles fonctions ça peut être compliqué pour la maintenance (comprendre par là pas la façon la plus aisé)

Avoir une map par fonction, ça n'a plus aucun intérêt. Je suppose que la signature de tes fonctions est différente et c'est ce qui cloche. Passe par un type erasure pour le stockage. Un Boost.Any ou peut être un Boost.Fusion ?

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
#include <functional>
#include <iostream>
#include <string>
#include <boost/fusion/include/map.hpp>
#include <boost/fusion/include/make_map.hpp>
#include <boost/fusion/include/at_key.hpp>
 
void function_1(int i)
{
    std::cout<<"function_1("<<i<<")\n";
}
 
void function_2(double d)
{
    std::cout<<"function_2("<<d<<")\n";
}
 
void function_3(std::string s)
{
    std::cout<<"function_3("<<s<<")\n";
}
namespace
{
    struct key_1;
    struct key_2;
    struct key_3;
    typedef std::function<void (int i)> type_fun_1;
    typedef std::function<void (double d)> type_fun_2;
    typedef std::function <void (std::string s)> type_fun_3;
 
    typedef boost::fusion::map<
     boost::fusion::pair<key_1,type_fun_1>
     ,boost::fusion::pair<key_2,type_fun_2>
     ,boost::fusion::pair<key_3,type_fun_3>
    > type_map_operations;
}
 
int main()
{
    type_map_operations const operations  = boost::fusion::make_map<key_1,key_2,key_3,type_fun_1,type_fun_2,type_fun_3>(
        function_1,function_2,function_3);
    boost::fusion::at_key<key_1>(operations)(1);
    boost::fusion::at_key<key_2>(operations)(2.4);
    boost::fusion::at_key<key_3>(operations)("tutu");
 
 
    return 0;
}

[3DArchi]

La remarque de pyros m'a fait tilter que je n'avais peut être pas compris ton problème. J'ai repris ton message :

J'ai donc choisis le design suivant : Il y a une classe texture qui peut prendre comme type n'importe lequel. Ensuite en fonction de ce type j’appelais le bon TextureOperation (grâce a un std::find_if car j'ai un std::vector possédant une instance de chacun des classes dérivées).

Il m’a donc fallut enlevé le static pour que sa compile et je pense bien avoir une erreur de design...

A priori, ce n'était pas un si mauvaise idée que ça. Tu avais quelque chose comme ça :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
#include <map>
#include <memory>
namespace
{
struct Operations
{
   virtual void f1()=0;
   virtual void f2()=0;
   virtual void f3()=0;
};
 
struct Operations_1 : public Operations
{
   virtual void f1(){}
   virtual void f2(){}
   virtual void f3(){}
};
 
struct Operations_2 : public Operations
{
   virtual void f1(){}
   virtual void f2(){}
   virtual void f3(){}
};
 
struct Operations_3 : public Operations
{
   virtual void f1(){}
   virtual void f2(){}
   virtual void f3(){}
};
 
enum Keys
{
   Key_1
   ,Key_2
   ,Key_3
};
typedef std::map<Keys,std::shared_ptr<Operations>> type_operations_cont;
}
 
 
 
int main()
{
   type_operations_cont operations=
   {
      {Key_1,std::shared_ptr<Operations>(new Operations_1)}
      ,{Key_2,std::shared_ptr<Operations>(new Operations_2)}
      ,{Key_3,std::shared_ptr<Operations>(new Operations_3)}
   };
 
   operations[Key_1]->f1();
   operations[Key_2]->f3();
   operations[Key_3]->f2();
 
   return 0;
}

Si ce n'est pas trop clair je peux poster un bout de code pour résumer un peu mieux.

vas-y. Ca clarifiera toujours un peu

[victor_gasgas]

En fait c'est exactement le code que tu as donné

Juste peut-être quelque points :

- J'utilise pas une std::map mais un std::vector avec std::find_if + une lambda. Mais je pense pas changé car la key est viens de la classe Opération dérivée : c'est une fonction membre redéfinie.

- J'utilise comme toi des std::shared_ptr mais je les crées avec std::make_shared plutôt qu'un new.

Mais bon en fait c'est le fait d'avoir du retirer le static pour compiler qui m'avait paru bizarre comme solution.