[C++]Destruction d'un "objet partagé" - Page 1

yop,

J'ai un objet utilisé par plusieurs "modules" de mon programme.
Ils ont tous un pointeur vers cet objet, mais un seul en est le créateur (et le destructeur).

Le truc, c'est que c'est pas forcément le créateur/destructeur qui est fermé en dernier.

J'ai donc pensé à utiliser un compteur de référence. Mais ça oblige les modules à faire ou un delete, ou un --objet->reference;
C'est crade, c'est pas à eux de choisir, je voudrais qu'ils fassent tous un delete, ils ont pas à savoir que cet objet est partagé, non ?

Alors, comment s'y prend-on habituellement, proprement, dans un cas comme ça ? On utilise un "gestionnaire" externe, qui compte les références sur l'objet et prend les bonnes décisions ?

Merci d'avance.

ça t'irait par exemple ? Sinon Brunni avait parlé il y a un moment d'une solution perso pour ce genre de cas ; il me semble que c'était techniquement proche avec une syntaxe différente, je n'étais pas convaincu perso mais ça répond surement également à ton besoin. Zerosquare saura surement retrouver le topic en un rien de temps si jamais

Zeph > shared_ptr fait tout simplement du comptage de référence, non ?
Y a-t-il d'autres méthodes (par pure curiosité) ?

Oué j'aurais aussi dirigé vers un shared pointer. (en java je laisse le garbage collecteur se démerder, je dis ça, je dis rien )

En effet shared_ptr semble être ce qu'il te faut. Tant que tu ne fait pas de référence cyclique.

Ah, c'est exactement ça qu'il me faut, j'avais déjà vu ce terme passer, mais j'en avais jamais eu besoin, merci beaucoup

Pour info, vu que j'utilise Qt, je vais utiliser la variante maison de cet outil : http://doc.qt.io/qt-5/qsharedpointer.html

flanker > en l'occurrence oui je pense que ça fait du comptage de référence ; pour les autres approches je pense en effet qu'il vaut mieux aller googler "garbage collector" et regarder les solutions proposées ^^

ok, je me demandais s'il y avait d'autres façons plus exotiques ^^

Il y a déjà un bon paquet de solutions exotiques qui ont été explorées dans ce domaine, quand même ^^ Ça ne veut pas dire qu'il n'en reste pas, mais il y a déjà de quoi faire

Zeph (./2) :
Sinon Brunni avait parlé il y a un moment d'une solution perso pour ce genre de cas ; il me semble que c'était techniquement proche avec une syntaxe différente, je n'étais pas convaincu perso mais ça répond surement également à ton besoin. Zerosquare saura surement retrouver le topic en un rien de temps si jamais

Il suffit de demander
topics/156501-gestion-de-memoire-par-refcount

Merci !

Folco (./7) :
Pour info, vu que j'utilise Qt, je vais utiliser la variante maison de cet outil : http://doc.qt.io/qt-5/qsharedpointer.html

Bon, ceci dit, j'arrive pas à faire un truc, initialiser un QSharedPointer avec un pointeur existant. Je lis surement mal la doc du constructeur, parce que je comprends pas trop pourquoiça marche pas : http://doc.qt.io/qt-5/qsharedpointer.html#QSharedPointer-2

J'écris ça : void LadderData::newPlayer(Player* player) { player_list.append(QSharedPointer<Player*>(player)); ... }
J'ai donc ça comme erreur :

/mnt/Data/prog/TBL/ladderdata.cpp:54: error: no matching function for call to 'QSharedPointer<Player*>::QSharedPointer(Player*&)'
     player_list.append(QSharedPointer<Player*>(player));
                                                      ^

J'arrive pas à savoir si c'est ma syntaxe qui est foireuse, ou l'usage de la classe.

Merci pour votre coup d'oeil affûté

Pour la destruction des objets, j'ai un outil imparrable :




et crois moi il sentira rien....



GT

Je tenterais bien un truc dans le genre :

QSharedPointer<Player> player(new Player) ;
...

void LadderData::newPlayer(const QSharedPointer<Player>& player)
{
    player_list.append(player);
    ...
}

Pas la peine de dire que c'est un pointeur dans le QSharedPointer, car c'est une classe faite justement pour encapsuler un pointeur, donc le type suffit (comme avec un auto_ptr, d'ailleurs)
Quant à l'usage, on n'utilise sans doute pas le pointeur directement mais le QSharedPointer, sinon le compteur de référence est perdu (il y a sans doute un accesseur pour récupérer le pointeur directement quand même en cas de besoin ponctuel et aussi * doit être surchargé pour renvoyer l'objet pointé.
(Mmm, tu mixes des _ et des chameaux ? )

Et sinon, comme tu travailles avec Qt, je te conseille de jeter un coup d'œil sur QSharedData et QSharedDataPointer, ces classes permettent de créer des objets où le pointeur partagé est implicite et où tu n'as donc pas besoin de travailler avec des QSharedPointer partout. (C'est comme ça que fonctionnent QString etc.)

Ok, je vais voir ça. Ah, si ça peut éviter de me faire chier pour sérialiser/désérialiser aussi, ça sera parfait.

Bon, les QSharedDataPointer, ça a l'air d'etre fait pour du Copy On Write, c'est pas ce que je veux. Je veux plusieurs pointeurs vers un objet unique, et que tous les pointeurs "sachent" quand cet objet a été détruit.

Pen² -> t'as raison, c'est comme ça que je vais faire, mon problème de design était là.

Pen^2 (./15) :
(Mmm, tu mixes des _ et des chameaux ? cheeky)

C'est la merde :

nomDeMéthode();
NomDeFonction();
MACRO
variable

Ca, c'est ok.
et ensuite, j'ai le choix :

variablesupergrandequifaitchier
VariableSuperGrandeQuiFaitChier
variable_super_grande_qui_fait_chier

Je suis pas fixé

(ps> je sais, GT, en assembleur, les registres font pas chier )

Tiens, oué, marrant de différencier à ce point, mais pourquoi pas, après tout.

(register void *a1, *a2, ... )

ayé, je sais !!!
vARIABLEsUPERgRANDEqUIfAITcHIER

Tu es battu:

http://ashutoshmehra.net/blog/2010/02/long-function-names/

RtlWriteDecodedUcsDataIntoSmartLBlobUcsWritingContext [wcp.dll], with 53-characters, was the longest one (but this function is not documented)
(52) ConvertSecurityDescriptorToStringSecurityDescriptor{A,W} [advapi32.dll], the function that Raymond Chen admitted was the reason for his post on security descriptors.
(52) ConvertStringSecurityDescriptorToSecurityDescriptor{A,W} [advapi32.dll], the complement of the above.
(50) CreatePrivateObjectSecurityWithMultipleInheritance [advapi32.dll], another security function.
(50) CertCreateCTLEntryFromCertificateContextProperties [crypt32.dll].
(50) EapHostPeerQueryUIBlobFromInteractiveUIInputFields [eappcfg.dll].
(49) AccessCheckByTypeResultListAndAuditAlarmByHandle{A,W} [advapi32.dll], yet another security API — I guess the security API programmers get a good kick from long names, just like me!
(47) GetNumberOfPhysicalMonitorsFromIDirect3DDevice9 [Dxva2.lib].
(43) SetupRemoveInstallSectionFromDiskSpaceList{A,W} [Setupapi.dll].And just so that no one thinks I’m making these up, I’ve linked to their docum

Folco (./22) :
ayé, je sais !!!
vARIABLEsUPERgRANDEqUIfAITcHIER

ou encore mieux : vArIAblEsUpErgrAndEqUIfAItchIEr
Ça porte encore mieux son nom.

-C+c ?

C'était l'idée en effet.

Folco (./18) :
Bon, les QSharedDataPointer, ça a l'air d'etre fait pour du Copy On Write, c'est pas ce que je veux. Je veux plusieurs pointeurs vers un objet unique, et que tous les pointeurs "sachent" quand cet objet a été détruit.

QExplicitlySharedDataPointer alors.

Folco (./19) :
variablesupergrandequifaitchier
VariableSuperGrandeQuiFaitChiervariable_super_grande_qui_fait_chier

La convention en Qt (comme en Java d'ailleurs) est variableSuperGrandeQuiFaitChier.

Merci Kevin, j'irai voir.

• Folco retourne bricoler