Discussion :

[zais_ethael]

Non. Les smart pointer ajoutent de l'intelligence aux pointeurs, c'est tout. Pour les smart pointers qui font du comptage de référence, on peut s'en servir comme ramasse miettes, mais ça n'est pas leur seul usage.

"Smart pointeur à comptage de réfèrence" c'est long à taper, et tout le monde connait pas forcément le shared_ptr.

Dans quelle définition ? Quel le rapport entre la taille d'une variable en mémoire et les caracteristiques objet d'un langage donné ?

Il est vrai que dans le concept objet, un objet n'est défini que par les méthodes qu'il offre. Néanmoins, techniquement, un objet doit bien contenir des données - leurs tailles variant d'une classe dérivée à l'autre. D'où le fait que ce concept est incompatible avec la création des variables sur la pile comme en C/C++.

C'est souvent la preuve d'une erreur de conception dès le début. En démarrant un projet, il vaut mieux perdre du temps à bien le concevoir, qu'à se faire une petite classe dont dépend le projet et qu'on devra jeter par la suite.

Je me marre Alors toi tu fais un programme et tu n'as jamais besoin de revenir sur ta décision? Un bout de code tapé c'est un bout de code jamais réécris? Ca m'a l'air encore pire que de mal concevoir une applic. En java, tant qu'on essaye de bien réutiliser le code c'est assez facile de modifier l'architecture - en C++ pas.

Comme la facilité de troller sur ses caracteristiques objet ?

Troll Power

[zais_ethael]

Empécher la dérivation publique est plus difficile (il y a un hack pour y parvenir), là il faut partir dans l'éducation des masses.

Ben justement, tu pourrais m'expliquer
Non, franchement ca m'interresse.

[roulious]

"Smart pointeur à comptage de réfèrence" c'est long à taper, et tout le monde connait pas forcément le shared_ptr.

En parlant de comptage de référence, je disais que les smart pointers ne servaient pas qu'à faire du ramasse miette, voir ce thread (en anglais) : http://groups.google.fr/group/comp.l...e9ab72ae0a19b8

Je me marre Alors toi tu fais un programme et tu n'as jamais besoin de revenir sur ta décision? Un bout de code tapé c'est un bout de code jamais réécris?

J'ai l'impression que tu mélanges un peu l'interface des classes/fonctions/... avec ce qu'il y a dedans. L'interface (ce qui est destiné au client de tes classes) doit rester le plus fixe possible pour casser le moins de choses possibles lorsque tu t'apperçois que tu as fait hériter une classe Carre d'une classe Rectangle. Après ça, tu peux bidouiller en interne tant que tu veux, les utilisateurs de ton code n'en voient rien.

[zais_ethael]

J'ai l'impression que tu mélanges un peu l'interface des classes/fonctions/... avec ce qu'il y a dedans. L'interface (ce qui est destiné au client de tes classes) doit rester le plus fixe possible pour casser le moins de choses possibles lorsque tu t'apperçois que tu as fait hériter une classe Carre d'une classe Rectangle. Après ça, tu peux bidouiller en interne tant que tu veux, les utilisateurs de ton code n'en voient rien.

Non, je parlais bien de l'interface. L'ennui, pour reprendre les mots de luc, c'est que si on crée une classe selon la sémantique par valeur on ne peut pas la transferer aisément vers celle par entité. Le problème est bien entendu que tout programme est appelé à changer - quand bien même il était très bien concu à la base (durée de vie moyenne d'un programme = 10 ans - impossible de prévoir tout pendant la première phase de conception).

[Luc Hermitte]

Corrigez-moi si je me trompe, mais pour moi, le ramasse-miettes est un complément du comptage de références (pointeurs intelligents) : Selon ce que j'ai compris, le ramasse-miettes sert à libérer ce que le comptage de référence n'a pas pu libérer automatiquement: Les groupes inacessibles d'objets qui se référencent entre eux ("références cycliques")

Je ne dirais pas complémentaire. C'est différent. Je me vois difficilement utiliser les deux sur des mêmes données. Avec les pointeurs intelligents les durées de vie restent maitrisées/implicitement connues, comme il l'a été dit plus loin.
Les GC sont plus simples à manipuler dans les cas de références cycliques -- et encore, j'ai lu (rumeur sur internet, tout ça) que le premier GC de Java n'en était pas capable. Avec les pointeurs intelligents (ceux à comptage de référence) il y a quand même moyen de contourner les problèmes de références cycliques, mais cela demande à ce que l'on distribue les responsabilités dans les cycles.

(Il me semble, qu'il y a une variété de pointeurs intelligents qui savent malgré tout s'en sortir).

Sur le lien que j'avais donné, il y a un mini "encart" sur les pointeurs intelligents.

Il est vrai que dans le concept objet, un objet n'est défini que par les méthodes qu'il offre. Néanmoins, techniquement, un objet doit bien contenir des données - leurs tailles variant d'une classe dérivée à l'autre. D'où le fait que ce concept est incompatible avec la création des variables sur la pile comme en C/C++.

Un objet ne contient pas nécessairement des données. Tu sembles systématiquement associer des objets à des entités. Une fois de plus, cela n'a pas à être nécessaire -> matrices, chaines de caractères, ...

Empécher la dérivation publique est plus difficile (il y a un hack pour y parvenir), là il faut partir dans l'éducation des masses.

Ben justement, tu pourrais m'expliquer
Non, franchement ca m'interresse.

Je suppose que tu fais référence au hack qui interdit la dérivation.
Hop : http://www.developpez.net/forums/showthread.php?t=42040 (c'était compliqué à retrouver -- je suis passé par "virtual" et "protected" ).

Non, je parlais bien de l'interface. L'ennui, pour reprendre les mots de luc, c'est que si on crée une classe selon la sémantique par valeur on ne peut pas la transferer aisément vers celle par entité. Le problème est bien entendu que tout programme est appelé à changer - quand bien même il était très bien concu à la base (durée de vie moyenne d'un programme = 10 ans - impossible de prévoir tout pendant la première phase de conception).

Les projets peuvent effectivement évoluer au fil des Demandes de Modification reçues. Surtout si ils durent et que beaucoup de personnes différentes sont passées dessus. Mais ce qui est clair, c'est qu'un changement de sémantique peut s'avérer couteux. Mais bon. Perso je préfère ça à ne pas avoir le choix entre ces deux sémantiques pour mes classes.

[zais_ethael]

Avec les pointeurs intelligents les durées de vie restent maitrisées/implicitement connues, comme il l'a été dit plus loin.

Je ne suis pas d'accord. Certes avec un shared_ptr, par exemple, on sait que l'objet sera détruit quand il ne sera plus réfèrencé. Mais sait-on seulement "quand" il ne sera plus réfèrencé? Prenons le cas d'un objet encapsulant un handler de bas niveau: une socket faisant serveur. Il est très interessant de pouvoir gérer correctement le cycle de vie de cet objet (pour savoir quand le serveur occupe le port). Avec un shared_ptr on ne peut être sur qu'il n'existe plus de réfèrences. On a donc que deux solutions: pas de shared_ptr ou mettre un booléen dans l'objet pour savoir si le handler est toujours actif(ce qu'on ferait en java). Ou alors on essaye de surveiller tout le projet pour être sur de ne pas faire de bétise (pas bon ca). Bref ca montre bien que le problème est le même avec ou sans GC -> on ne controle pas vraiment la durée de vie de l'objet.

Un objet ne contient pas nécessairement des données. Tu sembles systématiquement associer des objets à des entités. Une fois de plus, cela n'a pas à être nécessaire -> matrices, chaines de caractères, ...

Si tu veux dire que certain objets ne contiennent pas de données, soit, mais il y en a forcément qui en contiennent aussi, l'un des interets de l'orienté objet étant de ne pas avoir à s'en préoccuper.

Mais ce qui est clair, c'est qu'un changement de sémantique peut s'avérer couteux. Mais bon. Perso je préfère ça à ne pas avoir le choix entre ces deux sémantiques pour mes classes.

A part pour des questions d'optimisation, je ne vois pas l'interet. Remarque c'est important aussi, mais pas dans tous les projets (montage vidéo = bien, applic de facturation = pas besoin).

[JolyLoic]

Le choix de sémantique n'a aucun rapport avec l'optimisation.

Pour une classe gérant des comptes banquaires, une sémantique de valeur serait désastreuse : Un compte banquaire pourrait être copié, on pourrait modifier une copie et pas l'autre, un client aurait donc plusieurs soldes différents...

Pour une classe gérant des grandeurs physiques, une sémantique par entité serait désastreuse. Quand je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
a = 1;
b = a;
a = 2;

Je n'ai absolument pas envie que b==2.