Et tu les utilises très bien avec de la mémoire automatique, c'est la méthode normale, faire du dynamique c'est uniquement si on ne peut pas faire autrement. La pile convient très bien.
Non, comme je le disais ce n'est pas la méthode normale. La pile n'est pas seulement disponible pour les variables locales, elle sert aussi à sauver le contexte d'exécution, l'exemple que je donnais était simple (je ne vais pas écrire une classe de 2000 lignes pour un exemple) mais supposons que j'utilise _beaucoup_ d'objets dans ma méthode, là le risque de dépassement est clair. 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. 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).
C'était clair que c'était des objets, mais tu ne dis pas pourquoi tu utilises des pointeurs, ce n'est pas une obligation. Rien ne t'empêche de mettre tes objets nouvellement créés directement dans ton vector, sans passer par des pointeurs. Ou alors il y a une raison qui t'en empeche, mais celle-là tu ne l'as pas explicitée.
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.
{
Compte l_compte;
l_compte.changerProprietaire(nom);
// d'autres trucs ici
}
Que cette manière de faire ne convienne pas toujours, ok, mais dans le cas de ton exemple, je ne vois rien qui l'empeche.
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). Eventuellement si on veut à tout prix utiliser la pile on peut mettre un pointeur sur la pile mais finalement ça revient au même vu qu'on sera tout de même obligé de supprimer le pointeur pour éliminer l'objet.
Ca ne parait vraiment pas plus « bricolage » qu'un « design pattern » quelconque, qu'un ramasse-miette, ou d'autres choses, le tout est de connaître l'outil qu'on utilise.
C'est un pattern justement ;-). Je trouve que c'est un bricolage parce que pour disposer de tous les avantages du java il faut bien choisir son pointeur intelligent (auto_ptr ne fonctionne pas avec la STL par exemple) et que ça crée des dépendances supplémentaires, bref c'est contraignant tout simplement parce que le langage n'a pas été prévu pour. 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.
Ma question c'est : ces variables locales peuvent-elles être des instances de classe, et alors leur constructeur et la libération de mémoire est-elle faite à la fin du bloc ?
Ok je n'avais pas compris. Quand on instancie un objet dans une méthode, la référence est effectivement libérée à la fin du bloc mais l'objet lui est toujours en mémoire et attends d'être éliminé par le GC. 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. Pour les autres variables (types primitifs), comme je le disais, le système est le même qu'en C++, elles sont détruites en fin de bloc.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Non, comme je le disais ce n'est pas la méthode normale. La pile n'est pas seulement disponible pour les variables locales, elle sert aussi à sauver le contexte d'exécution, l'exemple que je donnais était simple (je ne vais pas écrire une classe de 2000 lignes pour un exemple) mais supposons que j'utilise _beaucoup_ d'objets dans ma méthode, là le risque de dépassement est clair. 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. 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).
C'était clair que c'était des objets, mais tu ne dis pas pourquoi tu utilises des pointeurs, ce n'est pas une obligation. Rien ne t'empêche de mettre tes objets nouvellement créés directement dans ton vector, sans passer par des pointeurs. Ou alors il y a une raison qui t'en empeche, mais celle-là tu ne l'as pas explicitée.
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.
{
Compte l_compte;
l_compte.changerProprietaire(nom);
// d'autres trucs ici
}
Que cette manière de faire ne convienne pas toujours, ok, mais dans le cas de ton exemple, je ne vois rien qui l'empeche.
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). Eventuellement si on veut à tout prix utiliser la pile on peut mettre un pointeur sur la pile mais finalement ça revient au même vu qu'on sera tout de même obligé de supprimer le pointeur pour éliminer l'objet.
Ca ne parait vraiment pas plus « bricolage » qu'un « design pattern » quelconque, qu'un ramasse-miette, ou d'autres choses, le tout est de connaître l'outil qu'on utilise.
C'est un pattern justement ;-). Je trouve que c'est un bricolage parce que pour disposer de tous les avantages du java il faut bien choisir son pointeur intelligent (auto_ptr ne fonctionne pas avec la STL par exemple) et que ça crée des dépendances supplémentaires, bref c'est contraignant tout simplement parce que le langage n'a pas été prévu pour. 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.
Ma question c'est : ces variables locales peuvent-elles être des instances de classe, et alors leur constructeur et la libération de mémoire est-elle faite à la fin du bloc ?
Ok je n'avais pas compris. Quand on instancie un objet dans une méthode, la référence est effectivement libérée à la fin du bloc mais l'objet lui est toujours en mémoire et attends d'être éliminé par le GC. 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. Pour les autres variables (types primitifs), comme je le disais, le système est le même qu'en C++, elles sont détruites en fin de bloc.