Discussion :

[adda_issa]

salut,

il s'agit de la définition de deux constructeurs

j'arrive pas a comprendre pourquoi allouer de l'espace mémoire alors que nous pouvons utiliser la notion d'address

en vérité j'aimerai savoir qu'est ce qui différencie ses deux constructeur ci dessous

NB:largeur et hauteur sont des pointeurs

1-cas: Rectangle::Rectangle(double l,double h):largeur(new double(l)),hauteur(new double(h))

2-cas: Rectangle::Rectangle(double l,double h):largeur(&l),hauteur(&h)

merci d'avance

[Bousk]

Le premier crée des pointeurs pour y stocker les valeurs, le second pointe vers les variables passées en paramètres.
Et vu que les variables sont temporaires, il pointera vite vers de la mémoire pourrie.
Dans les deux cas, avoir un pointeur comme membre ici est pas loin du top 1 de la mauvaise idée.

[koala01]

Salut,

En fait, les deux sont complètement aberrant en l'état, car les notions de hauteur et de largeur devraient être manipulées par valeurs

En effet, un pointeur n'est, à la base, qu'une valeur numérique entière (généralement) non signée qui permet de représenter l'adresse à laquelle on espère trouver une donnée du type indiqué.

Ce concept n'a qu'un seul intérêt: on dispose d'une valeur (nullptr, anciennement, on utilisait la macro NULL qui indique de manière explicite que ... la donnée souhaitée n'existe pas.

Or, dans le cas de la hauteur et de la largeur d'un rectangle, cela revient, sommes toutes, à dire que la donnée en question est égale à 0. Et tu seras d'accord avec moi pour dire qu'avoir un rectangle dont hauteur est égale à 0 et la largeur est égale à 3.1415 (ou l'inverse) n'a ... absolument auun sens !

Ceci étant dit, pour les cas pour lesquels l'utilisation aurait du sens (car il y en a), il faut savoir que C++ applique des règles très strictes quant à la durée de vie des données:

De manière générale, une donnée -- quelle qu'elle soit -- n'existe dans l'application qu'entre le moment où elle est déclarée et l'accolade fermante qui correspond à la dernière accolade ouvrante qui précède cette déclaration (on parle de "portée" des variables).

Voici un petit exemple pour t'aider à comprendre (lis les commentaires :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
int main(){
    int a = 3;   // a existe à partir d'ici
    // on peut utiliser a ici
    for(/* ... ; ...; ... */){
        int b;  // b existe à partir d'ici
        int c;  // c  existe à partir d'ici
        //  on peut utiliser a, b et c ici, car les trois existent
    }  // b et c sont détruits ici (c est détruit en premier, b est détruit ensuite)
    // on peut toujours utiliser a ici
    // mais on ne peut plus utiliser ni b ni c.
} // a est détruit ici

Le problème avec les pointeurs, c'est qu'il n'y a aucun moyen de faire la différence entre une adresse mémoire à laquelle on trouvera effectivement la donnée du type indiqué et la même adresse mémoire dont la donnée a déjà été détruite. Voici un code pour comprendre le problème:

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
int main(){
    int * ptr_b = nullptr; // pointeur dont on dit explicitement
                           // qu'il pointe sur une adresse invalide
    /* on peut tester */
    if(! ptr_b){ // correspond à if(ptr_b == nullptr)
        std::cout<<"adresse invalide\n";
    }
    for(/* ... ; ...; ... */){
        int b = 5;
        ptr_b = & b;  // ptr_b prend l'adresse mémoire où se trouve b
        *ptr_b = 10; // remplace la valeur qui se trouve à l'adresse indiquée
                   // par ptr_b (autrement dit la valeur de b)
                   // par 10, pas de problème
     }  // CRACK!!! b est détruit, ptr_b contient une adresse mémoire à laquelle
        // on ne trouve plus la moindre donnée
    if(ptr_b){ // correspond à if(ptr_b != nullptr)
        std::cout<<"ptr_b semble correspondre à une adresse valide\n";
        *ptr_b = 15; // BOUM: l'adresse semble valide, et pourtant
                     // elle ne correspond à aucune donnée
    }
}

L'allocation dynamique de la mémoire nous permet de dire au compilateur que l'on veut "contourner" la règle sur la portée des données. En d'autres termes, elle nous permet de dire au compilateur que

Je ne veux pas que cette donnée soit détruite au moment où on quitte la portée dans laquelle elle est déclarée.

Il est parfois utile de pouvoir agir de la sorte, mais, en toute honnêteté, cela pose souvent bien plus de problèmes que cela n'en résout, parce que:

1. Il faut s'assurer de manière systématique que le pointeur représente une adresse mémoire valide avant d'essayer d'accéder à la donnée qui s'y trouve cela implique
2. qu'il faut avoir la certitude que le pointeur reprend la valeur nullptr lorsque la donnée est effectivement détruite (surtout si le pointeur reste accessible après la destruction)
3. nous prenons spécifiquement la responsabilité de veiller à libérer la mémoire allouée de manière dynamique, ce qui implique:
4. qu'il faut libérer cette mémoire au plus tard juste avant de "perdre" l'adresse mémoire (le dernier pointeur pointant sur l'adresse mémoire en question), autrement, nous observerons une "fuite mémoire", qui, à termes, pourrait mettre l'intégrité de tout le système à mal
5. il faut éviter de libérer "une deuxième fois" la mémoire (allouée de manière dynamique) qui a déjà été libérée une première fois, car cela fera planter l'application

A tel point qu'il n'y a -- en définitive qu'un seul cas dans lequel nous n'aurons pas d'autre choix que d'avoir recours à l'allocation dynamique de la mémoire: lorsque l'on définit une hiérarchie de classes (polymorphes) et que l'on souhaite maintenir toutes les instances des classes participant à cette hiérarchie sous la forme d'une "liste d'objets connus comme étant du type de base".

Et encore, selon le cas, nous veillerons à utiliser les pointeurs intelligents fournis -- depuis 2011 -- par la bibliothèque standard (avant, nous aurions utilisés ceux fournis par boost, dont la bibliothèque standard s'est inspirée), à savoir : std::unique_ptr ou le couple std::shared_ptr et std::weak_ptr.

Mais ca, j'en parlerai un autre jour

[adda_issa]

salut,
j'aimerai aussi que vous m'aider a ce niveau avec le code ci dessous

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
//declaration
vector<Vehicule*> listeVehicules;
listeVehicules.push_back(new Voiture(15000, 5));

j'aimerai savoir s'il est possible d'utiliser listeVehicules.push_back(& v) après avoir déclarer Voiture v(15000,5) Voiture etant une classe; cet a dire ecrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
int main()
{
vector<Vehicule*>listeVehicules;
Voiture v(15000,5);
listeVehicules.push_back(&v);
}

merci d'avance

[koala01]

Il est possible de le faire (dans le sens où le compilateur ne verra aucune objection), car un pointeur n'est jamais qu'une valeur numérique entière (généralement) non signée représentant l'adresse mémoire à laquelle on devrait trouver une donnée du type indiqué.

Mais, en pratique, les règles de portées pour les données créées sur la pile (les données créées sans utiliser new) font qu'il est très largement déconseillé de le faire, parce que le pointeur risque fort de représenter une adresse mémoire où se trouve une donnée qui a déjà été détruite (et qu'il n'y a aucun moyen de faire la différence entre cette adresse mémoire et une autre à laquelle se trouve une donnée qui existe encore et qui n'a pas été détruite).

Voici un exemple simple pour te faire 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
15
int main(){
    std::vector<Voiture*> tab;
    for(int i=0; i<10; ++i){ // on veut ajouter 10 voiture
        Voiture v;
        tab.push_back(&v); //CRACK
    } // v est détruit ici,
      // le pointeur correspondant dans tab pointe sur une
      // adresse invalide
    for(auto * it : tab){
        it->someFunction(); // BOOM: erreur de segmentation:
                            // on essaye d'accéder à une
                            // adresse mémoire qui ne
                            // contient aucune donnée non détruite
    }
} tab est détruit ici

[adda_issa]

Le premier crée des pointeurs pour y stocker les valeurs, le second pointe vers les variables passées en paramètres.
Et vu que les variables sont temporaires, il pointera vite vers de la mémoire pourrie.
Dans les deux cas, avoir un pointeur comme membre ici est pas loin du top 1 de la mauvaise idée.

il pointera vers la memoire pourrie sachant que dans le destructeur on a largeur=nullptr; hauteur=nullptr;????

[foetus]

il pointera vers la memoire pourrie sachant que dans le destructeur on a largeur=nullptr; hauteur=nullptr;????

Non, il y a erreur de compréhension Le pointeur va pointer vers une adresse qui ne sera plus utilisée par ton objet (donc à l'instant T, tu n'as plus la garantie que ton pointeur pointe vers l'objet désiré ou vers tout autre chose - c'est indéterminé (*))

Le destructeur est surtout en charge de libérer la mémoire que l'objet a allouée.

Pour largeur=nullptr; hauteur=nullptr, ce sont des affections, juste pour mettre la mémoire à zéro. C'est un héritage du C, justement lorsque tu as des pointeurs invalides - en voyant tout à 0 ou que ton programme détecte le pointé à 0 (cela peut être un plantage si tu ne fais pas les tests ), tu dois te dire qu'il y a un problème parce que le destructeur a été appelé. Au lieu que ton programme ait des objets erronés ou pas (mais c'est indéterminé (*)) sans vraiment planter (c'est 1 principe du développeur - toujours s'arrêter à l'endroit du bogue et "pas ailleurs")

[foetus]

il pointera vers la memoire pourrie sachant que dans le destructeur on a largeur=nullptr; hauteur=nullptr;????

Suite à ton message privé, je te conseille vivement de reprendre la notion de pointeur parce que c'est très très mélangé dans ta tête

1) la notion d'adresse et l'opérateur &.
2) les variables locales, leurs allocations et après les "dangling pointers" que @koala01 te parlait
3) l'allocation dynamique avec les fonctions malloc/ free.
3) les structures et leurs allocations/ comment les membres sont "agencés en mémoire" - parce que j'ai compris que tu me parles de cela, mais je ne vois pas le rapport avec la choucroute
4) toutes les autres choses en relation avec la mémoire en C que j'oublie

Et seulement ensuite et après du code très plantogéne mais très instructif qui forge l'expérience , tu pourras aborder le C++ et la notion de constructeur/ destructeur dont je te parlais dans le message précédent
Il y a aura d'autres choses en C++ comme par exemple les références, les pointeurs intelligents.