Merci et j'ai une question: pourquoi dit-on que le tas est géré par le logiciel (le système d'exploitation), tandis que la pile est gérée par l'ordinateur.
Bonjour. Peut être que j'ai mal compris la question. La pile est directement géré par le système d'exploitation. Il faut imaginer un grand tas de feuille, chaque fois qu'on déclare une variable int i = 0; i est mis sur une nouvelle feuille, mise en haut de la pile. Quand i meurt on l'enlève de la pile. C'est géré de manière automatique il n'y à rien à faire. Le tas, lui est utilisé pour les allocations dynamique (le new en gros). Et là c'est au programme, (et plutôt au programmeur) de gérer la vie de ces éléments. On va dire que le système d'exploitation ne regarde pas ce qui se passe dans le tas, c'est entièrement le programme qui va gérer les éléments à l'intérieur du tas.
@@lepetitcplusplus8013 lors de mes lectures j'ai eu à lire dans un blog si je ne me trompe pas ce que vous venez d'expliquer et l'auteur a précisé sans détailler la gestion des deux parties de mémoires. merci pour l'explication car ça me permet de voir un peu plus claire.
@@yussufabbawa1854 Bonjour, désolé du retard je n'étais pas présent ces derniers temps. En plus de ces deux mécanismes, il y a en réalité un troisième emplacement mémoire, celui des statiques. Mais ça reste assez anecdotique, et généralement elles sont embarqués avec l'exécutable.
Salut, je suis un abonné récent de ta chaîne, je suis super content de voir enfin une chaîne en français qui va dans les concepts C++ plus en profondeur que les bases du langage ! J'aurais une question, j'avais lu que dans l'allocation de mémoire sur la pile, la seule chose qui se passait derrière c'est un déplacement du curseur d'allocation dans la pile après avoir donné son adresse ; et pour une libération de la mémoire, c'est aussi un simple déplacement du curseur dans l'autre sens. Mais ma question, c'est est-ce que si je crée un scope ne contenant que int i = 5 par exemple, et que juste après la fin de ce scope, je crée une variable integer sans l'initialiser, est-ce que cette dernière variable aura la valeur 5 également ? J'ai déjà essayé ce cas de figure mais le compilateur n'a pas voulu que je laisse une variable non initialisée dans le programme. Et autre question, dans quel sens le curseur de déplace-t-il ? C'est peut-être variable selon le compilateur ?
L’expérience est interessante. Pour la variable avec une valeur fantôme, je dirais oui, en effet. Certains compilateurs ne génère qu’un warning pour les variables non initialisées. Il faut également désactiver les optimisations pour que les variables soient effectivement placées dans la pile, et pas seulement dans un registre du processeur. Pour le sens de la pile, c’est surtout le processeur qui est en cause. La pile est gérée par le compilateur dans le même sens que les empilements (push, call) et dépilements (pop, ret) du processeur.
Pour compléter Jean-Marie Papillon, en théorie, non ta variable reste non initialisé. L'ensemble devrait être libéré et nettoyer quand ta précédente variable est détruite. Cependant, mais c'est à prendre avec tes pincettes, je ne suis pas sûr à 100% ce que je vais avancer. Mais suivant la machine et le compilateur, je pense que cela peut se produire.
Merci et j'ai une question:
pourquoi dit-on que le tas est géré par le logiciel (le système d'exploitation), tandis que la pile est gérée par l'ordinateur.
Bonjour. Peut être que j'ai mal compris la question. La pile est directement géré par le système d'exploitation. Il faut imaginer un grand tas de feuille, chaque fois qu'on déclare une variable int i = 0; i est mis sur une nouvelle feuille, mise en haut de la pile. Quand i meurt on l'enlève de la pile. C'est géré de manière automatique il n'y à rien à faire.
Le tas, lui est utilisé pour les allocations dynamique (le new en gros). Et là c'est au programme, (et plutôt au programmeur) de gérer la vie de ces éléments. On va dire que le système d'exploitation ne regarde pas ce qui se passe dans le tas, c'est entièrement le programme qui va gérer les éléments à l'intérieur du tas.
@@lepetitcplusplus8013 lors de mes lectures j'ai eu à lire dans un blog si je ne me trompe pas ce que vous venez d'expliquer et l'auteur a précisé sans détailler la gestion des deux parties de mémoires.
merci pour l'explication car ça me permet de voir un peu plus claire.
@@yussufabbawa1854 Bonjour, désolé du retard je n'étais pas présent ces derniers temps. En plus de ces deux mécanismes, il y a en réalité un troisième emplacement mémoire, celui des statiques. Mais ça reste assez anecdotique, et généralement elles sont embarqués avec l'exécutable.
Salut, je suis un abonné récent de ta chaîne, je suis super content de voir enfin une chaîne en français qui va dans les concepts C++ plus en profondeur que les bases du langage !
J'aurais une question, j'avais lu que dans l'allocation de mémoire sur la pile, la seule chose qui se passait derrière c'est un déplacement du curseur d'allocation dans la pile après avoir donné son adresse ; et pour une libération de la mémoire, c'est aussi un simple déplacement du curseur dans l'autre sens. Mais ma question, c'est est-ce que si je crée un scope ne contenant que int i = 5 par exemple, et que juste après la fin de ce scope, je crée une variable integer sans l'initialiser, est-ce que cette dernière variable aura la valeur 5 également ?
J'ai déjà essayé ce cas de figure mais le compilateur n'a pas voulu que je laisse une variable non initialisée dans le programme.
Et autre question, dans quel sens le curseur de déplace-t-il ? C'est peut-être variable selon le compilateur ?
L’expérience est interessante.
Pour la variable avec une valeur fantôme, je dirais oui, en effet. Certains compilateurs ne génère qu’un warning pour les variables non initialisées. Il faut également désactiver les optimisations pour que les variables soient effectivement placées dans la pile, et pas seulement dans un registre du processeur.
Pour le sens de la pile, c’est surtout le processeur qui est en cause. La pile est gérée par le compilateur dans le même sens que les empilements (push, call) et dépilements (pop, ret) du processeur.
Pour compléter Jean-Marie Papillon, en théorie, non ta variable reste non initialisé. L'ensemble devrait être libéré et nettoyer quand ta précédente variable est détruite. Cependant, mais c'est à prendre avec tes pincettes, je ne suis pas sûr à 100% ce que je vais avancer. Mais suivant la machine et le compilateur, je pense que cela peut se produire.
Et merci :D