Discussion :

[Panaméen]

Bonjour voila ,

On a un projet a faire ... nous avons bloqué sur quelque chose , " l'agrégation " entre le main ( ) et une autre classe ...

"L'autre classe" appellée A est celle qui a instancier l'objet de la classe B

.h de A

Code :

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

1
2
3
4
class A
{
     B *ObjetDeB;
};

.h de B

Code :

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

1
2
3
4
5
class B
{
     public :
                 void loooool ( ) ;
};

dans le cpp de A

Code :

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

1
2
3
4
A::A()  // Constructeur
{
    ObjetDeB = new B ; 
}

Code :

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

1
2
3
4
B A :: getmonB()    // getter de l'attribut
{
    return *ObjetDeB ;
}

main () :

Code :

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

1
2
3
4
5
6
7
8
9
10
int main()
{
   A MonA ;
   B *MonB ;
 
   *MonB = MonA.getmonB() ;
     MonB->loooool();
 
  return 0 ;
}

Pouvez me dire , si ce qui est au dessus est correct ? Merci davance

En fait , ce que nous recherchons a faire , cest de pouvoir utiliser l'instance de B crée par A via son adresse dans le main ( )


Cordialement

[Matthieu Brucher]

Déjà au niveau des types, ce n'est pas bon. Tu retournes une copie du B interne et tu le mets dans un B*, ça ne peut pas fonctionner...

[Panaméen]

Ca ne peut pas fonctionner , pourtant ca fonctionne ...
Que faire alors ?

[Matthieu Brucher]

Retourner le pointeur directement (B*), et non un B, et ça marchera.

[Panaméen]

Code :

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

1
2
3
4
B A :: getmonB()    // getter de l'attribut
{
    return *ObjetDeB ;
}

je retourne pas le pointeur directement là ?

[Matthieu Brucher]

Ben non, tu retournes une nouvelle instance de B par valeur, c'est juste une copie de l'objet pointé par ObjetDeB.

[nikko34]

Code :

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

1
2
3
4
B A :: getmonB()    // getter de l'attribut
{
    return *ObjetDeB ;
}

je retourne pas le pointeur directement là ?

non, tu renvoies une copie B.

si tu veux renvoyer ton pointeur:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
B* A::getmonB()
{
    return ObjetDeb;
}
 
int main()
{
    //...
    MonB = MonA.getmonB();
}

MAIS

si A crée l'objet B dans son constructeur et le détruit dans son destructeur ( à ne pas oublier... ), pourquoi en faire un pointeur?

tu peux faire

Code :

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

1
2
3
4
5
 
class A
{
    B ObjetDeB;
};

( construction et destruction automatique, tu n'as pas à faire de new ou de delete )

et renvoyer une référence (&) sur ton objet ( pas un pointeur ):

Code :

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

1
2
3
4
5
 
B & getMonB()
{
    return ObjetDeB;
}

et l'utiliser comme ça:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
int main()
{
    monA.getMonB().looool();
 
    // ou alors:
 
    B & monB = monA.getMonB();
    monB.looool();
 
    return 0;
}

En C++ le concept de références est important ( plus que celui de pointeur pour débuter ) .

Effectivement, quand on a pas encore bien compris les pointeurs et qu'on rajoute par dessus les références, je conçois bien ça ne doit pas être clair du tout ce que je raconte.

[corrector]

Ca ne peut pas fonctionner , pourtant ca fonctionne ...
Que faire alors ?

Commencer par apprendre le B-A-BA de l'usage des pointeurs avant d'essayer d'écrire des programmes avec des pointeurs.

Ne pas compiler avant d'avoir compris.

Tester son programme pour vérifier qu'on a compris.

[bdeuu]

Et il est preferable d'utiliser assez rapidement les auto_ptr et les shared_ptr qui permettent d'allegerla gestion de l'allocation dynamique de memoire

[koala01]

Salut,

On pourrait répondre à toutes tes questions de la manière suivante:
De manière générale, il faut préférer la gestion "statique" (AKA sur la pile) de la mémoire d'un objet plutôt que sa gestion "dynamique" (AKA sur le tas).

Cela sous entend que, tant que tu peux faire autrement, tu ne devrais pas avoir recours aux pointeurs.

Le corollaire de cela est que tu devrais utiliser éventuellement les conteneurs de la STL si tu envisage de "regrouper" plusieurs membres d'un même type.

Les méthodes renvoyant un membre renvoyant alors une référence sur le membre en question (constante, ou non, en fonction des besoins)

Les exception à ces règles sont relativement simples:

1. Si un membre d'une de tes classes doit survivre à la destruction de l'objet qui le contient
2. Si le membre représente en réalité le "conteneur" alors que la classe représente le "contenu" (exemple: un membre Usine dans une classe Travailleur)
3. Si le membre est du même type (ou d'une classe de base/dérivée) que la classe (exemple: un membre de type Noeud dans la classe... Noeud)
4. Si tu dois pouvoir profiter du polymorphisme, avec les méthodes virtuelles et autres astuces
5. Si un membre peut ne pas exister (à ne pas confondre avec "peut ne pas être initialisé), et que tu veux pouvoir en tester l'existence

alors, tu devra faire appel aux pointeurs, et vraisemblablement à l'allocation dynamique.

Les méthodes renvoyant ces membres renvoyant alors un pointeur vers ces membres (constant ou non selon les besoins)

A noter que, pour le premier cas, il peut s'avérer utile d'avoir une classe séparée dont la responsabilité sera, justement, de gérer les éléments alloués dynamiquement, et que dans le deuxième cas, le pointeur peut pointer vers un élément créé de manière "statique".

[corrector]

Disclaimer: Ami débutant en C++, tous les exemples de code de ce message sont faux, archi-faux. Ne viens pas me dire que tu n'étais pas prévenu.

Et il est préférable d'utiliser assez rapidement les auto_ptr et les shared_ptr qui permettent d'alléger la gestion de l'allocation dynamique de mémoire

Oui, mais pas trop vite : j'ai observé (ici) que certains commencent à utiliser shared_ptr avant d'avoir compris ce qu'est l'allocation dynamique, d'où des horreurs du type :

Code :

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

1
2
3
shared_ptr<A> p;
A a;
p.reset (&a);

Le problème, AMA, est que shared_ptr est présenté comme la baguette magique qui fait qu'on n'a plus à s'embêter à comprendre l'allocation dynamique, et comme un GC intégré au langage (comme si avec les smart pointers C++ devenait Java); alors qu'au contraire, je ne vois pas comment on peut comprendre shared_ptr sans comprendre l'usage correct de delete.

Le discours : "laisser les shared_ptr gérer les désallocations tous seuls" peut, mal interprété, devenir "je n'ai plus à besoin de comprendre comment ça marche", et conduire à :

Code :

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

1
2
3
shared_ptr<A> p, q;
p = blah blah;
q.reset (q.get ());

Comme quoi, l'absence de conversion implicite (A* -> shared_ptr<A> et shared_ptr<A> -> A*) n'effraie pas certains : ils invoquent plusieurs fonctions membres nommée, pour "convertir" shared_ptr<A> en A* en shared_ptr<A>. (Si ils voulaient "convertir" un A en B, et que la seule fonction qui renvoie un B et prennent A s'appelle A::I_want_to_get_a_B_and_then_die_an_horrible_death(), ils feraient b = a.I_want_to_get_a_B_and_then_die_an_horrible_death(). )