« Non, comme je le disais ce n'est pas la méthode normale. »
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.
« En général on instancie pas d'objets sur la pile, le heap est parfaitement adapté comme espace utilisateur, d'autant que question sécurité utiliser la pile ce n'est pas vraiment terrible. »
Ce n'est « en général » que si on s'obstine à appliquer en C++ des habitudes venant de C ou de Java. Sinon c'est à éviter quand on fait du C++. L'instanciation dont tu parles, dans la mémoire globale (et pas dans le heap, a priori, même si le compilo peut faire comme ça) n'est pas plus adaptée, juste plus coûteuse. Et évidemment amène les risques liés aux pointeurs. 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.
« D'ailleurs, Java ne place que des références sur la pile et jamais d'objets (ok pas pour les même raisons mais bon ... C# n'alloue jamais d'objets sur la pile non plus). »
Ben c'est pas une référence puisque ces langages offrent moins de types de mémoire possibles. Je vois mal comment Java pourrait mettre autre chose que des références sur la pile puisque la durée de vie des objets n'est pas liée aux blocs... c'est normal vu les contraintes du langage.
« Oui il y'a une raison qui est liée au conteneur, si je me souviens bien, on ne peut pas mettre des objets d'une classe de base et des objets de la classe dérivé dans ce conteneur (je ne me souviens plus la raison) ce qui implique qu'on utilise des pointeurs. Et là notre problème de libération mémoire se pose. »
C'est parce qu'une copie est effectuée, qui va copier dans le type de base, enfin je suppose. Mais tu te places aussi dans un cas où des références plutot que des pointeurs ne conviennent pas, et où la libération des pointeurs poserait problème (contrairement à une utilisation généralisée de pointeurs, là on sait plus facilement où regarder). Boost propose aussi des pointeurs intelligents qui supportent la copie (donc la SL aussi)...
« Oui bien sûr avec un exemple tel que celui-là (qui est décidement mal choisi), on peut utiliser la pile mais bon (cf quelques lignes plus haut). »
Mais bon, t'as décidé de ne pas faire comme ça, ça me parait être la principale raison.
« C'est un pattern justement ;-). Je trouve que c'est un bricolage parce que pour disposer de tous les avantages du java (...) »
Tous les avantages de Java ? C'est une curieuse manière de voir les choses quand tant de choses sont supprimées et que l'on n'a plus le choix. L'avantage c'est juste qu'il y a un ramasse-miettes ; qu'il soit obligatoire n'en est pas forcément un.
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.
« je me souviens d'un papier de Stroustrup parlant d'un GC pour C++ preuve que même son créateur est conscient que c'est une fonctionnalité qui manque. »
Et ? Le fait que ça manque veut seulement dire que l'ajout des possibilités d'un GC serait un plus. Et ça parait évident. Mais il ne s'agit que d'un ajout, pas d'un remplacement... heureusement, en particulier puisque C++ possède des choses plus efficaces et simples, qu'il serait néfaste de supprimer (choix fait dans Java).
« Le comportement n'est pas différent d'un new en C++ à la différence que ce n'est pas au programmeur de se soucier de l'élimination de l'objet. »
Que le programmeur n'ait pas à s'en soucier, c'est l'avantage. Que ce soit « comme un new en C++ », c'est là l'inconvénient. En C++ justement on cherche à les éviter. C'est quand même bien porc de taper dans la mémoire dynamique quand on peut utiliser de l'automatique...
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
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.
« En général on instancie pas d'objets sur la pile, le heap est parfaitement adapté comme espace utilisateur, d'autant que question sécurité utiliser la pile ce n'est pas vraiment terrible. »
Ce n'est « en général » que si on s'obstine à appliquer en C++ des habitudes venant de C ou de Java. Sinon c'est à éviter quand on fait du C++. L'instanciation dont tu parles, dans la mémoire globale (et pas dans le heap, a priori, même si le compilo peut faire comme ça) n'est pas plus adaptée, juste plus coûteuse. Et évidemment amène les risques liés aux pointeurs. 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.
« D'ailleurs, Java ne place que des références sur la pile et jamais d'objets (ok pas pour les même raisons mais bon ... C# n'alloue jamais d'objets sur la pile non plus). »
Ben c'est pas une référence puisque ces langages offrent moins de types de mémoire possibles. Je vois mal comment Java pourrait mettre autre chose que des références sur la pile puisque la durée de vie des objets n'est pas liée aux blocs... c'est normal vu les contraintes du langage.
« Oui il y'a une raison qui est liée au conteneur, si je me souviens bien, on ne peut pas mettre des objets d'une classe de base et des objets de la classe dérivé dans ce conteneur (je ne me souviens plus la raison) ce qui implique qu'on utilise des pointeurs. Et là notre problème de libération mémoire se pose. »
C'est parce qu'une copie est effectuée, qui va copier dans le type de base, enfin je suppose. Mais tu te places aussi dans un cas où des références plutot que des pointeurs ne conviennent pas, et où la libération des pointeurs poserait problème (contrairement à une utilisation généralisée de pointeurs, là on sait plus facilement où regarder). Boost propose aussi des pointeurs intelligents qui supportent la copie (donc la SL aussi)...
« Oui bien sûr avec un exemple tel que celui-là (qui est décidement mal choisi), on peut utiliser la pile mais bon (cf quelques lignes plus haut). »
Mais bon, t'as décidé de ne pas faire comme ça, ça me parait être la principale raison.
« C'est un pattern justement ;-). Je trouve que c'est un bricolage parce que pour disposer de tous les avantages du java (...) »
Tous les avantages de Java ? C'est une curieuse manière de voir les choses quand tant de choses sont supprimées et que l'on n'a plus le choix. L'avantage c'est juste qu'il y a un ramasse-miettes ; qu'il soit obligatoire n'en est pas forcément un.
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.
« je me souviens d'un papier de Stroustrup parlant d'un GC pour C++ preuve que même son créateur est conscient que c'est une fonctionnalité qui manque. »
Et ? Le fait que ça manque veut seulement dire que l'ajout des possibilités d'un GC serait un plus. Et ça parait évident. Mais il ne s'agit que d'un ajout, pas d'un remplacement... heureusement, en particulier puisque C++ possède des choses plus efficaces et simples, qu'il serait néfaste de supprimer (choix fait dans Java).
« Le comportement n'est pas différent d'un new en C++ à la différence que ce n'est pas au programmeur de se soucier de l'élimination de l'objet. »
Que le programmeur n'ait pas à s'en soucier, c'est l'avantage. Que ce soit « comme un new en C++ », c'est là l'inconvénient. En C++ justement on cherche à les éviter. C'est quand même bien porc de taper dans la mémoire dynamique quand on peut utiliser de l'automatique...