Résolu - Attendre dans un destructeur / Tester une instance

Résolu - Attendre dans un destructeur / Tester une instance - C++ - Programmation

Marsh Posté le 18-05-2009 à 23:15:58    

Bonjour,
 
Si j'ai une classe qui ressemble à ceci:

Code :
  1. class Texture{
  2.     volatile bool flag;
  3.     Texture(void);
  4.     ~Texture(void);
  5. };


 
Puis-je attendre dans le destructeur comme ceci:

Code :
  1. Texture::~Texture(){
  2.     // envoyer un signal à un thread qui assignera flag=0;
  3.     while(flag!=0){
  4.         usleep(10000);
  5.     }
  6. }


Message édité par 404 Not Found le 20-05-2009 à 03:10:06
Reply

Marsh Posté le 18-05-2009 à 23:15:58   

Reply

Marsh Posté le 19-05-2009 à 09:41:10    

moui :/ reste à faire ça proprement avec de vrai signal/slots genre boost::signals2

Reply

Marsh Posté le 19-05-2009 à 15:05:17    

Y a-t-il une meilleure manière de faire ?
 
Sinon, une question plus ou moins apparentée:

Code :
  1. Texture *object = 0;
  2. Texture *object = new Texture();
  3. delete(object);


Est-il possible de tester si l'objet est instancié avec if(object!=0) ?
J'ai essayé de faire 'this=0;' dans le destructeur puis de tester si l'objet existe sans succès ...
Faut-il garder une trace des objets qu'on charge/décharge ?
 
Désolé pour ma nooberie [:ocube]


Message édité par 404 Not Found le 20-05-2009 à 02:55:14
Reply

Marsh Posté le 19-05-2009 à 15:10:01    

si jamais this==0 dans ton destructeur alors tu as un grave problème dans ton code.
si tu veux attendre la fin d'un thread, tu dois pouvoir te mettre en attente d'un évènement. Soit tu passes par boost comme proposé plus haut, soit tu vois l'api de ton OS.


---------------
last.fm
Reply

Marsh Posté le 19-05-2009 à 15:38:42    

La deuxième question n'est pas vraiment liée à la première, je veux juste savoir si il est possible de tester si on pointe vers une instance ou si l'instance a été détruite, sans "noter" l'état de l'objet ailleurs.
Un peu comme en C où on peut faire 'ptr=NULL;' pour "invalider" un pointeur.


Message édité par 404 Not Found le 20-05-2009 à 02:56:38
Reply

Marsh Posté le 19-05-2009 à 16:01:34    

à l'interieur d'une methode this vaut toujours quelqeu chose de non NULL ... C'est le principe de la RAII ..
 
Tu cherches à faire qqchose de bien alambiqué. Quel est el but recherché ?

Reply

Marsh Posté le 19-05-2009 à 17:08:37    

Joel F a écrit :

à l'interieur d'une methode this vaut toujours quelqeu chose de non NULL ... C'est le principe de la RAII ..
 
Tu cherches à faire qqchose de bien alambiqué. Quel est el but recherché ?


 
En fait, c'est une classe Texture pour une application SDL/OpenGL. Le thread qui a ouvert le contexte OpenGL est malheureusement le seul à pouvoir charger/décharger une texture: je ne peux pas utiliser glXMakeCurrent ou similaire. Or, mes textures sont générées et mises à jour depuis l'extérieur par un autre thread, de manière asynchrone (en fonction de signaux échantillonnés via un FPGA).
 
La première question était liée à ceci:
Dans le thread de rendu, j'ai une std::queue qui contient les *texture à charger/décharger.  
Dans le constructeur de la classe Texture, je push() le pointeur this dans la queue. Tout se passe très bien, le thread de rendu charge la texture et l'affiche.
Dans le destructeur par contre, j'ai un problème: si je push() aussi le pointeur this, le destructeur se termine et quand le thread de rendu voudra décharger le premier élément de la queue, celui-ci pointera vers "quelque-part".
Je n'ai pour le moment pas trouvé d'autre solution que d'envoyer une valeur à la place du *texture, ce qui rend les fonctions moins génériques.
On peut effectivement attendre dans le destructeur, mais delete() est bloquant.
 
Pour la deuxième question:
Si j'essaie de tracer une surface avec un *texture qui a été delete(), les choses se passent logiquement très très mal. Je voulais savoir si il y a un moyen propre et "automatique" de voir si mon *texture a été instancié ou si je dois maintenir une liste des textures qui ont été instanciées.


Message édité par 404 Not Found le 20-05-2009 à 02:47:42
Reply

Marsh Posté le 19-05-2009 à 18:01:03    

A ce moment, fai tune factory propre dans le thread OGL et cache le destructeur dans la partie privée de ta classe. Rend la factory ami de ta textture comme ça elle sera seul à pouvoir la detruire.
 
Sinon, fais du pooling avec un pattern flyweight qui stocke tes textures et gérent leur detsruction façon GC à la fin des applis.
 
Mais ton truc avec des wait etc, c'ets compeltement foireux et anti-objet

Reply

Marsh Posté le 20-05-2009 à 01:23:51    

Joel F a écrit :

Sinon, fais du pooling avec un pattern flyweight qui stocke tes textures et gérent leur detsruction façon GC à la fin des applis.


 
C'est finalement le plus simple et le plus efficace.
 
Merci beaucoup.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed