IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Boost C++ Discussion :

Puis-je utiliser un weak_ptr ici


Sujet :

Boost C++

  1. #1
    Membre très actif
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    688
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 688
    Par défaut Puis-je utiliser un weak_ptr ici
    Salut,

    dans quel cas utilize vous weak_ptr ?

    est ce cas que le cas suivant est un bon candidat :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    class Main
    {
    Module m;
    }
     
    class Module
    {
    weak_ptr<Main> parent; //shared_ptr plutot ?
    }
    Merci

  2. #2
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Par défaut
    Salut,
    Un shared ptr est un pointeur dont la durée de vie est partagée entre différents objets.
    Un weak ptr est utilisé lorsqu'on ne veut pas interférer avec la durée de vie du pointeur mais juste pouvoir l'utiliser au besoin (et s'il existe).
    Les responsabilités sont différentes : dans un cas, la gestion de la ressource est partagée (shared ptr), dans l'autre non (celui qui a un weak ptr ne gère pas la ressource et peut donc la perdre). Choisir l'un ou l'autre dépend donc de ce critère : partage de sa gestion ou non.
    Et il y a les scopped ptr dont la responsabilité est attribuée une fois et n'est pas partagée.
    Cf le tuto de Loïc Joly sur les pointeurs intelligents.

    Dans ton cas, outre que les cycles peuvent relever d'un problème de design, ça ressemble à une composition entre Main et Module. La durée de vie de m est identique à celle de l'objet Main qui le possède. J'ai l'impression que Module devrait avoir non pas un pointeur mais une référence vers Main, référence initialisée à la construction :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    class Main
    {
    Module m;
    }
     
    class Module
    {
    Module(Main &parent_):parent(parent_){}
    Main& parent; //shared_ptr plutot ?
    }
    La référence traduit cette dépendance de façon encore plus forte que le pointeur (quelque soit son intelligence).

  3. #3
    Membre très actif
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    688
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 688
    Par défaut
    Citation Envoyé par 3DArchi Voir le message

    Dans ton cas, outre que les cycles peuvent relever d'un problème de design, ça ressemble à une composition entre Main et Module.
    Pour le pbm de design , ce que j'ai voulu éclater une grosse classe en 1 classe et 5 modules .

    POur la référence j'y avais pensé mais je shoutais éviter d'avoir à inclure un point .h dans le .h en passant par un pointeur je peux me servir de la forward declaration "class Module.h"

  4. #4
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Par défaut
    Avec une référence tu peux utiliser une déclaration anticipé dans les headers. C'est comme pour un pointeur.

  5. #5
    Membre très actif
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    688
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 688
    Par défaut
    Citation Envoyé par 3DArchi Voir le message

    Dans ton cas, outre que les cycles peuvent relever d'un problème de design, ça ressemble à une composition entre Main et Module.
    Pour le pbm de design , ce que j'ai voulu éclater une grosse classe en 1 classe et 5 modules .

    POur la référence j'y avais pensé mais je souhaitais éviter d'avoir à inclure un point .h dans le .h. En passant par un pointeur je peux me servir de la forward declaration "class Module;"

  6. #6
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Par défaut
    POur la référence j'y avais pensé mais je souhaitais éviter d'avoir à inclure un point .h dans le .h. En passant par un pointeur je peux me servir de la forward declaration "class Module;"
    Citation Envoyé par 3DArchi Voir le message
    Avec une référence tu peux utiliser une déclaration anticipé dans les headers. C'est comme pour un pointeur.
    Citation Envoyé par guillaume07 Voir le message
    Pour le pbm de design , ce que j'ai voulu éclater une grosse classe en 1 classe et 5 modules .
    Une 'grosse' classe est effectivement une classe avec trop de responsabilités. Les identifier et les réorganiser dans des classes dédiées est une bonne idée. Mais est-ce que les composants ont vraiment besoin de connaître le conteneur ?

  7. #7
    Membre très actif
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    688
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 688
    Par défaut
    Citation Envoyé par 3DArchi Voir le message
    Une 'grosse' classe est effectivement une classe avec trop de responsabilités. Les identifier et les réorganiser dans des classes dédiées est une bonne idée. Mais est-ce que les composants ont vraiment besoin de connaître le conteneur ?
    disons que chacun module peut avoir besoin d'une méthode ou attribut d'un autre module

    mes modules :

    param ( contient le nom , l'id etc du conteneur )
    file ( gère les enreg dans un fichier lecture etc)
    engine ( effectue tout les calculs )
    stat ( calcul et tiens à jour toutes les stats résultant des calculs )


    donc sauf cas spécifique comme le module stat qui se fou du module file, à priori tous les modules peuvent avoir à communiquer ensemble

    et chaque module est déclaré amie de la classe Conteneur

  8. #8
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Par défaut
    Généralement, si tout dépend de tout, c'est qu'il y a un problème au niveau du découpage. L'idéal en terme d'une répartition, c'est que si tu traces le graphe de dépendance entre tes modules, ce graphes soit acyclique, sans dépendance circulaire. Comment le faire ? Difficile à dire dans l'abstrait. Parfois en regroupant deux modules, parfois en en créant un nouveau qui supporte des fonctions de bas niveau, parfois en déplaçant quelque chose d'un module à un autre...

    Note que je parles bien de module (chose conceptuelles, n'ayant pas vraiment de représentation physique dans le code), et non de classes. Ce n'est pas si gênant d'avoir des dépendances cycliques entre classes, tant que ces classes font partie d'un même module (exemple : Un conteneur et ses itérateurs)
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  9. #9
    Membre très actif
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    688
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 688
    Par défaut
    Citation Envoyé par JolyLoic Voir le message
    Généralement, si tout dépend de tout, c'est qu'il y a un problème au niveau du découpage. L'idéal en terme d'une répartition, c'est que si tu traces le graphe de dépendance entre tes modules, ce graphes soit acyclique, sans dépendance circulaire. Comment le faire ? Difficile à dire dans l'abstrait. Parfois en regroupant deux modules, parfois en en créant un nouveau qui supporte des fonctions de bas niveau, parfois en déplaçant quelque chose d'un module à un autre...

    Note que je parles bien de module (chose conceptuelles, n'ayant pas vraiment de représentation physique dans le code), et non de classes. Ce n'est pas si gênant d'avoir des dépendances cycliques entre classes, tant que ces classes font partie d'un même module (exemple : Un conteneur et ses itérateurs)
    "ce graphes soit acyclique, sans dépendance circulaire"

    c'est à peu près le cas oui

  10. #10
    Membre très actif
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    688
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 688
    Par défaut
    Citation Envoyé par 3DArchi Voir le message
    Salut,
    Un shared ptr est un pointeur dont la durée de vie est partagée entre différents objets.
    Un weak ptr est utilisé lorsqu'on ne veut pas interférer avec la durée de vie du pointeur mais juste pouvoir l'utiliser au besoin (et s'il existe).
    Les responsabilités sont différentes : dans un cas, la gestion de la ressource est partagée (shared ptr), dans l'autre non (celui qui a un weak ptr ne gère pas la ressource et peut donc la perdre). Choisir l'un ou l'autre dépend donc de ce critère : partage de sa gestion ou non.
    Et il y a les scopped ptr dont la responsabilité est attribuée une fois et n'est pas partagée.
    Cf le tuto de Loïc Joly sur les pointeurs intelligents.

    Dans ton cas, outre que les cycles peuvent relever d'un problème de design, ça ressemble à une composition entre Main et Module. La durée de vie de m est identique à celle de l'objet Main qui le possède. J'ai l'impression que Module devrait avoir non pas un pointeur mais une référence vers Main, référence initialisée à la construction :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    class Main
    {
    Module m;
    }
     
    class Module
    {
    Module(Main &parent_):parent(parent_){}
    Main& parent; //shared_ptr plutot ?
    }
    La référence traduit cette dépendance de façon encore plus forte que le pointeur (quelque soit son intelligence).
    le truc c'est que ems classes utilisent boost::serialization est à ce titre doivent comporter un constructeur par défault et de ce fait je doute que je puisse utiliser une reference plutto qu'un pointeur car sur quoi pointerai la référence ?

  11. #11
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Par défaut
    Effectivement. Il y aurait bien la possibilité d'utiliser Boost.Optional pour wrapper ta référence mais je ne sais pas si cela s'articule bien avec la sérialisation. Reste donc le weak_ptr.

  12. #12
    Membre éclairé
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    301
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 301
    Par défaut
    le truc c'est que ems classes utilisent boost::serialization est à ce titre doivent comporter un constructeur par défault et de ce fait je doute que je puisse utiliser une reference plutto qu'un pointeur car sur quoi pointerai la référence ?
    boost::serialization ne t'oblige absolument pas à avoir une classe défaut constructible: cf http://www.boost.org/doc/libs/1_43_0...l#constructors

  13. #13
    Membre très actif
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    688
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 688
    Par défaut
    ok merci, j'étais resté sur boost 1.36

Discussions similaires

  1. Windows Live Writer - puis l'utiliser avec mon blog ?
    Par DonJR dans le forum Autres Logiciels
    Réponses: 2
    Dernier message: 16/12/2006, 19h23
  2. Réponses: 1
    Dernier message: 30/11/2006, 10h59
  3. [UBUNTU] Puis-je utiliser la documentation de Debian
    Par JavaAcro dans le forum Ubuntu
    Réponses: 11
    Dernier message: 27/11/2006, 23h01
  4. [3D]Moteur de raytracing sans les bibliothèques type DirectX, que puis-je utiliser?
    Par cladsam dans le forum Développement 2D, 3D et Jeux
    Réponses: 8
    Dernier message: 21/04/2006, 17h28
  5. [Info] Quels outils de develpt puis-je utiliser pour pocketpc
    Par chris69000 dans le forum Développement Mobile en Java
    Réponses: 2
    Dernier message: 22/06/2004, 10h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo