Discussion :

[Zhitoune]

Bonjour à tous,

je code un programme qui permet de contrôler une carte de génération et d'acquisition de signaux analogiques. une fois lancé l'acquisition est autonome et appelle une fonction callback static pour signaler que l’acquisition est terminée

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
 
//aogenrator:h
class aoGenerator : public QWidget
{
 
public :
 
        aoGenerator (QWidget * parent = 0);
        ~aoGenerator();
 
private :
int duree;
 
void updateDisplay();
static int32 CVICALLBACK DoneCallback (TaskHandle taskHandle, int32 status
                                         , void *callBackData);
};

j'aimerais m'en servir pour signifier l’évènement à l'interface seulement celle-ci est définie dans le même objet que DoneCallback. pour cela la variable callBackData me permet de faire passer un pointeur sur l'instance d'aogenerator et ainsi d'accéder au variable de celui-ci mais pas d'exécuter ses fonctions :

Code :

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

1
2
3
4
5
6
7
8
9
10
// aogenerator:cpp
int32 CVICALLBACK aoGenerator::DoneCallback (TaskHandle taskHandle, int32 status
                                             , void * callBackData)
{    
    aoGenerator* gen = (aoGenerator*) callBackData;//  cast de callBackData en aoGenerator
    int d = gen->duree;//marche
    gen->updateDisplay();//marche pas...
 
    return(0);
}

bref mon problème est-il du à l'aspect static de la fonction ou bien est-ce autre chose?
dans les deux cas auriez-vous une idée pour contourner ce problème?

merci d'avance!!

[Emmanuel Deloget]

Il doit y avoir un problème sur la façon dont la callback est appelée, parce que c'est la technique à utiliser.

Sauf que, sauf que, sauf que.

Si jamais QtWidget utilise l'héritage multiple, alors il y a de bonnes et tendres chances pour que, effectivement, le code ne fonctionne pas. Pour contourner le problème, il suffit d'encapsuler ton objet dans un autre - un objet callback :

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
 
class callback
{
private:
  aoGenerator* gen;
  int32 work(TaskHandle taskHandle, int32 status)
  {
    return gen->DoneCallback(taskHandle, status);
  }
public:
  callback(aoGenerator *g) : gen(g) { }
  ~callback() { }
  static int32 CVICALLBACK work(TaskHandle taskHandle, 
                                int32 status, 
                                void *callBackData)
  {
    callback *c = (callback*)callBackData;
    return c->work(taskHandle, status);
  }
};
 
// utilisation
setup_callback(..., /* pfn */ &callback::work, /* void* param */ new callback(my_gen_obj));

[gbdivers]

Si jamais QtWidget utilise l'héritage multiple

C'est QWidget (sans t )
Et effectivement, QWidget utilise le double héritage (QObject et QPaintDevice)

[Zhitoune]

Merci pour vos réponses

bon je ne saisi pas du tout le lien avec l'héritage multiple...mais je vous confiance du coup j'essaie d'implémenter l'encapsulage...ce qui peut prendre du temps. je reposte dès que j'ai du nouveau.

[Zhitoune]

C'est bon tout marche!!
merci à vous

[Emmanuel Deloget]

Merci pour vos réponses

bon je ne saisi pas du tout le lien avec l'héritage multiple...mais je vous confiance du coup j'essaie d'implémenter l'encapsulage...ce qui peut prendre du temps. je reposte dès que j'ai du nouveau.

Déjà, on note que objet* -> void* -> objet* est une transformation dont le comportement est noté comme étant indéfini dans la norme. Il y a un risque non négligeable à faire cette transformation, car elle dépends fortement de l'implémentation sous jacente.

Dans le cas de l'héritage non multiple, la transformation objet* -> void* -> objet* est plus ou moins sans risque, car objet* est un pointeur vers la vtable de l'objet dans la plupart des implémentation que je connais (plus exactement, this == pointeur sur la vtable)

Dans le cas de l'héritage multiple, objet possède plusieurs vtable. Le mécanisme de fonctionnement est différent, et les cast peuvent poser des problèmes (la cohérence entre this et les vtable n'est plus maintenue correctement). Du coup, dans la grande majorité des cas, ça plante de manière incompréhensible.

[Flob90]

Déjà, on note que objet* -> void* -> objet* est une transformation dont le comportement est noté comme étant indéfini dans la norme.

Une valeur de type pointeur sur objet convertie en pointeur sur void et reconvertie dans l'autre sens, avec un cv-qualification potentiellement différente, doit avoir sa valeur original.

(traduction libre)

[Emmanuel Deloget]

Mmm. Idem en 5.2.9 §10 dans le texte de la norme de 98.

Je vais revoir mes classiques.