Et même dans des langages bas niveau tel que le C, ou haut niveau tel que le C++ ou le Go, ces choses sont masquées.
Est juste une affirmation fausse: en C, si, il y a une gestion de la mémoire: malloc/calloc/realloc/free, c'est plus simple à utiliser que maintenir soit-même le tas et la pile du programme.
malloc/calloc/realloc/free (et alloca ne l'oublions pas), ce n'est pas de la gestion de la mémoire.
C'est à toi de calculer la taille suffisante pour stocker ta donnée au préalable. C'est à toi de t'assurer que le pointeur retourné par realloc est toujours le même qu'avant. C'est à toi de t'assurer de ne pas appeler free 2 fois sur le même pointeur.
L'implémentation des malloc qui appelle pour toi les syscall sbrk et brk et organisent la heap pour s'y retrouver reste quelque chose de très bas niveau, et peu différent de ce que tu ferais en Assembleur.
Maintenant, concernant le C++ et le Go, c'est mécanisme de gestion de mémoire sont bien masqués à l'utilisateur. En Go ce n'est pas toi qui appelle le Garbage Collector, ou qui alloue la mémoire pour tes objets. En C++ ce n'est pas toi qui appelle tel ou tel constructeur, ni les destructeurs. Ces choses sont présentes, mais pas exposés à l'utilisateur.
Je persiste et signe donc, C, C++, Go, et bien d'autres langages : ne sont pas explicite sur les concepts sous-jacents.
[^] # Re: C++, haut niveau ?
Posté par David Delassus (site web personnel) . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 3.
malloc/calloc/realloc/free (et alloca ne l'oublions pas), ce n'est pas de la gestion de la mémoire.
C'est à toi de calculer la taille suffisante pour stocker ta donnée au préalable. C'est à toi de t'assurer que le pointeur retourné par realloc est toujours le même qu'avant. C'est à toi de t'assurer de ne pas appeler free 2 fois sur le même pointeur.
L'implémentation des malloc qui appelle pour toi les syscall
sbrketbrket organisent la heap pour s'y retrouver reste quelque chose de très bas niveau, et peu différent de ce que tu ferais en Assembleur.Maintenant, concernant le C++ et le Go, c'est mécanisme de gestion de mémoire sont bien masqués à l'utilisateur. En Go ce n'est pas toi qui appelle le Garbage Collector, ou qui alloue la mémoire pour tes objets. En C++ ce n'est pas toi qui appelle tel ou tel constructeur, ni les destructeurs. Ces choses sont présentes, mais pas exposés à l'utilisateur.
Je persiste et signe donc, C, C++, Go, et bien d'autres langages : ne sont pas explicite sur les concepts sous-jacents.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg