Différence d'instanciation d'objets

Version imprimable

13/04/2011, 15h48
Wrack44

Différence d'instanciation d'objets

Bonjour,

J'ai beau chercher sur Google je ne trouve pas de site qui explique précisément la différence entre un object instancié de la sorte:

Code:

MyObject myobject(10);

ou

Code:

MyObject *myobject = new MyObject(10);

La portée, la mémoire, tout y est expliqué mais aucun exemple concret qui me montre où un object instancié avec la méthode 1 ne fonctionnerait pas alors qu'un objet instancié avec la méthode 2 irait...

QUelqu'un aurait un petit bout de code explicatif ?

Merci

a+
13/04/2011, 16h19
AF_2.8

Je pense que tu as déjà compris que l'un des deux objets est statique, et l'autre est dynamique.
La seul différence est donc la facon dont tu gères la mémoire.
Dans le cas de l'objet statique tu alloues la mémoire tout de suite et ce jusqu'à la fin de la portée de l'objet.
Dans le cas de l'objet dynamique tu alloues la mémoire quand tu en as besoin, et tu la libère quand tu n'en as plus besoin; celà donne donc plus de souplesse mais demande également plus de rigueur.

A près dans d'autre cas de figure, principalement celui de l'héritage il est intéressant d'utiliser des objets dynamiques. Imagine que tu ais les classes B,C,D qui hérite de A. Si tu veux toutes les mémoriser dans un tableau la seule solution consiste à créer un tableau (ou un conteneur) de pointeur sur A et tu alloueras dynamiquent les objets B,C,D pour pouvoir les ranger dans le tableau ce que tu ne pourras pas faire avec des objets statiques.
Voici donc un exemple parmi d'autre de l'avantage de l'objet dynamique.

Un des autres avantages et le passage par pointeur d'un objet dans une fonction qui evite de recopier tout l'objet en mémoire (donc gain de temps et d'espace mémoire), même si en C++ tu peux avoir la même chose avec un objet statique passé par référence.

Autre chose : la portée d'un objet statique et fixé, celle d'un objet dynamique non, tout le temps que tu ne l'a pas désalloué, il existe (c'est souvent une des raisons des fuites mémoires)

Salut,

Exemple concret:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 MaClass* creerMaClass1() { MaClass* maClass = new MaClass(); return maClass; } MaClass* creerMaClass2() { MaClass maClass(); return &maClass; } int main() { MaClass* maClass1 = creeMaClass1(); MaClass* maClass2 = creeMaClass2(); // maintenant si tu essaye d'utiliser maClass2 tu te prendra un joli segFault dans les dents :) }
Dans l'absolu, on pourrait tout coder en allocation dynamique, mais il faudrait tout libérer à la main tout le temps... J'imagine même pas les lignes de delete en fin de fonction et le nombre de fuite...

13/04/2011, 17h18
Invité

Citation:

Envoyé par AF_2.8

(...)
Dans le cas de l'objet statique tu alloues la mémoire tout de suite et ce jusqu'à la fin de la portée de l'objet.
(...)

Sur le fond, c'est juste, mais sur la forme, c'est extrêmement ambigüe par rapport aux notions C++.

Idéalement il faudrait éviter d'utiliser le terme statique ici car il porte à confusion avec le mot clé static.

Et la notion de "fin de la portée de l'objet" n'est pas très claire non plus. (En programmation, la portée signifie: d'où est-ce que je peux utiliser quelque-chose)
Il faudrait mieux dire "fin du bloc du code où est déclaré l'objet" (sauf pour le cas des variables static qui ne sont désinstanciées qu'à la fin du programme).
13/04/2011, 17h22
Flob90

@AF_2.8:

Citation:

Imagine que tu ais les classes B,C,D qui hérite de A. Si tu veux toutes les mémoriser dans un tableau la seule solution consiste à créer un tableau (ou un conteneur) de pointeur sur A et tu alloueras dynamiquent les objets B,C,D pour pouvoir les ranger dans le tableau ce que tu ne pourras pas faire avec des objets statiques.

Pour le début oui, mais pas besoin d'allouer dynamiquement (je ne crois pas qu'on parle d'allocation statique, on dirait plutôt sur la pile, et "objets statiques" désigne autre chose).

@OP: Imagines que tu ais un programme qui demance à l'utilisateurs (via un flux d'entrée, console, fichier, autre), combien d'objets de tel entité il doit créer par exemple, comment tu ferais sans utiliser l'allocation dynamique ? (directement ou indirectement (*) ). Les cas où l'utilisation de l'allocation dynamique est indispensable c'est lorsque que tu ne peux pas prévoir à l'avance ce que tu auras besoin de créer.

(*) Si tu passes par un tableau dynamique du genre vector, elle est caché mais reste présente.
13/04/2011, 17h47
Wrack44

Merci pour toutes vos réponses!

Je pense avoir mieux compris. En gros on est pas souvent "obligé" de passer par du dynamique. La façon "statique" est correcte aussi mais dans certain cas je serai contraint de coder avec du dynamique. Je peux donc continuer comme j'avais commencé, merci beaucoup :)

Merci pour les réponses rapides et à bientôt,

Il y a une manière de voir simple qui peut t'aider à rapidement choisir ta manière d'instancier ton objet.

L'idée fondamentale est que ce soit deux manières de donner un temps de vie à ton objet. Les notions de zone de stockage (pile ou tas) sont des détails d'implémentation.

Si tu veux que ton objet vive uniquement le temps d'execution du bloc en cours :
Code:

1 2 3 4 5 6 { /// MonType mon_object; } /// mon_objet est implicitement détruit ici
Par contre si tu veux déterminer "à la main" le moment où ton objet doit être détruit :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 { MonType* mon_object = new MonType(); } /// mon_objet est implicitement n'est pas détruit ici //// blah blah blah du code void finish_him( MonType* mon_objet ) { delete mon_objet; // mon objet (si valide) sera détruit ici }
Dans ce cas n'oublie jamais de faire en sorte que chaque appel à new à l'execution ait son appel à delete quelque part. Cela suggère que tu ais toujours un pointeur valide vers ton objet à tout moment. Sinon, tu as un "memory leak", une fuite de mémoire (fuite parcequ'elle est là, qu'elle n'est jamais désallouée mais tu n'y as plus accès et donc tu ne peux pas la libérer).

Une fois que tu as compris ça, tu comprends aussi qu'il se peut que tu veuilles définir une règles "générale" qui va régir la vie de certains de tes objets.
En C++, on appelle ça des "smart pointer" (pointeur intelligents).

Chaque type de smart pointer va avior une règle de gestion différente. C'est un tout autre sujet alors je te conseil de jetter un oeil à ce que fournis boost pour comprendre.

14/04/2011, 11h12
Wrack44

Merci pour toute ces réponses...

Et en fait en codant ce matin j'ai vite compris l'utilité de la portée, j'ai été obligé de créer des objets dynamiques pour mes besoins, suivants vos conseils, super!

Par contre libérer la mémoire avec le delete, je ne le fais que quand je n'ai plus besoin de ces objets. Ma question est la suivante: j'ai plusieurs objets, qui vont me servir tout au long de mon programme, en gros j'en aurai besoin jusqu'à la dernière instruction de mon programme. Dois-je quand même les deleter? Ou cela va se faire tout seul au moment ou mon programme va se terminer non?

Merci,

a+
14/04/2011, 11h26
Klaim

1. delete n'est jamais appelé tout seul (sauf avec des smart pointer)
2. La plupart des OS d'aujourd'hui vont de toutes façons libérer la mémoire de l'application d'un coup. Donc tu ne verras pas le problème.
3. Par contre si tu ne libères pas ta mémoire à la fin de l'application, c'est très "sale". Si un jour tu as besoin que ton application soit modifiée (et ça arrivera) il y aura forcément des problèmes (performance et mémoire) qui seront liés à cette fuite mémoire.

Résumé : delete toujours tes objets alloués avec new.
14/04/2011, 11h29
Wrack44

Donc en gros si je ne la libère pas elle reste prise par l'OS même quand mon programme a terminé de tourner? quelle idée bizarre :) Donc le seul moyen de la libérer est de redémarrer la machine?

Ok donc à la fin de mon main je delete les vars maintenant :)

Merci,
14/04/2011, 13h16
Klaim

Non non, les OS récent (par exemple, pas Windows95) vont bien libérer la mémoire une fois le programme quitté. C'est juste "propice aux érreurs" si il y a des évolutions de l'application.

Personnellement, j'ai adopté le dogme suivant : quand j'écris un new, je m'arrête et j'écris le code qui va faire le delete immédiatement. Du coup, ça m'oblige à penser new et delete ensemble et à toujours faire en sorte d'avoir réfléchis à la stratégie de vie de mes objets dans son ensemble.