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

 C++ Discussion :

déclaration des attributs


Sujet :

C++

  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Mars 2011
    Messages
    42
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2011
    Messages : 42
    Par défaut déclaration des attributs
    Bonjour,

    Je viens du C# et du C, je me pose une question sur le C++. Lorsqu’on déclare un attribut, quelle est la différence entre : Toto m_toto; et Toto &m_toto ?
    Le premier est par valeur et le second par référence ?
    Pourquoi doit-on obligatoirement initialiser Toto &m_toto dans le constructeur ?

    Même question pour Toto getToto() et Toto& getToto().

    Merci

    Bonne journée

  2. #2
    Membre chevronné
    Homme Profil pro
    Cadre informatique
    Inscrit en
    Avril 2013
    Messages
    183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Cadre informatique

    Informations forums :
    Inscription : Avril 2013
    Messages : 183
    Par défaut
    Toto m_toto et Toto &m_toto sont effectivement une valeur et une référence. Cependant, la référence est un nom supplémentaire que tu donnes à une variable. Elle te permet de ne pas faire de copie au passage d'une fonction et ainsi éviter une perte de temps assez grande lorsque tu manipules des données de grande taille.
    A ce qu'il me semble, tu n'es pas obliger de l'initialiser dans le constructeur. S'il te plait de mettre un constructeur avec un passage par valeur, cela ne change rien

  3. #3
    Membre Expert Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    Mai 2007
    Messages
    1 048
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2007
    Messages : 1 048
    Par défaut
    Bonjour,

    C'est exact, le premier est par copie et le second par référence.
    On DOIT initialiser une référence car c'est un alias, il ne peut référer à "rien". La référence permet contrairement au pointeur de ne pas permettre de passer 0/NULL/nullptr en paramètre par exemple, et de forcer à avoir une valeur correct dans ta variable.

    A ce qu'il me semble, tu n'es pas obliger de l'initialiser dans le constructeur
    Si tu est obliger d'initialiser ta référence dans le constructeur, une référence n'a pas d'état 0/NULL/nullptr et le compilateur t'obligera à lui trouver une valeur.

  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
    Citation Envoyé par xps1616 Voir le message
    Bonjour,

    Je viens du C# et du C, je me pose une question sur le C++. Lorsqu’on déclare un attribut, quelle est la différence entre : Toto m_toto; et Toto &m_toto ?
    Le premier est par valeur et le second par référence ?
    Pourquoi doit-on obligatoirement initialiser Toto &m_toto dans le constructeur ?
    En fait, tu dois meme initialiser la référence directement dans la liste d'initialisation, car, contrairement à un pointeur, une référence apporte une garantie d’existence de l'objet référencé (du moins, au moment de sa déclaration).

    En effet, en C++, une référence a, au niveau du code binaire généré, un comportement très similaire à celui d'un pointeur, mais, là où un pointeur peut valoir NULL (nullptr en C++11) et indiquer alors la "non existence" de l'objet pointé, une référence nous apporte la garantie que l'objet existe bel et bien.

    Pour que nous puissions avoir cette garantie, il est obligatoire d'indiquer l'objet référencé directement au niveau de la déclaration de la référence.

    Ainsi, un code proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    int main(){
    UnType obj ; // un objet de type UnType
    UnType & ref; // on tente de déclarer une référence sans indiquer l'objet
                  // auquel elle fait référence
    }
    sera purement et simplement refusé par le compilateur, pour la bonne raison... qu'il ne peut pas s'assurer de l'existence de l'objet référencé (vu qu'il n'y en a pas ) et qu'il ne peut donc pas apporter la garantie attendue de la part de la référence.

    Au niveau des classes et des structures, l'initialisation doit, comme je l'ai indiqué plus haut, se faire au niveau des listes d'initialisation
    Même question pour Toto getToto() et Toto& getToto().

    Merci

    Bonne journée
    Toto getToto va renvoyer une copie (pour autant que l'objet soit copiable) du membre en question.

    Cela implique que aucune des modifications que tu pourrais envisager de faire au niveau de l'élément renvoyé par cette fonction ne seront répercutée sur l'objet don toto est le membre.

    Allez, un petit exemple pour comprendre
    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 MyClass{
        public:
            MyClass(int tata):tata_(tata){}
            int getTata(){return tata_;}
        private:
            int tata_;
    };
    int main(){
        MyClass mc(12);
        std::cout<<mc.getTata() <<std::endl; // sortie : 12
        int truc = mc.getTata(); 
        truc++; // on aurait pu faire mc.getTata()++;
        std::cout<<mc.getTata() <<std::endl; // sortie : toujours 12
    }
    Toto & getToto va renvoyer une référence sur le membre en question.

    Cela signifie que toutes les modifications que tu pourrais faire au niveau de l'élément renvoyé seront répercutée vers le membre en question.

    Le meme exemple avec les référence nous donnera donc
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    class MyClass{
        public:
            MyClass(int tata):tata_(tata){}
            int & getTata(){return tata_;}
        private:
            int tata_;
    };
    int main(){
        MyClass mc(12);
        std::cout<<mc.getTata() <<std::endl; // sortie : 12
        mc.getTata()++;
        /* OU OU OU */
        int & t=mc.getTata();
        ++t;
        std::cout<<mc.getTata() <<std::endl; // sortie :13
    }
    Note toutefois qu'il est généralement (à quelques rares exceptions près) mal vu de permettre ce genre de comportement, parce que cela implique que l'utilisateur peut modifier l'état interne de ta classe en dehors de tout contrôle, et que ce sera donc à l'utilisateur de faire les vérifications "qui vont bien" avant de modifier la valeur, avec une série de risques inhérent à cette opportunité:
    1. L'utilisateur peut "oublier" de faire les vérifications d'usage et se retrouver avec un objet dans un état incohérent
    2. Les vérifications faites par l'utilisateur seront "ventilées" dans tout son code, ce qui rendra le débugage en cas de besoin particulièrement difficile
    3. Il y a sans doute d'autres raisons, mais ces deux là sont déjà suffisantes en elles-même

    La "bonne pratique" lorsqu'on décide de fournir un accesseur sur le membre d'une classe consiste
    1. A déclarer l'accesseur comme étant une fonction constante (comprends: qui s'engage à ne pas modifier l'objet courent), afin qu'il puisse, le cas échéant, être utilisé avec un objet que l'on a déclaré comme étant constant
    2. A déclarer la référence vers l'objet comme étant constante, afin que le compilateur refuse les éventuelles modifications de la référence renvoyée

    Au final, un "bon" accesseur devrait sans doute prendre une forme proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    class MyClass{
        public:
            UnType const & getTata() const{return tata_;}
        private:
            UnType tata_;
    };
    Notes enfin qu'il n'y a généralement pas d'intérêt à renvoyer une référence (qu'elle soit constante ou non) sur les types primitifs, et qu'il y a toujours intérêt, afin de respecter la loi de demeter, à s'inquiéter de savoir s'il est réellement intéressant de fournir un accesseur ou non... Mais ca, c'est un autre débat
    Citation Envoyé par Bysbobo Voir le message
    Toto m_toto et Toto &m_toto sont effectivement une valeur et une référence. Cependant, la référence est un nom supplémentaire que tu donnes à une variable. Elle te permet de ne pas faire de copie au passage d'une fonction et ainsi éviter une perte de temps assez grande lorsque tu manipules des données de grande taille.
    Ca, c'est tout à fait vrai, mais ce n'est qu'un des cas d'utilisation des références.

    Un autre cas d'utilisation des références est le cas où tu veux permettre à ta fonction (ou à ta classe) de modifier (en interne) un objet qui existe par ailleurs.

    Et le dernier cas d'utilisation des références concerne le principe substituabilité: lorsque tu veux manipuler des objets polymorphes (comprends: des objets intervenant dans une même hiérarchie de classes) en les manipulant comme s'ils étaient du type de base.

    Ces deux derniers cas sont (plus ou moins) régulièrement mis en oeuvre par utilisation de pointeurs, mais, il est tout à fait valide d'utiliser des références et beaucoup plus sécurisant (étant donné la garantie d'existence de l'objet apportée par la référence) dans ces buts
    A ce qu'il me semble, tu n'es pas obliger de l'initialiser dans le constructeur.
    Faux: si un membre est une référence vers un objet, tu as l'obligation de l'initialiser au niveau de la liste d'initialisation, autrement, le compilateur t'enverra paitre avec une erreur de compilation.
    S'il te plait de mettre un constructeur avec un passage par valeur, cela ne change rien
    Faux aussi.

    Le résultat dépendra essentiellement de la manière dont le membre est déclaré:
    Si le membre est une valeur, tu peux l'initialiser dans le constructeur au départ d'une valeur ou d'une référence.

    L'objet servant de paramètre lors de l'appel du constructeur sera alors copié (pour autant qu'il soit copiable) au niveau de la classe, avec, selon le cas, certaines élision de copie.

    Note que, si tu déclares le paramètre comme étant une référence constante, tu pourras également utiliser une variable temporaire non nommée lors de l'appel du constructeur, au même titre que lorsque l'argument est transmis par valeur.

    Si le membre est déclaré comme une référence (qu'elle soit constante ou non), tu ne peux pas déclarer l'argument autrement que comme une référence, sous peine d'observer des comportements indéfinis:
    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 MaClasse{
        public:
            MaClasse(UnType obj):obj_(obj) { // obligatoire vu que obj_ est une référence
            } //CRACK.... obj est détruit ici (obj_ référence un objet détruit :-S)
            UnType const & getObj() const{return obj_;}
       private:
            UnType & obj_;
    };
    int main(){
        UnType obj;
        MaClasse cl(obj); // CRAK: voir le construteur
        cl.getObj().someFunction(); // BOUM: l'objet référencé par cl::obj_ n'existe plus
                                    // l'appel à someFunction() provoquera une erreur de segmentation
    }
    Note d'ailleurs que, si le membre est une référence, il faudra prendre des précautions pour s'assurer que l'instance de ta classe ne survive jamais à l'objet qui est référencé, mais cela permettrait malgré tout d'avoir un comportement 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
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    class A{
        public:
           A(int i):i_(i){}
           int value() const{return i_;}
           void changeValue(int newVal){i_=newval;}
        private:
            int i_;
    };
    class MaClasse{
        public:
            MaClasse(UnType & obj):obj_(obj) { // obligatoire vu que obj_ est une référence
            } 
            void doSomething(){
                obj_.changeValue(obj_.value()*obj_.value());
            }
       private:
            A & obj_;
    };
    int main(){
        A a(3);
        std::cout<<a.value()<<std::endl; //sortie 3
        MaClass cl(a);
        cl.doSomething();
        std::cout<<a.value()<<std::endl; //sortie 9 (3 * 3), merci les références :D
    }
    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 averti
    Profil pro
    Inscrit en
    Mars 2011
    Messages
    42
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2011
    Messages : 42
    Par défaut
    Un grand merci pour toutes vos explications qui sont très claires

    Bonne soirée

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Problème dans la déclaration des attributs
    Par hazem2410 dans le forum C#
    Réponses: 3
    Dernier message: 02/12/2010, 08h28
  2. Réponses: 5
    Dernier message: 10/11/2004, 19h44
  3. Inhiber l'ordre alphabétique des attributs sous Xerces
    Par philippe rousseau dans le forum XML/XSL et SOAP
    Réponses: 3
    Dernier message: 04/12/2003, 17h19
  4. Sauvegarde des attributs de texte en fichier ini
    Par Raylemon dans le forum Langage
    Réponses: 2
    Dernier message: 06/09/2003, 21h28
  5. Une fonction avec des attributs non obligatoires
    Par YanK dans le forum Langage
    Réponses: 5
    Dernier message: 15/11/2002, 13h39

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