Différence entre std::unique_ptr et std::shared_ptr.(Quand les utiliser ?)

Version imprimable

15/09/2014, 13h11
Invité

Différence entre std::unique_ptr et std::shared_ptr.(Quand les utiliser ?)

Salut.

J'hésite souvent entre les 2.

std::unique_ptr me donne souvent des erreurs du style use of deleted function. (Je ne l'utilise presque jamais à vrai dire)

std::shared_ptr : j'ai moins de problème avec.

Si j'ai bien compris la documentation std::unique_ptr est préférable si le pointeur n'est pas copiable, c'est bien ça ?

Donc il faut obligatoirement redéfinir un move constructor pour transférer le contenu d'un pointeur à l'autre.

Donc à priori std::unique_ptr ne serait à utiliser que pour les pointeurs non copiable.

Tandis que std::shared_ptr si j'ai bien compris, est à utiliser pour les pointeurs qui peuvent être copiés.

Donc si je comprends bien, std::unique_ptr est préférable dans le cas ou un objet ne peux être référencer que par un seul pointeur à la fois dans tout le programme.

Je ne comprend pas très bien leur intérêt. :/
15/09/2014, 13h36
Flob90

Bonjour,

L'utilité des pointeurs intelligents (peu importe lesquels) c'est de gérer le cycle de vie d'une ressource. Leur nécessité est du à la grande difficulté (impossibilité) de gérer manuellement (avec new/delete ou tout autre fonctions de création/libération à appeler systématiquement) les ressources en C++ dès qu'on dépasse le cadre de une ressource (et encore).

Gérer le cycle de vie va donc consisté à appeler automatiquement la fonction de libération (delete) et à associer le plus tôt possible le pointeur intelligent à la fonction de création (new). Techniquement on se retrouve donc avec une capsule RAII (unique_ptr/shared_ptr) et sa fonction de création (make_unique/make_shared).

Maintenant la différence tiens à savoir qui gère la ressource, ou plus exactement combien de personne en même temps. Si la ressource doit n'être gérer que par une personne, alors c'est unique_ptr qui convient, si par contre plusieurs personne doivent la gérer alors c'est shared_ptr (et son copain weak_ptr). On doit plus souvent se retrouver dans le cas de unique_ptr.

Pour l'utilisation, non il n'y a rien de spécial à redéfinir, tes erreurs sont surement du à la tentative de copier un unique_ptr, ce qui est une erreur, il y a un seul propriétaire, quel sens donner à la copie ? On peut par contre le transférer (avec move).
15/09/2014, 14h00
Invité

Ok donc si j'ai bien compris :

std::unique_ptr est plutôt à utilisé si, par exemple, un personnage possède un pointeur sur une arme et lors de la création d'un autre personnage prenant la même arme que le 1er personnage, le pointeur sur l'arme doit être ré-alloué et tout le contenu de la classe arme doit être copier.

std::shared_ptr est plutôt à utilisé dans l'autre cas, si par exemple, j'ai une ressource qui possède un pointeur sur une texture et je veux que l'autre ressource contienne aussi un pointeur pointant sur la même texture.

Donc, j'utiliserais plutôt std::unique_ptr dans le cadre de classes copiable (ce qui est en effet la sémantique la plus souvent utilisée) et std::shared_ptr dans le cadre de classes non copiable.

Bref je vais essayer de remplacer tout les raws pointers utilisé dans mon framework par des std::unique_ptr et std::shared_ptr.

Pour le premier exemple, non rien n'est ré-alloué, je vais prendre cet exemple. On a donc une classe character et une classe weapon :
Code:

1 2 3 4 5 6 7 8 struct weapon { }; struct character { };
Premier point, quel sémantique de weapon ? A priori entité, donc non copiable (par contre déplaçable) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 struct weapon { weapon() =default; weapon(weapon&) =delete; weapon(weapon&&) =default; weapon& operator=(weapon&) =delete; weapon& operator=(weapon&&) =default; }; struct character { };
(Je lui ai aussi mis un constructeur par défaut pour que ca compile). Maintenant la sémantique de character, c'est la même. On a aussi un lien entre weapon et character l'un peut posséder l'autre et c'est l'unique possesseur : c'est typiquement le cas d'utilisation d'un std::unique_ptr (unicité et facultatif ou changeable) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 struct weapon { weapon() =default; weapon(weapon&) =delete; weapon(weapon&&) =default; weapon& operator=(weapon&) =delete; weapon& operator=(weapon&&) =default; }; class character { std::unique_ptr<weapon> hand; };
Je profite de la sémantique de std::unique_ptr qui est entité et qui s'impose à character par transitivité pour ne pas réécrire les services delete/default. Ensuite on va dire qu'un personnage peut laisser tomber son arme et qu'il peut prendre une arme (et dans ce cas il lâche celle qu'il possède) :
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 struct weapon { weapon() =default; weapon(weapon&) =delete; weapon(weapon&&) =default; weapon& operator=(weapon&) =delete; weapon& operator=(weapon&&) =default; }; struct character { auto release() { using std::swap; std::unique_ptr<weapon> empty; //On créé une main vide swap(hand,empty); //On échange la main vide avec notre main return empty; //On retourne la main qu'on avait créé } auto equip(std::unique_ptr<weapon>&& to_equip) { using std::swap; swap(hand,to_equip); //On échange notre main avec l'arme qu'on veut return std::move(to_equip); //On retourne ce qu'on avait dans la main } private: std::unique_ptr<weapon> hand; };
(On peut faire un peu autrement, mais je trouve que c'est ainsi que c'est sémantiquement le plus clair). Un main pour illustrer tout ça :
Code:

1 2 3 4 5 6 7 8 int main() { character david; //David apparait david.equip(std::make_unique<weapon>()); //Il s'équipe d'une arme character goliath; //Goliath arrive goliath.equip(david.release()); //David laisse tomber son arme et Goliath s'en équipe }
Pour les shared_ptr j'ai pas d'exemple d'utilisation, je ne sais pas si c'est ce qui convient pour des textures.

15/09/2014, 14h43
Médinoc

Normalement, les deux tendent à être utilisés avec des classes non-copiables: Tout dépend de qui gère la durée de vie.

Par exemple, un conteneur (vector, map etc.) de unique_ptr est une bonne idée, préférable à shared_ptr, si tu veux que le conteneur gère la durée de vie du contenu.
15/09/2014, 15h03
Invité

Ha ok donc ça ne convient pas vraiment dans le cadre des classes copiable alors ?

Alors que devrais je faire dans le cadre des classes copiable, faire une méthode clone et, recréer un std::unique_ptr ?

Bref dans les exemple que flob90 m'a donné, il faisait ça.

Pas nécessairement, disons que A et B sont copiables et que A gère un std::unique_ptr sur B :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 struct A {}; struct B { B() =default; B(const B& rhs) : a(rhs.a ? std::make_unique<A>(*rhs.a) : std::unique_ptr<A>()) {} B& operator=(const B& rhs) { a=std::make_unique<A>(*rhs.a); return *this; } private: std::unique_ptr<A> a; };
Dans le code que j'ai écrit sur l'autre sujet, j'utilise un fonction clone car on est dans une hiérarchie d'héritage, ça me permet d'avoir un notion de copie/clonage sans avoir le slicing.

15/09/2014, 15h30
Invité

Ok, je comprends mieux maintenant, merci. :)
15/09/2014, 20h59
Invité

Une dernière question.

Salut, si je suis dans ce cas là :

J'ai un std::vector qui possède des pointeurs sur toutes les entités du monde. (ce vecteur là sert aussi de propriétaire qui libère les ressources)
J'ai un second sdt::vector qui contient des pointeurs sur les entités du monde qui sont visible par le joueur.

Le second std::vector n'est donc pas propriétaire, il utilise juste la ressource.

Il n'y a pas de std::weak_ptr pour les std::unique_ptr.

Comment dois je procéder pour convertir les std::unique_ptr en std::shared_ptr voir même en std::weak_ptr ?
15/09/2014, 21h09
Médinoc

Références (possiblement avec reference_wrapper?), pointeurs nus ou indices.
15/09/2014, 22h33
Invité

Ok.

Pour l'instant j'utilise des pointeurs nus.
17/09/2014, 00h01
koala01

Salut,

Citation:

Envoyé par Lolilolight

Ha ok donc ça ne convient pas vraiment dans le cadre des classes copiable alors ?

Alors que devrais je faire dans le cadre des classes copiable, faire une méthode clone et, recréer un std::unique_ptr ?

Bref dans les exemple que flob90 m'a donné, il faisait ça.

Typiquement, une classe a soit sémantique de valeur, soit sémantique d'entité (du moins, si on exclu les conteneurs de la réflexion, car il prennent la sémantique des éléments qu'ils contiennent ;)) et une classe ayant sémantique de valeur est copiable et affectable (mais il est généralement bon de veiller à ce que ce soit une classe non modifiable) alors qu'une classe ayant sémantique d'entité n'est ni copiable ni affectable (mais il est généralement possible d'en modifier l'état).

Les classes ayant sémantique de valeur correspondent systématiquement à des objets dont on peu retrouver différentes instances strictement identiques en mémoire à un instant donné et peuvent assez facilement entrer dans la catégorie des "types primitifs de ton DSL (Domain specific language, ou, si tu préfères, les termes que tu utilises pour expliquer les données métier que tu dois manipuler) et qui n'ont aucun sens à entrer dans une hiérarchie de classe (à intervenir dans un relation d'héritage). Une date, une heure, une couleur, une coordonnée, un montant ou une unité (metre, seconde, euro, gramme, ...) sont autant de classes ayant sémantique de valeur.

Les classes ayant sémantique d'entité correspondent quant à elles à des objets qui doivent être identifiable de manière unique et non ambigue. Tu ne peux donc pas trouver, à un instant T, plusieurs instances représentant exactement les même valeurs, autrement, tu perds la notion d'unicité, et tu risque d'appliquer à l'une des changements qui auraient du être appliqués à d'autres. Les classes ayant sémantique d'entité sont les candidates idéales pour créer des hiérarchies de classes (qu'elles soient des classes de base ou des classes dérivées). Vehicule, Arme, CompteBanquaire etc sont autant de classes ayant sémantique d'entité.

Si je place la classe Arme dans cette catégorie, c'est parce que tu peux en effet avoir plusieurs classes qui héritent de cette classe (Epée, dague, arc, sarbaccane, lance-pierre, j'en passe et de meilleures, entrent toutes dans la catégorie "armes" ;))

A priori, le problème ne devrait donc pas se poser pour les classes copiables, car il s'agit de classe ayant sémantique de valeur qui n'interviendront donc jamais dans une hiérarchie de classes et pour lesquelles il n'y a donc absolument aucune raison de recourir à l'allocation dynamique de la mémoire. Et, si tu n'as aucune raison de recourir à l'allocation dynamique de la mémoire, tu n'as donc aucune raison d'envisager le recours à une capsule RAII afin d'assurer la libération correcte de la mémoire au moment où cela s'avère opportun ;)

L'idée générale est donc :
1- Utiliser l'allocation dynamique de la mémoire uniquement lorsque tu en as besoin, c'est à dire lorsque tu veux pouvoir disposer de collections contenant des objets dont le type entre dans la catégorie des classes ayant sémantique de valeur (comme ces objets ne sont ni copiable ni affectables, l'utilisation de pointeurs devient la seule solution pour créer ce type de collection et l'allocation dynamique de la mémoire s'avère être la seule solution permettant d'avoir la certitude que les objets renvoyés ne seront pas détruits par mégarde).

2-Si tu dois recourir à l'allocation dynamique de la mémoire, tu devrais l'encapsuler dans une ressource RAII (std::unique_ptr ou std::shared_ptr)

3- Tu devrais, autant que possible, faire en sorte de n'avoir qu'un et un seul objet qui sera responsable de la libération des ressources allouées dynamiquement, mais ce n'est pas forcément toujours possible

4- Si tu arrive à faire en sorte qu'il n'y a qu'un et un seul décideur du moment où les ressources allouées à un objet doivent être libérées (comprends : si tu n'as qu'un et un seul responsable de la durée de vie pour les objets pour lesquels tu as eu recours à l'allocation dynamique de la mémoire, même s'il est possible de "passer la patate chaude" à quelqu'un d'autre), std::unique_ptr est ce qu'il te faut

5- Si tu n'arrive pas à faire en sorte qu'il n'y ait qu'un et un seul décideur pour ce qui est de la durée de vie des objets pour lesquels tu as eu recours à l'allocation dynamique de la mémoire, tu devras "en désespoir de cause" te tourner vers std::shared_ptr (et son pendant std::weak_ptr)
17/09/2014, 12h01
mintho carmo
Citation:

Envoyé par koala01

4- Si tu arrive à faire en sorte qu'il n'y a qu'un et un seul décideur du moment où les ressources allouées à un objet doivent être libérées (comprends : si tu n'as qu'un et un seul responsable de la durée de vie pour les objets pour lesquels tu as eu recours à l'allocation dynamique de la mémoire, même s'il est possible de "passer la patate chaude" à quelqu'un d'autre), std::unique_ptr est ce qu'il te faut

5- Si tu n'arrive pas à faire en sorte qu'il n'y ait qu'un et un seul décideur pour ce qui est de la durée de vie des objets pour lesquels tu as eu recours à l'allocation dynamique de la mémoire, tu devras "en désespoir de cause" te tourner vers std::shared_ptr (et son pendant std::weak_ptr)

Je trouve que ces 2 derniers points sont incomplets.

A mon avis :
- un seul propriétaire et un seul observateur (le propriétaire) ==> unique_ptr
- plusieurs propriétaire OU pluisuers observateur ==> shared_ptr
Par défaut, on doit considérer que l'on est en multithreads (soit parce que c'est effectivement le cas, soit parce que rien n'interdit dans le design que ça ne sera pas le cas dans le futur). Dans cette situation, avec unique_ptr, pour avoir un observateur, on peut passer :
- par un pointeur nu ==> impossible de vérifier si l'objet est détruit ou non
- une référence ou un équivalent de weak_ptr ==> impossible de garantir que l'objet n'est pas détruit entre le moment où l'on teste la validité de l'objet et le moment où on l'utilise
Dans les 2 cas, le design est problématique

Le seul moyen sécurisé d'avoir plusieurs observateurs est d'utiliser shared_ptr/weak_ptr. Le premier est utilisé pour avoir plusieurs propriétaire de la ressource (situation qui devrait reste rare), le second pour avoir plusieurs observateurs sur la ressource. Lorsqu'un observateur souhaite utiliser la ressource, il doit localement promouvoir le weak_ptr en shared_ptr (et dans ce cas, le shared_ptr est détruit à la fin du bloc, l'observateur est juste un propriétaire temporaire)

Donc à mon sens, le cas 4 correspond à unique_ptr si pas d'autre observateur que le propriétaire ou shared_ptr/weak_ptr s'il y a plusieurs observateurs
17/09/2014, 12h37
Médinoc

Ça dépend de la durée de vie des observateurs eux-mêmes (ou de leurs liens vers l'objet). Selon les circonstances, ils peuvent être garantis être détruits avant l'objet lui-même.
17/09/2014, 13h00
mintho carmo

Citation:

Envoyé par mintho carmo

soit parce que rien n'interdit dans le design que ça ne sera pas le cas dans le futur

Cela fait parti des contraintes sur le design dont je parlais.

Effectivement, si le propriétaire et l'observateur sont dans le même thread, même si l'application est multi-threads, on pourra raisonner en termes de thread unique. Ou si le design fait que le thread ont une durée de vie plus courte que le propriétaire (par exemple si le propriétaire est un pool d'objets, qu'il ne les détruit jamais - sauf en quittant l'application)

Mais cela a un impact en termes d'évolutivité du code. Un code conçu directement avec shared_ptr/weak_ptr sera plus robuste qu'un code conçu avec unique_ptr/& (ou weak_unique_ptr). Il faut voir si le coût d'utilisation de shared_ptr est critique ou non. Par défaut, je conseille son utilisation
17/09/2014, 13h13
Ehonn

Par défaut, je "déconseille" son utilisation et demande de bien identifier qui est responsable de la durée de vie de l'objet à l'instant t dans la vie du programme et pas dans les éventuelles améliorations / évolutions qui ne seront probablement jamais faites. (C'est plus facile de passer d'un unique_ptr à un shared_ptr que l'inverse.)
17/09/2014, 13h25
mintho carmo

Citation:

Envoyé par Ehonn

Par défaut, je "déconseille" son utilisation et demande de bien identifier qui est responsable de la durée de vie de l'objet à l'instant t dans la vie du programme et pas dans les éventuelles améliorations / évolutions qui ne seront probablement jamais faites. (C'est plus facile de passer d'un unique_ptr à un shared_ptr que l'inverse.)

Dans ce que j'explique, je considère bien le cas où il n'y a qu'un seul responsable de la durée de vie d'un objet.

Je ne parle pas de ne pas définir clairement qui est responsable de la durée de vie ou d'utiliser des shared_ptr pour ne pas avoir à réfléchir sur cette problématique. On est bien d'accord que d'utiliser par défaut shared_ptr pour éviter d'avoir à réfléchir au design est une très mauvaise approche.

Je parle d'avoir un propriétaire unique (1 seul shared_ptr permanent - donc un seul responsable de la durée de vie) et plusieurs observateurs (plusieurs weak_ptr, qui ne sont pas responsable de la durée de vie de l'objet, mais peuvent devenir temporairement propriétaire - ie le temps d'utiliser cette ressource)
17/09/2014, 14h08
koala01
Citation:
Envoyé par mintho carmo

Je trouve que ces 2 derniers points sont incomplets.

A mon avis :

un seul propriétaire et un seul observateur (le propriétaire) ==> unique_ptr
plusieurs propriétaire OU pluisuers observateur ==> shared_ptr

Par défaut, on doit considérer que l'on est en multithreads (soit parce que c'est effectivement le cas, soit parce que rien n'interdit dans le design que ça ne sera pas le cas dans le futur). Dans cette situation, avec unique_ptr, pour avoir un observateur, on peut passer :

par un pointeur nu ==> impossible de vérifier si l'objet est détruit ou non
une référence ou un équivalent de weak_ptr ==> impossible de garantir que l'objet n'est pas détruit entre le moment où l'on teste la validité de l'objet et le moment où on l'utilise

Dans les 2 cas, le design est problématique

Le seul moyen sécurisé d'avoir plusieurs observateurs est d'utiliser shared_ptr/weak_ptr. Le premier est utilisé pour avoir plusieurs propriétaire de la ressource (situation qui devrait reste rare), le second pour avoir plusieurs observateurs sur la ressource. Lorsqu'un observateur souhaite utiliser la ressource, il doit localement promouvoir le weak_ptr en shared_ptr (et dans ce cas, le shared_ptr est détruit à la fin du bloc, l'observateur est juste un propriétaire temporaire)

Donc à mon sens, le cas 4 correspond à unique_ptr si pas d'autre observateur que le propriétaire ou shared_ptr/weak_ptr s'il y a plusieurs observateurs
Hé bien, je ne suis pas du tout d'accord avec ton raisonnement...

A partir du moment où tu as déterminé qui était le seul responsable de la durée de vie de tes objets, tu veilles simplement à ce qu'il s'occupe de cette gestion en dehors de tout thread enfant (ou plutôt, au niveau du thread principal), et point-barre.

Si d'autres threads ont besoin de manipuler ces objets, tu le transmets par référence ( *(myUniqu.get() ), de préférence constante ou tu indique clairement dans les spécifications qu'il ne faut jamais faire un delete sur un pointeur nu (car la durée de vie de l'objet pointé est gérée par ailleurs grâce à une capsule RAII).

Finalement, la capsule RAII n'a qu'un seul et unique objectif : s'assurer que l'objet pointé est correctement détruit avant de perdre toute référence dessus. Rien n'empêche de récupérer un pointeur nu lorsque tu as affaire à une fonction et / ou à un thread qui n'a pas le droit à la parole en ce qui concerne la destruction de l'objet ;)
17/09/2014, 14h32
mintho carmo
Citation:

Envoyé par koala01

Hé bien, je ne suis pas du tout d'accord avec ton raisonnement...

A partir du moment où tu as déterminé qui était le seul responsable de la durée de vie de tes objets, tu veilles simplement à ce qu'il s'occupe de cette gestion en dehors de tout thread enfant (ou plutôt, au niveau du thread principal), et point-barre.

Si d'autres threads ont besoin de manipuler ces objets, tu le transmets par référence ( *(myUniqu.get() ), de préférence constante ou tu indique clairement dans les spécifications qu'il ne faut jamais faire un delete sur un pointeur nu (car la durée de vie de l'objet pointé est gérée par ailleurs grâce à une capsule RAII).

Finalement, la capsule RAII n'a qu'un seul et unique objectif : s'assurer que l'objet pointé est correctement détruit avant de perdre toute référence dessus. Rien n'empêche de récupérer un pointeur nu lorsque tu as affaire à une fonction et / ou à un thread qui n'a pas le droit à la parole en ce qui concerne la destruction de l'objet ;)

Par référence ou pointeur, la problématique est la même (et de toute façon, un observateur n'a jamais le droit de faire un delete, sinon ce n'est plus un observateur, mais un propriétaire) : rien ne permet de savoir au propriétaire que la ressource est encore utilisée ou non par un observateur.
Code:

1 2 3 4 5 6 7 8 void use_ressource(Ressource* p) { // ou & ou const& // use p } std::unique_ptr<Ressource> p = make_ressource(); std::thread t(ressource, p.get()); // quand détruire la ressource ?
On en revient à ce que je disais à Médinoc : si la durée de vie des ressources est supérieure à celle des threads, pas de problème. Mais dans le cas général (c'est pas une situation exception, on peut par exemple considérer un thread graphique qui affichent des ressources gérées par un moteur de rendu), on a un problème de sécurité

Une fonction ou un thread qui ont accès à une ressource ont forcement leur mot à dire concernant la destruction de cette ressource, même s'ils ne sont pas propriétaire de cette ressource (ie pas resposable de la détruire). Tout simplement parce que s'ils ont accès à une ressource, c'est bien pour l'utiliser à un moment donné et qu'il faut bien que la ressource ne soit pas libérée lorsqu'ils l'utiliseront
17/09/2014, 14h41
ternel

C'est là que le propriétaire est prié de faire attention.
S'il y a observateur, il y a observé.

Le propriétaire du pointeur sait quand un observateur commence à regarder, et ne dois pas libérer avant.
Par contre, ça veut aussi dire que l'observateur doit signaler qu'il a fini de regarder.

L'avantage d'une référence sur un pointeur nu, c'est que non seulement l'observateur n'aura pas le droit moral de faire un delete, mais n'en aura pas non plus la possibilité.

Sauf à être ultra crade delete(&reference), mais on ne peut ps coder contre un tel développeur..
17/09/2014, 14h46
mintho carmo

Citation:

Envoyé par leternel

Le propriétaire du pointeur sait quand un observateur commence à regarder, et ne dois pas libérer avant.
Par contre, ça veut aussi dire que l'observateur doit signaler qu'il a fini de regarder.

Ce qui revient à faire un compteur de référence, donc shared_ptr...

Pour le delete, comme je l'ai déjà dit, le problème n'est pas que l'observateur fasse un delete (ça ne serait plus un observateur), mais que le propriétaire fasse un delete alors qu'un observateur utilise la ressource (sauf à faire un compteur de référence)

Salut, j'utilise en effet un contexte multi-thread, et il ne faut pas que les ressources soient libérée avant que l'observateur (qui est le composant de rendu de la scene dans mon cas) ai fini de les utiliser.

Donc si je comprends bien je n'ai pas trop le choix je devrais utiliser un shared_ptr dans ce cas là.

Bref jusqu'à maintenant, j'ai utilisé un pointeur nu mais que je pense changé en std::unique_ptr dans mon std::vector et lorsque je quitte l'application, j'utilise une variable de condition qui attends que l'observateur aie fini d'afficher la scene, avant que le thread principal (le main) libère les ressources.
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 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 #ifndef ODFAEG_ENTITY_SYSTEM_HPP #define ODFAEG_ENTITY_SYSTEM_HPP #include <condition_variable> #include <mutex> #include <thread> #include "export.hpp" /** *\namespace odfaeg * the namespace of the Opensource Development Framework Adapted for Every Games. */ namespace odfaeg { /** * \file entitySystem.h * \class EntitiesSystem * \brief base class of all entities systems of the odfaeg. * \author Duroisin.L * \version 1.0 * \date 1/02/2014 */ class ODFAEG_CORE_API EntitySystem { public : /** *\fn EntitySystem () *\brief constructor. */ EntitySystem () : needToUpdate(false) { running = false; g_notified = true; } /** *\fn void launch() *\brief launch the thread to update every entities of the entity system. */ void launch () { running = true; m_thread = std::thread (&EntitySystem::run, this); } /** *\fn void update() *\brief function called when we need to update the entities, this function block the current thread until it's finished. */ void update () { g_notified = false; needToUpdate = true; g_signal.notify_one(); std::unique_lock<std::mutex> locker (g_lock_update); g_signal.wait(locker, [&](){return g_notified;}); } /** *\fn void run() *\brief this function block this thread until we need to update the entities by calling the update function. * or if we want to stop the thread. */ void run () { while (running) { std::unique_lock<std::mutex> locker(g_lock_update); g_signal.wait(locker, [&](){return needToUpdate || !running;}); onUpdate(); g_notified = true; needToUpdate = false; g_signal.notify_one(); } } /** *\fn bool isRunning() *\brief tells is the thread is running. *\return true if the thread is running. */ bool isRunning () { return running; } /** *\fn void stop() *\brief stop this thread. */ void stop () { running = false; g_signal.notify_one(); } /** *\fn void onUpdate() *\brief function to refefines to updates the entities. */ virtual void onUpdate() = 0; private : std::thread m_thread; /**< an internal thread which updates the entities*/ bool running, needToUpdate, g_notified; /**< tells if the thread is running, if the entities need to be update by the thread, and, if the thread have finished to update the entities.*/ std::condition_variable g_signal; /**<condition variable used for the primitive synchronisation of the thread.*/ std::mutex g_lock_update; /**<mutex used in the condition variable to avoid concurrent access to a variable between different threads*/ }; } #endif // ENTITY_SYSTEM
Tant que l'observateur n'a pas fini de mettre la scene à jour (pendant ou bien lors de l'arrêt de l'application c'est à dire lorsque je mets running à false), le thread principal est bloqué et ne peux pas libérer les ressources.

Donc, je crois que dans ce cas là je peux m'en sortir avec un std::unique_ptr, il y a malheureusement un cas ou je n'ai pas le choix et ou je dois utiliser un std::shared_ptr.

C'est lorsque par exemple, j'ai un bsp tree ou chaque noeud est une action. (mais ça pourrait être autre chose)
Je suis obligé d'utiliser un pointeur pour les feuilles du bsp tree dans le .h vu que j'ai pas la définition complète de la classe dans la classe elle même, et je veux lier ces actions à plusieurs BSP-TREE.
De plus les feuilles du BSP-TREE peuvent être nulle si ce n'est pas une action combinée, donc, raison de plus d'utiliser un pointeur. (std::shared_ptr ou std::unique_ptr)

Si je fais un std::unique_ptr pour les feuilles du BSP-TREE, le problème est que les actions seront invalide si je veux les utiliser dans un autre BSP-TREE car elles seront déplacée dans les feuilles du premier BSP-TREE.

Et cette classe n'est pas copiable donc je ne peux pas copier mes actions en les passant dans le constructeur du BSP-TREE et en faisant une allocation dynamique dans le constructeur du BSP-TREE. (C'est une classe à sémantique d'entité) donc je suis obligé de faire un déplacement ou un partage de pointeur.

Et comme le BSP-TREE ne peut pas devenir propriétaire d'une action, je suis obligé d'utiliser un std::shared_ptr!

Ou bien alors, je dois rendre la classe Action copiable mais je pense pas que ça soit une bonne idée.

C'est le seul cas ou je suis obligé d'utilisé un std::shared_ptr dans mon code, dans tout les autres cas je peux utilisé un std::unique_ptr et je pourrais, je pense, très bien me passer du std::shared_ptr.

18/09/2014, 19h33
Flob90

Je n'ai pas tous compris à mon message, mais un truc me choque un peu : j'ai l'impression que tu as pensé l'implémentation interne de ton arbre en prenant en compte l'ensemble du problème. Alors que la base de la conception c'est justement de découper la problématique avant de concevoir. Je ne vois pas pourquoi le fait qu'il y est au final plusieurs arbre se partageant des objets influent l'implémentation de l'arbre. Je fais mon arbre sans tenir compte de ce point, ensuite à l'utilisation je passe par une capsule si j'ai besoin d'ajouter une notion de partage.

Bon bah j'ai redéfini le constructeur de copie et l'opérateur d'affectation. (Avec std::shared_ptr je ne devais pas car la classe std::shared_ptr est copiable, tandit que std::unique_ptr ne l'est pas vu que dans la logique on utilise std::unique_ptr pour faire un déplacement et pas une copie.)

Voila donc ce que j'ai fais :

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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
 
#include "../../../include/odfaeg/Core/action.h"
#include "../../../include/odfaeg/Core/actionMap.h"
using namespace std;
namespace odfaeg {
Action::Action (EVENT_TYPE type) : type(type) {
    leaf = true;
    pressed = false;
    switch (type) {
        case CLOSED :
            startEvent.type = sf::Event::Closed;
            break;
        case RESIZED :
            startEvent.type = sf::Event::Resized;
            break;
        case LOST_FOCUS :
            startEvent.type = sf::Event::LostFocus;
            break;
        case GAIGNED_FOCUS :
            startEvent.type = sf::Event::GainedFocus;
            break;
        case TEXT_ENTERED :
            startEvent.type = sf::Event::TextEntered;
            break;
        case MOUSE_WHEEL_MOVED :
            startEvent.type = sf::Event::MouseWheelMoved;
            break;
        case MOUSE_MOVED :
            startEvent.type = sf::Event::MouseMoved;
            break;
        case MOUSE_ENTERED :
            startEvent.type = sf::Event::MouseEntered;
            break;
        case MOUSE_LEFT :
            startEvent.type = sf::Event::MouseEntered;
            break;
        case JOYSTICK_MOVED :
            startEvent.type = sf::Event::MouseLeft;
            break;
        case JOYSTICK_CONNECTED :
            startEvent.type = sf::Event::JoystickConnected;
            break;
        case JOYSTICK_DISCONNECTED :
            startEvent.type = sf::Event::JoystickDisconnected;
            break;
    }
    is_not = false;
}
Action::Action (EVENT_TYPE type, sf::Keyboard::Key key) : type(type) {
    leaf = true;
    pressed = false;
    switch (type) {
    case KEY_PRESSED_ONCE :
        startEvent.type = sf::Event::KeyPressed;
        startEvent.key.code = key;
        break;
    case KEY_HELD_DOWN :
        startEvent.type = sf::Event::KeyPressed;
        startEvent.key.code = key;
        break;
    case KEY_RELEASED :
        startEvent.type = sf::Event::KeyReleased;
        startEvent.key.code = key;
        break;
    }
    is_not = false;
}
Action::Action (EVENT_TYPE type, sf::Mouse::Button button) : type(type) {
    leaf = true;
    pressed = false;
    switch (type) {
        case MOUSE_BUTTON_PRESSED_ONCE :
            startEvent.type = sf::Event::MouseButtonPressed;
            startEvent.mouseButton.button = button;
            break;
        case MOUSE_BUTTON_HELD_DOWN :
            startEvent.type = sf::Event::MouseButtonPressed;
            startEvent.mouseButton.button = button;
            break;
        case MOUSE_BUTTON_RELEASED :
            startEvent.type = sf::Event::MouseButtonReleased;
            startEvent.mouseButton.button = button;
            break;
    }
    is_not = false;
}
Action::Action(const Action& other) {
    leaf = other.leaf;
    pressed = other.pressed;
    startEvent = other.startEvent;
    is_not = other.is_not;
    leftChild = std::make_unique<Action>(*other.leftChild);
    rightChild = std::make_unique<Action>(*other.rightChild);
    comparator = other.comparator;
    pressed = other.pressed;
    type = other.type;
}
/*Action (EVENT_TYPE type, sf::Joystick::Button button) : type(type) {
    cptype = NONE;
    switch (type) {
        case JOYSTICK_BUTTON_PRESSED_ONCE :
            startEvent.type = sf::Event::MouseButtonPressed;
            startEvent.joystickButton.button = button;
            break;
        case JOYSTICK_BUTTON_HELD_DOWN :
            startEvent.joystickButton.button = button;
            break;
        case JOYSTICK_BUTTON_RELEASED :
            startEvent.type = sf::Event::MouseButtonReleased;
            startEvent.joystickButton.button = button;
            break;
    }
}*/
bool Action::andComparator (std::unique_ptr<Action>& a1, std::unique_ptr<Action>& a2) {
    return a1->isTriggered() && a2->isTriggered();
}
bool Action::orComparator (std::unique_ptr<Action>& a1, std::unique_ptr<Action>& a2) {
    return a1->isTriggered() || a2->isTriggered();
}
bool Action::xorComparator (std::unique_ptr<Action>& a1, std::unique_ptr<Action>& a2) {
    return a1->isTriggered() | a2->isTriggered();
}
void Action::operator! () {
    if (!is_not)
        is_not = true;
    else
        is_not = false;
}
std::unique_ptr<Action> Action::operator| (Action &other) {
    std::unique_ptr<Action> result = std::make_unique<Action>(COMBINED_WITH_XOR, *this, other);
    return result;
}
std::unique_ptr<Action> Action::operator|| (Action &other) {
    std::unique_ptr<Action> result = std::make_unique<Action>(COMBINED_WITH_XOR, *this, other);
    return result;
}
std::unique_ptr<Action> Action::operator&& (Action &other) {
    std::unique_ptr<Action> result = std::make_unique<Action>(COMBINED_WITH_XOR, *this, other);
    return result;
}
bool Action::isTriggered () {
    vector<sf::Event> events = Command::getEvents();
    if (leaf) {
        if (type == KEY_HELD_DOWN && !is_not) {
            return sf::Keyboard::isKeyPressed(startEvent.key.code);
        }
        if (type == KEY_HELD_DOWN && is_not) {
            return !sf::Keyboard::isKeyPressed(startEvent.key.code);
        }
        if (type == MOUSE_BUTTON_HELD_DOWN && !is_not) {
            return sf::Mouse::isButtonPressed(startEvent.mouseButton.button);
        }
        if (type == MOUSE_BUTTON_HELD_DOWN && is_not) {
            return !sf::Mouse::isButtonPressed(startEvent.mouseButton.button);
        }
        /*else if (type == JOYSTICK_BUTTON_HELD_DOWN)
            return sf::Joystick::isButtonPressed(startEvent.joystickButton.button);*/
        for (unsigned int i = 0; i < events.size(); i++) {
            if (!is_not && !pressed) {
                return equalEvent(events[i], startEvent);
            } else if (is_not) {
                return !equalEvent(events[i], startEvent);
            } else {
                return false;
            }
        }
 
 
    } else {
        return comparator(std::ref(this->leftChild), std::ref(this->rightChild));
    }
}
Action::Action (EVENT_TYPE type, Action leftChild, Action rightChild)  {
    leaf = false;
    this->type = type;
    this->leftChild = std::make_unique<Action>(leftChild);
    this->rightChild = std::make_unique<Action>(rightChild);
    is_not = false;
    pressed = false;
    if (type == COMBINED_WITH_AND) {
        comparator = std::bind(&Action::andComparator, this, std::ref(this->leftChild), std::ref(this->rightChild));
    } else if (type == COMBINED_WITH_OR) {
        comparator = std::bind(&Action::orComparator, this, std::ref(this->leftChild), std::ref(this->rightChild));
    } else {
        comparator = std::bind(&Action::xorComparator, this, std::ref(this->leftChild), std::ref(this->rightChild));
    }
}
 
bool Action::equalEvent (sf::Event event, sf::Event other) {
    if (event.type != other.type)
        return false;
    if (event.type == sf::Event::Resized) {
        return event.size.width == other.size.width && event.size.height == other.size.height;
    }
    if (event.type == sf::Event::TextEntered) {
        return event.text.unicode == other.text.unicode;
    }
    if (event.type == sf::Event::KeyPressed || event.type == sf::Event::KeyReleased) {
        if (event.type == sf::Event::KeyPressed && event.key.code == other.key.code)
            pressed = true;
        return event.key.code == other.key.code;
    }
    if (event.type == sf::Event::MouseWheelMoved) {
        return event.mouseWheel.delta == other.mouseWheel.delta;
    }
    if (event.type == sf::Event::MouseButtonPressed || event.type == sf::Event::MouseButtonReleased) {
        if (event.type == sf::Event::MouseButtonPressed && event.mouseButton.button == other.mouseButton.button)
            pressed = true;
        return event.mouseButton.button == other.mouseButton.button;
    }
    if (event.type == sf::Event::MouseMoved) {
        return event.mouseMove.x == other.mouseMove.x && event.mouseMove.y == other.mouseMove.y;
    }
    if (event.type == sf::Event::JoystickButtonPressed || event.type == sf::Event::JoystickButtonReleased) {
        return event.joystickButton.joystickId == other.joystickButton.joystickId
            && event.joystickButton.button == other.joystickButton.button;
    }
    if (event.type == sf::Event::JoystickMoved) {
        return event.joystickMove.joystickId == other.joystickMove.joystickId
            && event.joystickMove.position == other.joystickMove.position;
    }
    return false;
}
void Action::setPressed(sf::Event event, bool pressed) {
    if (!leaf) {
        leftChild->setPressed(event, false);
        rightChild->setPressed(event, false);
    } else {
        if ((event.type == sf::Event::KeyReleased && startEvent.type == sf::Event::KeyPressed && event.key.code == startEvent.key.code) ||
            (event.type == sf::Event::MouseButtonReleased && startEvent.type == sf::Event::MouseButtonPressed && event.mouseButton.button == startEvent.mouseButton.button)) {
            this->pressed = pressed;
        }
    }
}
bool Action::containsEvent(sf::Event& event) {
    if (!leaf) {
        return leftChild->containsEvent(event) || rightChild->containsEvent(event);
    } else {
        return Command::equalEvent(event, startEvent);
    }
}
void Action::getEvents(std::vector<sf::Event>& events) {
    if (!leaf) {
        leftChild->getEvents(events);
        rightChild->getEvents(events);
    } else {
        events.push_back(startEvent);
    }
}
Action& Action::operator=(const Action& other) {
    leaf = other.leaf;
    pressed = other.pressed;
    startEvent = other.startEvent;
    is_not = other.is_not;
    leftChild = std::make_unique<Action>(*other.leftChild);
    rightChild = std::make_unique<Action>(*other.rightChild);
    comparator = other.comparator;
    pressed = other.pressed;
    type = other.type;
    return *this;
}
}

Je copie l'action et je la met dans un std::unique_ptr.

19/09/2014, 10h18
Bousk

Citation:

Envoyé par mintho carmo

Ce qui revient à faire un compteur de référence, donc shared_ptr...

Pour le delete, comme je l'ai déjà dit, le problème n'est pas que l'observateur fasse un delete (ça ne serait plus un observateur), mais que le propriétaire fasse un delete alors qu'un observateur utilise la ressource (sauf à faire un compteur de référence)

Ou bien juste faire une application intelligemment. Dans le parent qui lance le thread, tu attends que le 2° thread qu'il a lancé ait fini avant de détruire les ressources.
Vouloir prendre en compte "oui mais si un jour un utilisateur veut utiliser un 3° thread, oui mais si..." c'est bien, mais revenir sur terre sur son cas concret et y répondre c'est un bon début.
19/09/2014, 10h56
mintho carmo
Citation:

Envoyé par Bousk

Ou bien juste faire une application intelligemment. Dans le parent qui lance le thread, tu attends que le 2° thread qu'il a lancé ait fini avant de détruire les ressources.
Vouloir prendre en compte "oui mais si un jour un utilisateur veut utiliser un 3° thread, oui mais si..." c'est bien, mais revenir sur terre sur son cas concret et y répondre c'est un bon début.

L'aggressivité n'a jamais permit de renforcer une argumentation...

Quand tu lances un thread, tu as envie qu'il soit bloquant ? Si le thread travaille plusieurs minutes, il n'est pas question de faire un joint pour attendre qu'il ait fini avant de libérer la ressource

Et bien sûr que l'on va parler du "si un jour un utilisateur veut utiliser un 3° thread". J'ai donné un exemple de code minimaliste pour expliquer pourquoi le problème ne venait pas de l'observateur qui pourrait effacer la ressource, mais de savoir quand le propriétaire peut le faire. Avec un seul thread lancé, on est dans le cas d'un propriétaire unique, on peut transférer la responsabilité (par exemple, un thread pour la lecture et écriture de fichier, il n'aura plus besoin d'avoir la responsabilité des données lu, il pourra donner la propriété)

Dans une situation où l'on a plusieurs observateurs (avec ou sans plusieurs threads, le problème se posera pour le thread observateur si la ressource est partagée avec un thread et est utilisée dans la thread propriétaire), on devra partager la ressource et le coup du "tu attends que le 2° thread qu'il a lancé ait fini avant de détruire les ressources" sera encore plus problématique.
Code:

1 2 3 4 5 Ressource r; thread(use_ressource, &r); use_ressource2(r); // quand supprimer r ?
ou avec 2 threads
Code:

1 2 3 4 5 Ressource r; thread(use_ressource, &r thread(use_ressource2, &r); // quand supprimer r ?
Dans tous les cas, tu n'as pas forcement envie que l'appel des threads soit bloquant, tu ne sais pas quand tu peux supprimer la ressource

Un autre exemple classique, c'est une classe de rendu, qui garde des observateurs sur des ressources pour pouvoir les afficher et les utilises dans un thread interne (donc impossible de savoir pour le thread principal quand elles sont utilisées ou non). Bien sûr, le thread parent a besoin d'avoir accès aux ressources pour les mettre à jour. Lorsqu'il n'a plus besoin d'une ressource, il va demander sa détruction, mais celle-ci ne pourra pas être effective tant que le rendu en a encore besoin

C'est en fait une problématique classique et il y a pas mal de solution (sans sahred_ptr) qui ont été développé avec le temps. Mais au final, ces implémentations utilisent en interne un compteur de référence, ce qui est le boulot de shared_ptr (ou un simple bool s'il n'y a qu'un observateur, mais l'idée est la même)

L'idéal sera d'essayer de ne pas partager une ressource (surtout que cela pose des problèmes d'accès concurents), mais si on doit le faire, le couple unique_ptr + * (ou & ou weak_unique_ptr) sera une mauvaise solution à mon sens.
19/09/2014, 11h11
Ehonn

Citation:

Envoyé par mintho carmo

L'idéal sera d'essayer de ne pas partager une ressource (surtout que cela pose des problèmes d'accès concurents), mais si on doit le faire, le couple unique_ptr + * (ou & ou weak_unique_ptr) sera une mauvaise solution à mon sens.

... car on a identifier que la ressource pouvait être détruite par l'unique_ptr pendant que l'observateur l'utilisait.
C'est probablement l'utilisation du mot observer pour un shared_ptr qui me gène un peu, mais avec l'explication c'est plus clair :)

Mwai non même sans les std::unique_ptr je me retrouve toujours avec ce crash ici :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Action& Action::operator| (Action &other) {
    std::unique_ptr<Action> result = std::make_unique<Action>(COMBINED_WITH_XOR, *this, other);
    return *result;
}
Action& Action::operator|| (Action &other) {
    std::unique_ptr<Action> result = std::make_unique<Action>(COMBINED_WITH_XOR, *this, other);
    return *result;
}
Action& Action::operator&& (Action &other) {
    std::unique_ptr<Action> result = std::make_unique<Action>(COMBINED_WITH_XOR, *this, other);
    return *result;
}

Et c'est depuis que j'utilise gcc4.9 on dirait.

19/09/2014, 14h25
Ehonn
Citation:
Envoyé par Lolilolight

Code:

1 2 3 4 5 Action& Action::operator| (Action &other) { std::unique_ptr<Action> result = std::make_unique<Action>(COMBINED_WITH_XOR, *this, other); return *result; }
Ça n'a pas de sens de retourner une référence sur l'objet tenu par unique_ptr, retourne directement l'unique_ptr pour le déplacer. À la fin du bloc, ton unique_ptr est détruit et ta référence est invalide.
19/09/2014, 17h24
Bousk
Citation:

Envoyé par mintho carmo

Quand tu lances un thread, tu as envie qu'il soit bloquant ? Si le thread travaille plusieurs minutes, il n'est pas question de faire un joint pour attendre qu'il ait fini avant de libérer la ressource
Code:

1 2 3 4 5 6 7 8 9 10 11 12 int main() { Thread m1; Thread m2; m1.FaitSaVie(); m2.FaitSaVie(); while (run) { // l'application fait aussi sa vie } m1.join(); m2.join(); // tu supprimes sans aucun risque }
Ca relève pas du défi amha. :roll:
19/09/2014, 18h04
mintho carmo

Citation:

Envoyé par Bousk

Ca relève pas du défi amha. :roll:

Oui, sur un cas aussi simple que des ressrouces allouées au lancement de l'application et libéré à la fin, on trouvera des solutions. On pourra aussi faire la remarque que si le thread alloue lui aussi des ressources, cela impose qu'il ne sera pas détruit (et donc libérera ses propres ressources internes) avant la fin du problème. Et pour ce problème aussi on pourra trouver des solutions.

On utilise des ressources et des threads bien avant l'apparition de shared_ptr/weak_ptr.

Mon propos était surtout de soulever une problématique posée par unique_ptr/* (ou & ou weak_unique_ptr) et que shared_ptr/weak_ptr peut être une solution intéressante (que perso je conseille en premier par rapport à la première solution dans le cas de plusieurs observateurs). Maintenant, si tu préfères une solution n'utilisant pas shared_ptr, que tu as vérifié que ta solution ne présente pas la problématique que j'ai essayé d'expliquer, c'est très bien. C'est ton code, c'est toi qui décide de la solution
19/09/2014, 20h40
Invité
Mmmm, j'ai changé mon code et maintenant il utilise des std::unique_ptr.

Mon framework initialise tout au début de l'application et libère tout à la fin de l'application donc, il n'y a pas de problème, même lors de l'utilisation de plusieurs thread.

Cependant, je trouve ça moche de forcer l'utilisateur de la bibliothèque à devoir faire cela au cas ou la classe deviendrait propriétaire :
Code:

1 2 InputSystem::getListener().connect("A command", std::move(command));
Ou bien avec les pointeurs, forcer l'utilisateur à devoir faire un std::make_unique ou un std::make_shared.

J'aimerais bien me passer du std::move lors de l'utilisation de la bibliothèque mais apparemment la seule solution qui marche vraiment pour faire ça c'est du perfect forwarding avec des templates.
Donc bon finalement j'ai fais à chaque fois une copie que je passe à std::make si c'est un pointeur ou à la variable membre si ce n'est pas un pointeur.