Le C/C++ Me Conviendrait-il ?

Citation:

---

Envoyé par roulious

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.

Citation:

---

Envoyé par roulious

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++.

Citation:

---

Envoyé par roulious

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 :D 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.

Citation:

---

Envoyé par roulious

Comme la facilité de troller sur ses caracteristiques objet ? :D

---

Troll Power :twisted:

Citation:

---

Envoyé par Luc Hermitte

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 :lol:
Non, franchement ca m'interresse.

Citation:

---

Envoyé par zais_ethael

"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

Citation:

---

Envoyé par zais_ethael

Je me marre :D 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.

Citation:

---

Envoyé par roulious

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).

Citation:

---

Envoyé par Médinoc

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.

Citation:

---

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, ...

Citation:

---

Citation:

---

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" :?).

Citation:

---

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.

Citation:

---

Envoyé par Luc Hermitte

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.

Citation:

---

Envoyé par Luc Hermitte

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.

Citation:

---

Envoyé par Luc Hermitte

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).

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:

---

1 2 3

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

---

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