Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1685 connectés 

  FORUM HardWare.fr
  Programmation
  C++

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

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

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

n°1885879
404 Not Fo​und
Posté le 18-05-2009 à 23:15:58  profilanswer
 

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
mood
Publicité
Posté le 18-05-2009 à 23:15:58  profilanswer
 

n°1885949
Joel F
Real men use unique_ptr
Posté le 19-05-2009 à 09:41:10  profilanswer
 

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

n°1886120
404 Not Fo​und
Posté le 19-05-2009 à 15:05:17  profilanswer
 

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
n°1886123
theshockwa​ve
I work at a firm named Koslow
Posté le 19-05-2009 à 15:10:01  profilanswer
 

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
n°1886130
404 Not Fo​und
Posté le 19-05-2009 à 15:38:42  profilanswer
 

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
n°1886147
Joel F
Real men use unique_ptr
Posté le 19-05-2009 à 16:01:34  profilanswer
 

à 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é ?

n°1886180
404 Not Fo​und
Posté le 19-05-2009 à 17:08:37  profilanswer
 

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
n°1886222
Joel F
Real men use unique_ptr
Posté le 19-05-2009 à 18:01:03  profilanswer
 

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

n°1886304
404 Not Fo​und
Posté le 20-05-2009 à 01:23:51  profilanswer
 

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.


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

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

 

Sujets relatifs
Affichage d'une image JPG "sans fichier" [Résolu][résolu] afficher récursivement heure + mois sur deux champs
[C#] Faire une seule instance de dll pour deux programmes[VBAExcel Résolu] Copier coller de excel dans word
[résolu] unix - commande ps - colonne STIME - manque de précision[PHP][Resolu] Envoyer un signal à un processus depuis une page PHP ?
[résolu] Div en overflow:auto, garder le focus en bas ?[Résolu] Problème d'échappement d'apostrophes
[résolu] problème de débutant[Résolu] Alerte email
Plus de sujets relatifs à : Résolu - Attendre dans un destructeur / Tester une instance


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR