Fonctions de classes de politiques par default

Version imprimable

Bonjour,
je code une sorte de wrapper autour de Glut pour la gestion de fenêtres OpenGL.
Glut a une liste de callbacks que l'on n'est pas forcé de définir, par exemples :
Code:

1 2 glutKeyboardFunc (keyboardFunc); glutMouseFunc (mouseFunc);
Pour mon wrapper j'ai décidé de coder les callbacks sous forme de classes de politiques et de créer les nouvelles classes de fenêtres comme ça :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 struct MyCallbacks { static void keyboardFunc (uint8_t key, int x, int y) { // on gère le clavier } static void mouseFunc (int button, int state, int x, int y) { // on gère la souris } // etc... }; template <typename CB> class GlutWindow { GlutWindow() { //... glutKeyboardFunc (CB::keyboardFunc); glutMouseFunc (CB::mouseFunc); } }; typedef GlutWindow<MyCallbacks> MyWindow;
Alors vous voyez surement apparaître le problème, s'il y a 15 callbacks, est-ce que je suis obligé de créer 15 fonctions dans ma politique qui resteront pour la plupart vides ?
Ou alors existe-t-il un moyen d'utiliser des fonctions par default et de ne définir que les fonctions qui serviront à quelque chose ?

Merci pour votre aide.

Considérer que les callbacks d'une classe sont statiques et ne change jamais, ce n'est pas une bonne option. Il est préférable de passer par un système plus dynamique, qui permettra alors d'ajouter une callback (ou d'en enlever une) lorsque le besoin s'en fait sentir.

Dans ce cadre, boost.signal est une alternative à étudier.

Maintenant, pour ce qui est de répondre de manière précise à ta question : si ta politique fait des choses différentes, alors ce n'est pas une bonne politique, et elle doit être cassée en politiques plus petites.

Code:

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
59
60
61
62
63
64
 
struct mouse_event_registerer
{
  typedef void (*prototype)(int button, int state, int x, int y);
 
  static void do_register(prototype p)
  {
     glutMouseFunc(p);
  }
};
 
template <
  class Handler>
struct handler_traits
{
  typedef Handler handler_type;
  typedef typename handler_type::registerer_type hander_registerer;
  typedef typename handler_registerer::prototype handler_prototype;
 
  static void do_register(handler_prototype p)
  {
    hander_registerer::do_register(p);
  }
};
 
// les handlers d'évènement souris vont dériver de ce type, ce qui
// va importer registerer_type dans le handler. Dans le cas contraire, 
// on va simplement définir registerer_type dans la class handler,
// quitte à donner un type qui n'est pas prévu par glut, pour faire
// d'autres choses. 
struct generic_mouse_handler
{
  typedef mouse_event_registerer registerer_type;
};
 
// les struct héritent en public par défaut
struct null_mouse_handler : generic_mouse_handler
{
  void execute(int button, int state, int x, int y)
  { }
};
 
template <
  class WinEventHandler, 
  class MouseHandle = null_mouse_handler, 
  class KbHandler = null_kb_handler>
class glut_window
{
public:
  typedef WinEventHandler winevent_handle_type;
  typedef MouseHandler mouse_handler_type;
  typedef KbHandler kb_handler_type;
private:
  static void handle_mouse_event(int button, int state, int x, int y)
  {
    mouse_handler_type::execute(button, state, x, y);
  }
  ...
public:
  glut_window()
  {
    event_traits<mouse_handler_type>::do_register(handle_mouse_event);
  }
};

Code:

1
2
3
4
5
6
7
8
9
 
// Et un court exemple, pour le "plaisir"
struct my_mouse_handler : generic_mouse_handler
{
  void execute(int button, int state, int x, int y)
  {
    std::cout << "b = " << button << ", x = " << x << ", y = " << y << std::endl;
  }
};

14/09/2011, 14h30
arthurG

Merci pour ta réponse, ton exemple est très intéressant.

Par contre j'ai encore des soucis, principalement à cause des fonctions static que je semble forcé d'utiliser.

Citation:

Considérer que les callbacks d'une classe sont statiques et ne change jamais, ce n'est pas une bonne option. Il est préférable de passer par un système plus dynamique, qui permettra alors d'ajouter une callback (ou d'en enlever une) lorsque le besoin s'en fait sentir.

Je ne vois pas en fait comment me passer des statics, à cause des fonctions que je dois passer en paramètre à glut. Pour faire :

Code:

glutMouseFunc(p);

à ma connaissance p doit être soit une fonction globale soit une fonction membre statique. Maintenant l'approche statique me pose des problèmes pour la gestion de plusieurs fenêtres alors je suis encore dans une impasse.

Je vais voir du côté de boost.signal, mais est-ce que ça règlerait ce problèmes de fonctions statiques en vue de gérer plusieurs fenêtres ?
14/09/2011, 14h58
Emmanuel Deloget

Citation:

Envoyé par arthurG

Merci pour ta réponse, ton exemple est très intéressant.

Par contre j'ai encore des soucis, principalement à cause des fonctions static que je semble forcé d'utiliser.

Je ne vois pas en fait comment me passer des statics, à cause des fonctions que je dois passer en paramètre à glut. Pour faire :

Code:

glutMouseFunc(p);

à ma connaissance p doit être soit une fonction globale soit une fonction membre statique. Maintenant l'approche statique me pose des problèmes pour la gestion de plusieurs fenêtres alors je suis encore dans une impasse.

Je vais voir du côté de boost.signal, mais est-ce que ça règlerait ce problèmes de fonctions statiques en vue de gérer plusieurs fenêtres ?

Je me suis mal exprimé. Dans la phrase que tu as cité, statique est l'opposé de dynamique - c'est à dire qui peut être changé au runtime - et n'est pas lié au mot-clef C++.

Effectivement, un pointeur sur fonction ne peut être initialisé qu'en référençant une fonction membre statique ou une fonction libre.

glut n'est pas fait pour gérer plusieurs fenêtres, ni même plusieurs contextes. Pour gérer plusieurs fenêtre ou contextes de rendu, il faut aller au delà de glut - soit utiliser une autre librairie, soit directement le mode natif (GLX ou WGL ou autre selon la plateforme cible).