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

Livres C++ Discussion :

Erreur dans le livre Mieux programmer en C++?


Sujet :

Livres C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre du Club
    Homme Profil pro
    Inscrit en
    Février 2012
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Février 2012
    Messages : 7
    Par défaut Erreur dans le livre Mieux programmer en C++?
    Bonjour,

    J'ai été assez étonné de lire dans le livre "Mieux programmer en C++" a la page 30:

    http://dut.proced90.com/Documentatio...20en%20c++.pdf

    2.
    Il n’y a pas de risque de fuites mémoires.
    Détaillons en effet ce qui se passe en cas
    de génération d’exception : si l’opérateur
    new()
    lance une exception
    bad_alloc
    , comme
    le tableau d’objets
    T
    n’a pas encore été alloué, il n’y a donc pas de risque de fuite ; si la
    construction d’un des objets
    T
    alloué échoue, le destructeur de
    Stack
    est automatique-
    ment appelé (du fait qu’une exception a été générée au cours de l’exécution de
    Stack::Stack
    ), ce qui a pour effet d’exécuter l’instruction
    delete[]
    , laquelle effectue
    correctement la destruction et la désallocation des objets
    T
    ayant déjà été alloués.
    Hors lorsqu'une exception est lancé dans un constructeur l'objet n'est pas construit et le destucteur ne peu pas être appelé...
    Je ne comprend pas ce que l'auteur a voulu dire?

  2. #2
    Membre Expert
    Homme Profil pro
    Inscrit en
    Décembre 2010
    Messages
    734
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 734
    Par défaut
    Il me semble que quand une exception est lancée au cours d'un constructeur, les membres dont le constructeur est déjà appelé ont leur destructeur appelé (dans l'ordre inverse des constructeurs).
    Par contre, concernant l'allocation dynamique, il faut gérer soit-même vu qu'en effet le destructeur n'est pas appelé
    c'est décrit dans la FAQ ici.

  3. #3
    Membre Expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Par défaut
    Oui il ne faut pas oublier que si un objet est construit, alors son destructeur sera appele, meme si c'est un objet membre d'un autre objet!

    Donc en gros

    class K
    {
    A a;
    B b;
    C c;
    K() { throw 42; }
    };



    Au moment du throw, a b et c sont construits donc ils seront deconstruits. C'est K qui n'est pas construit au moment du throw. Si a ou b ou c a alloue quelque chose, il sera desalloue.

  4. #4
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 635
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 635
    Par défaut
    Salut,

    En gros, il faut savoir que le risque de fuite de mémoire survient lorsqu'on a recours à l'allocation dynamique de celle-ci.

    Lorsque tu déclares un membre par valeur (pour vsize_ ou pour vused_ dans l'exemple), il n'y a strictement aucune raison qu'une exception ne soit lancée.

    Le seul moment où il y a effectivement un risque qu'une exception soit lancée survient au moment du
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     v_ = new T[vsize_]; // Allocation initiale
    il y aura alors une exception de type std::bad_alloc qui sera lancée, si et uniquement si... l'allocation dynamique de la mémoire échoue.

    Tel que le code est présenté, il n'y aurait donc en effet strictement aucun risque de fuite mémoire, parce qu'il n'y a aucune raison d'invoquer un delete sur le résultat d'une allocation dynamique qui a échoué

    Par contre, là où tu aurais un grand risque de fuite mémoire, c'est si le constructeur venait à faire plus d'une allocation dynamique.

    Par exemple, une classe proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    class MaClass{
        public:
            MaClass(int i, int j):i(i),j(j){
                 first = new int[i]; // peut échouer!!!(*)
                 second = new int[j]; // peut aussi échouer!!!(**)
           }
        private:
            int i;
            int j;
            int * first;
            int * second;
    }
    Ou, pire encore une classe proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    class Matrix{
        public:
            Matrix(int lines, int columns):lines(lines),columns(columns){
                 data = new int *[lines]; // peut échouer (*)
                 for(int i = 0;i<lines;++i){
                     data[i]=new int[columns]; //peut aussi échouer (à chaque passage 
                                               // dans la boucle!!!) (**)
                 }
            }
        private:
            int lines;
            int columns;
            int ** data;
    };
    vont potentiellement poser problème.

    Non pas au moment de la première allocation de mémoire (*) car, si elle échoue, l'exception bad_alloc est lancée, et, comme il n'y a pas eu d'allocation dynamique avant, il n'y a rien qui nécessite le recours à delete ou à delete[], mais bien au niveau de la deuxième allocation dynamique (**):

    En effet, si la deuxième allocation dynamique (**) échoue, il faut, avant de quitter le constructeur, veiller à libérer le résultat de la première (*), voir (dans le cas de la classe Matrix ) de toutes les exécutions de la boucles pour lesquelles l'allocation dynamique a réussi avant qu'une (qui peut etre tout aussi bien la première que la dernière... ou n'importe laquelle entre les deux ) ne vienne à rater, sans oublier, toujours, de libérer le résultat de la première(*)

    Enfin, bref, pour arriver à gérer correctement tous les cas, cela devient beaucoup plus compliqué
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  5. #5
    Membre Expert
    Homme Profil pro
    Inscrit en
    Décembre 2010
    Messages
    734
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 734
    Par défaut
    Je suppose qu'on peut solutionner une partie du problème (une fois qu'on a envisagé les solutions pour restreindre l'allocation dynamique) en wrappant les pointeurs individuels dans des smart pointers, et les objets créés en masse dans des containers, ou le cas échéant dans des containers de smart-pointers?
    Dans ce cas on se ramène à des membres déclarés par valeur

  6. #6
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 394
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

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

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 394
    Par défaut
    En effet. Tant que la classe ne gère pas manuellement la durée de vie de ces ressources, elle devrait être exception-safe.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  7. #7
    Membre du Club
    Homme Profil pro
    Inscrit en
    Février 2012
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Février 2012
    Messages : 7
    Par défaut
    Effectivement alors lorsque l'allocation d'un tableau de classe avec new[] lance une exception std::bad_alloc les éléments déjà allouée du tableau sont libéré par la fonction new[]!

    Cependant le destructeur des éléments du tableau est appelé pour les éléments déjà construit mais pas le destructeur de la classe Stack!

    La fonction delete[] n'est au final jamais appelé dans l'exemple...

Discussions similaires

  1. Où en êtes-vous dans le livre "Apprenez à programmer en JAVA" ?
    Par mike1313 dans le forum Débuter avec Java
    Réponses: 6
    Dernier message: 20/07/2014, 14h19
  2. [Livre] Mieux programmer en Java - 68 astuces pour optimiser son code
    Par MarieKisSlaJoue dans le forum Général Java
    Réponses: 0
    Dernier message: 01/07/2014, 15h00
  3. Tri shell : erreur dans le livre bac info ?
    Par adel_info dans le forum Pascal
    Réponses: 13
    Dernier message: 12/11/2009, 09h43

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