Discussion :

[epsilon68]

Attention, il ne faut pas imaginer que si l'on demande d'allouer 3 octet au GC via un new, il va faire un malloc à chaque coup. L'allocation est différente qu'en C ou qu'en C++ (avec les opérateurs classiques non modifiés)

ha bon alors comment il fait?

tu veux dire qu'il ne demande pas au system, il alloue plein de memoire au debut pour eviter cela, oui mais que cela change-t-il à la fin? (à part une allocation et deallocation plus rapide) en terme de memoire utilisée?

[alex_pi]

voila, c'est evident que une allocation sur le tas pour chaque objet.... ca fait mal mais point de salut

Tu veux les mettres où, sur la pile ? Faut arrêter, un langage avec GC ne fais pas un malloc à chaque nouvelle objet... Y a pas de nécessité à prendre plus de place sous prétexte que tu as un GC.

et surtout un GC se justifie-t-il dans ces conditions?
un model contient les faces, edges, vertices alors pas de ref circulaire, rien du tout, juste un destructeur qu'il faut implementer.... et c'est souvent comme ca.

Imaginons maintenant que tu aies une forme, et que tu la répètes à plusieurs endroit. Avec un peu de chance, tu peux faire du partage habile, et là "juste un destructeur" ne marche plus (oui, un smart_pointeur devrait le faire)

[millie]

ha bon alors comment il fait?

tu veux dire qu'il ne demande pas au system, il alloue plein de memoire au debut pour eviter cela, oui mais que cela change-t-il à la fin? (à part une allocation et deallocation plus rapide) en terme de memoire utilisée?

Ca dépend des GC. Le GC d'Ocaml (niveau allocation je parle) va être assez différent du GC de Java par exemple.

En java du moins, ça ressemble à une allocation sur la pile, (il y a un pointeur sur le tas qui est simplement déplacé :
http://bruce-eckel.developpez.com/li...e=chap4#L4.3.4 )

[Médinoc]

Mais ça reste, pour chaque objet, au moins 4 octets supplémentaires pour les informations de RTTI, et un niveau d'indirection supplémentaire.

Imaginons une classe Point avec juste deux entiers (x, y), aucune fonction virtuelle (une simple structure de stockage). Voyons ce que ça donne dans un tableau:

En C++, un pointeur --->

• objet Point de taille 8 à ptr+0
• objet Point de taille 8 à ptr+1
• objet Point de taille 8 à ptr+2

En java, un tableau d'objets, référence vers le tableau --->

• Référence de type du tableau
• tableau[0] = Référence vers objet Point --->
  
  • objet Point de taille au moins 12
• tableau[1] = Référence vers objet Point --->
  
  • objet Point de taille au moins 12
• tableau[2] = Référence vers objet Point --->
  
  • objet Point de taille au moins 12

[Médinoc]

Mais ceci n'est pas en soi un problème dû au garbage collector: Je suis sûr qu'en .Net on peut parvenir à des performances mémoire voisines du C++, puisqu'en .Net on a droit aux "types valeurs", qu'on peut mettre dans un tableau.

[millie]

tableau[0] = Référence vers objet --->

• objet de taille au moins 12

Je ne comprend pas bien. C'était pas des entiers dans ta structure ? Un entier de type int en java n'est pas un objet. Ou bien, quelque chose m'a échappé.

[Luc Hermitte]

el_slapper, je pense que tu as soulevé un point intéressant au sujet des formations, mais attention à 3 autres éléments :
- tous les développeurs n'ont pas une formation de développeur. Il n'est pas rare d'avoir des ingénieurs formés relativement à un métier qui se retrouvent à développer dans des équipes où pendant ce temps des développeurs de formations découvrent le métier.

- même quand on est bien formés et super douées, nous restons des humains et on a vite fait d'oublier une désallocation suite à une soirée trop arrosée, ou une nuit trop courte, ou des interruptions répétées par le client, ou ...

- les erreurs. Gérer correctement les cas non nominaux est le détail qui change toute la donne. Faire ça à la main et de façon maintenable relève de l'impossible. Même des développeurs de formation sont (généralement?) incorrectement formés à cela. D'autant que cela n'a pas du tout la même criticité selon les applications. Les GC sont une solution partielle à ce problème.

[Médinoc]

Je ne comprend pas bien. C'était pas des entiers dans ta structure ? Un entier de type int en java n'est pas un objet. Ou bien, quelque chose m'a échappé.

Ça t'a bien échappé, mais je viens de clarifier mon message pour que ça n'échappe plus à personne.

[millie]

Ça t'a bien échappé, mais je viens de clarifier mon message pour que ça n'échappe plus à personne.

Ah oui, le mot "tableau" m'avait échappé. C'était pour ça

[epsilon68]

Mais ceci n'est pas en soi un problème dû au garbage collector: Je suis sûr qu'en .Net on peut parvenir à des performances mémoire voisines du C++, puisqu'en .Net on a droit aux "types valeurs", qu'on peut mettre dans un tableau.

oui mais plus d'heritage ... et plein d'inconvenients, ce n'est pas un objet donc plein de boxing / unboxing

[Médinoc]

ce n'est pas un objet donc plein de boxing / unboxing

Seulement si tu cherches à le traiter comme un objet. Si, au lieu de chercher à l'identifier par un simple pointeur, tu l'identifies par tableau+index, pas de boxing à l'horizon. Pareil si tu le passes par référence (encore un truc que Java ne sait pas faire) à une fonction...

[epsilon68]

Tu veux les mettres où, sur la pile ? Faut arrêter, un langage avec GC ne fais pas un malloc à chaque nouvelle objet... Y a pas de nécessité à prendre plus de place sous prétexte que tu as un GC.

je ne suis pas d'accord!

Code :

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

1
2
3
4
5
6
class Triangle {
private:
  Plane p1, p2, p3 // ou Plane boundaries[3]
  Plane face;
  Normal n;
};

tu vois je n'ai pas de pointeurs à l'interieur de mon triangle
cela me prend donc:
1 plane = 4 doubles = 32 octets
1 normal = 3 doubles = 24 octets

donc 3*32 + 1*32 + 1*24 = 152 octets

et en Java ?

Imaginons maintenant que tu aies une forme, et que tu la répètes à plusieurs endroit. Avec un peu de chance, tu peux faire du partage habile, et là "juste un destructeur" ne marche plus (oui, un smart_pointeur devrait le faire)

je n'ai aucun probleme, les references circulaires sont tres tres rares, et dans ce cas que tu cites j'ai no problemo, c'est un cas somme toute assez trivial, il suffirait de donner la responsabilité de destruction à un objet separé de cette fameuse liste... meme pas forcement besoin de smart-pointer

[epsilon68]

Seulement si tu cherches à le traiter comme un objet. Si, au lieu de chercher à l'identifier par un simple pointeur, tu l'identifies par tableau+index, pas de boxing à l'horizon. Pareil si tu le passes par référence (encore un truc que Java ne sait pas faire) à une fonction...

c'est pas le but d'etre objet dans un langage objet?

vouloir traiter des cas a part, c'est des problemes à gerer pour plus tard. Ces structures dans C# sont merdiques, ils auraient mieux fait d'etre consistent, d'ameliorer la gestion memoire des objets plutot que d'inventer encore un nouveau type :-/

J'avais vu dans Java 3d, la lib Vecmath leur optimisation avait consisté à mettre non pas des objets points dans les plans mais le contenu (des doubles ou float) ... c'est ce genre d'optimisation que vous voulez en Java?

[ptah35]

A mon avis, une "déstruction" déterministe et l'utilisation d'un GC ne devrait pas être opposés. En effet, le rôle du GC est de gérer la mémoire, pas celui de gérer n'importe quelle resource partagée. Si une classe représente une resource partager, il est selon moi plus correcte d'avoir des métodes du genre "open/close" ou "connect/disconnect", plutôt de de lier ces actions uniquement à la construction et à la desctruction des objets - même si c'est sans aucun doute une bonne idée de relacher la resource partagée à la destruction de l'objet.

[Médinoc]

Le problème de java, c'est justement qu'on se retrouve à payer pour de l'objet même dans les cas où l'on n'a pas besoin d'objet.
Le C++ est excellent pour éviter de payer pour ce qu'on n'utilise pas, et les value types de .Net sont un bon compromis pour les POD, même s'ils n'ont pas toutes les fonctionnalités qu'on pourrait vouloir.

Edit: J'en profite pour rajouter cet article sur la philosophie des types valeurs en .Net : http://blogs.msdn.com/slippman/archi...13/131225.aspx

[epsilon68]

de nos jours c'est quand meme tres dure d'oublier un delete.

les seules fois ou j'en fais c'est dans les destructeurs...
sinon c'est tres tres tres rare...

[Luc Hermitte]

de nos jours c'est quand même très dur d'oublier un delete.

les seuls fois ou j'en fais c'est dans les destructeurs...
sinon c'est tres tres tres rare...

Parce que le langage que nous utilisons nous permet de ne pas en écrire (ou du moins le moins possible) et sans provoquer la moindre fuite.

[Garulfo]

Le problème de java,[...]

Java n'est pas la panacée des GC surtout -_-
Il y a mieux.

[davcha]

Ceci est un problème de conception et non de langage ou de "feature" du langage.

Que ce soit "aucune abstraction au niveau de la source de données" ou "la source de données n'est plus une base de données", c'est indépendant du langage et fait partie de l'analyse (mauvaise) des concepteurs...

[...]

Tu ne me convaincs pas avec tes arguments car ce que tu montres sont des problèmes de conception.


Si n'importe qui pense qu'il peut faire un bon programme, tant pis pour lui et ceux qui l'emploient..


Et c'était exactement le sens de ma remarque initiale...

Ca tombe bien que tu parles de "mauvaise conception" (en fait j'espérais que tu allais en parler).
En gros, l'idée est que si tu réalises un programme qui a pour but d'effectuer le travail A, tu souhaites que la majorité du code du programme en question soit du "A" et pas un aspect technique B, C ou D.
Je suis peut-être pas très clair...

Reprenons l'histoire de notre programme de gestion avec une base de données ou un service web derrière.
Si ton appli de gestion traite des fleurs sauvages et de leurs relations avec les ours et la pollution, tu veux que la majorité du code soit relatif aux fleurs, aux ours et à la pollution.
Inversement, tu souhaites éviter un maximum toute référence à des librairies techniques, par exemple.

Tu vas me dire que la gestion de la mémoire, ce n'est pas une librairie technique, et tu auras raison. Par contre, si dans ton code tu as à tout bout de champ des tas d'allocations mémoires (même bien foutues, hein, je parle pas d'une allocation mémoire dans une triple boucle imbriquée, par exemple), ça "pollue" ton code.
Toutes ces allocations mémoires sont du ressort de l'ordinateur, ça n'a rien à voir avec la logique qui régit les fleurs sauvages, les ours et la pollution.
Ca pollue, donc. Et par conséquent, rend ton code moins lisible, plus difficile à maintenir, etc...

Alors, maintenant, GC ou pas GC, c'est un peu une autre histoire à la limite.
Il me semble que c'est Luc qui a parlé d'avoir des smart_pointers (ou autres) aussi invisibles que possible.

D'après moi, l'idéal est de savoir comment ça marche derrière, mais de voir cette mécanique le moins possible.

Mais ceci n'est pas en soi un problème dû au garbage collector: Je suis sûr qu'en .Net on peut parvenir à des performances mémoire voisines du C++, puisqu'en .Net on a droit aux "types valeurs", qu'on peut mettre dans un tableau.

On peut faire un stackalloc et un autre truc dont je me sers si peu souvent que j'ai oublié comment ça s'appelait. Ca permet d'avoir la même chose qu'un tableau initialisé sur la pile en C++. Ca nécessite de créer un type valeur particulier pour contenir le truc, par contre.

Ceci dit, tout ça c'est unsafe.

[Luc Hermitte]

Il me semble que c'est Luc qui a parlé d'avoir des smart_pointers (ou autres) aussi invisibles que possible.

J'ai dit toutes sortes de choses. Mais la seule qui pourrait se rapprocher c'est que je concédais que les smart_pointeurs du C++ étaient un chouilla verbeux (si non aliasés par des typedef). Ou alors que gérer des ressources brutes (pas juste la mémoire) au milieu d'un code où il fallait anticiper les cas non nominaux relève de l'impossible. Et que ce que je ne veux pas voir ce sont des if(ok)-else et autres try-finally à n'en plus finir.

Maintenant, quelle est l'importance de la gestion des insectes et pesticides, et autres brebis et éleveurs dans ton modèle de fleurs et d'ours ?
OK, l'analogie est pourrie. Le truc est que les cas non nominaux relèvent aussi du métier, et vont concerner des ressources métier qu'il faut aussi gérer correctement. Et je ne veux pas plus me poser de questions au sujet de la mémoire que des autres ressources, métiers (pots de bladan et autres insecticides à refermer et ranger après utilisation) ou non (i.e. plus techniques comme des connexions DB, sockets, mémoire, etc), que je pourrais être appelé à manipuler.


Donc (comme je le disais il y a des pages et des pages de cela) les GC, pourquoi pas, mais je veux plus. Et tous les GC ne me l'offrent pas -- du moins ceux des langages qui sont en directe concurrence avec celui que j'utilise professionnellement aujourd'hui. (je fais ce que je peux pour éviter le troll langage, mais ce n'est pas facile vu que les qualités des GC varient d'un langage à l'autre, de même que les techniques plus ou moins alternatives, cf les digressions récentes)