Là il y a un bouquin de C++ que tu dois brûler ou des personnes dont il faudrait arrêter d'écouter les conseils... Sérieusement.
Et moi je ne vois pas ce qu'il y'a de pas clair dans ce que j'explique. Comme je l'ai déjà dit, il y'a pleins de bonne raisons pour ne pas mettre d'objet dans la pile et pour toutes ces bonnes raisons ce n'est pas la méthode normale pour allouer des objets:
- La pile n'est pas un espace mémoire immense et mettre des objets (et a fortiori gros) dans la pile c'est s'exposer à un risque de stack overflow.
- Le programme sauvegarde son contexte d'execution dans la pile et ça implique des problèmes de sécurité puisque la pile est "executable". Le buffer overflow ce n'est pas seulement dans mes cauchemars.
Et il y'a aussi les problèmes dans le cas de programme multithreadé que j'avais oublié (merci pBpG). La pile n'est pas vraiment un espace thread-safe et effectivement on peut arriver à des résultats rigolos.
Utiliser la pile pour les types primitifs absolument je suis entièrement d'accord mais pour des objets non ou alors quand vraiment le besoin de performance se fait sentir. Là, il y a un bouquin de C++ que tu dois brûler ou des personnes dont il faudrait arrêter d'écouter les conseils... Sérieusement.
C'est un peu facile de ne pas prendre la solution normale proprosée par le langage, et ensuite de se plaindre des difficultés liées à une solution plus compliquée et contenant plus de risques, mais que tu a décidé d'utiliser.
Bien bien ok toi tu utilises la pile mais d'autres personnes non (sûrement des mauvais programmeurs) et dans ces cas là le problème se pose, tu peux retourner le problème dans tous les sens mais ça reste toujours la même chose : la gestion mémoire n'est pas simple et est source d'erreur (dans la vraie vie, dans les programmes des entreprises mais pas dans les tiens ok).
Le GC est une solution qui peut convenir, ce n'est pas la solution qui corrige des difficultés du C++. Une solution digne de ce nom ne dégrade pas.
Elle ne dégrade pas au contraire. Bon, sérieusement, j'ai fait de l'audit de code C++, j'en fais aussi (Java cette fois-c)i actuellement pour la boite ou je travaille et clairement le nombre de memory leaks est bien plus élevé dans le programme C++ que dans ce programme Java. Le GC est à mon avis plus efficace que des désallocations manuelles. En ça c'est une bonne solution, permettre d'avoir des programmes plus fiables c'est tout de même le plus important.
Pour finir, j'aprécie le C++ et ses qualités mais je l'ai assez pratiqué pour savoir qu'il a des défauts, que Java corrige entre autre. Après on peut se mettre la tête dans le sable et tout nier en bloc mais c'est un fait et probablement qu'un jour un langage corrigera les erreurs du Java. C'est tant mieux, c'est ça l'évolution.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Et moi je ne vois pas ce qu'il y'a de pas clair dans ce que j'explique. Comme je l'ai déjà dit, il y'a pleins de bonne raisons pour ne pas mettre d'objet dans la pile et pour toutes ces bonnes raisons ce n'est pas la méthode normale pour allouer des objets:
- La pile n'est pas un espace mémoire immense et mettre des objets (et a fortiori gros) dans la pile c'est s'exposer à un risque de stack overflow.
- Le programme sauvegarde son contexte d'execution dans la pile et ça implique des problèmes de sécurité puisque la pile est "executable". Le buffer overflow ce n'est pas seulement dans mes cauchemars.
Et il y'a aussi les problèmes dans le cas de programme multithreadé que j'avais oublié (merci pBpG). La pile n'est pas vraiment un espace thread-safe et effectivement on peut arriver à des résultats rigolos.
Utiliser la pile pour les types primitifs absolument je suis entièrement d'accord mais pour des objets non ou alors quand vraiment le besoin de performance se fait sentir. Là, il y a un bouquin de C++ que tu dois brûler ou des personnes dont il faudrait arrêter d'écouter les conseils... Sérieusement.
C'est un peu facile de ne pas prendre la solution normale proprosée par le langage, et ensuite de se plaindre des difficultés liées à une solution plus compliquée et contenant plus de risques, mais que tu a décidé d'utiliser.
Bien bien ok toi tu utilises la pile mais d'autres personnes non (sûrement des mauvais programmeurs) et dans ces cas là le problème se pose, tu peux retourner le problème dans tous les sens mais ça reste toujours la même chose : la gestion mémoire n'est pas simple et est source d'erreur (dans la vraie vie, dans les programmes des entreprises mais pas dans les tiens ok).
Le GC est une solution qui peut convenir, ce n'est pas la solution qui corrige des difficultés du C++. Une solution digne de ce nom ne dégrade pas.
Elle ne dégrade pas au contraire. Bon, sérieusement, j'ai fait de l'audit de code C++, j'en fais aussi (Java cette fois-c)i actuellement pour la boite ou je travaille et clairement le nombre de memory leaks est bien plus élevé dans le programme C++ que dans ce programme Java. Le GC est à mon avis plus efficace que des désallocations manuelles. En ça c'est une bonne solution, permettre d'avoir des programmes plus fiables c'est tout de même le plus important.
Pour finir, j'aprécie le C++ et ses qualités mais je l'ai assez pratiqué pour savoir qu'il a des défauts, que Java corrige entre autre. Après on peut se mettre la tête dans le sable et tout nier en bloc mais c'est un fait et probablement qu'un jour un langage corrigera les erreurs du Java. C'est tant mieux, c'est ça l'évolution.