> De plus, désolé de le dire, mais ce post ne reflétait pas vraiment l'expérience d'un développeur confirmé...
Et pourtant, il suffit de regarder l'évolution des langages de programmations au fil des ans pour voir qu'ils sont de plus en plus haut niveau et libèrent le développeur de plus en plus de détails.
> Quand je fais du développement, c'est plutôt axé système
Dans ce cas là je comprends bien qu'un GC te semble inutile et lourd. Mais dans beaucoup d'autres domaines, c'est extrèmement utile.
> Je voulais attirer l'attention sur le fait que le GC à un cout non négligeable en termes de perf, et que heureusement il y a bien des projets ou l'on peut s'en passer.
Personne ne dit le contraire. Maintenant, quand un GC divise par 3 le temps de développement, le cout en perfs tu t'en tapes un peu, il suffit de prendre une machine plus grosse. Ça coute moins cher que de payer tes développeurs 3 fois plus longtemps sur le même truc.
> L'implémentation "forcée" de GC comme dans java me semble
Elle n'est pas forcée, elle est absolument nécéssaire, et tout les futurs langages destinés à occuper la même place que Java auront un GC. Je n'imagine pas qu'un langage ou le programmeur a la charge de la gestion mémoire puisse, si il apparaissait aujourd'hui, avoir un quelconque succès.
> on y voit aussi que le type de MS voudrait bien se passer de GC si il pouvait pour son projet
Il me semble plutôt qu'il voudrait avoir une destruction deterministe dans certains cas. Il conclut que c'est impossible de faire cohabiter ça avec un GC.
> Pourquoi des pointeurs vers une chaine interne à l'objet devraient-ils être conservés en dehors de l'objet ?
Imagine le menu de la liste des fenetres d'un window manager par exemple (bon, c'est pas implémenté comme ça sous X, mais ça pourrait l'être...). Et puis il pourrait y avoir une taskbar aussi, c'est courant. Donc 2 objets différents qui doivent garder un pointeur vers le nom.
Et si tu me dis que la Fenetre devrait signaler à ListeDesFenetres et à Taskbar qu'elle est effacée, ça veut dire que Fenetre contient un pointeur vers ListeDesFenetres et Taskbar, ce qui n'est pas terrible coté encapsulation... Sans compter que pour chaque nouvel objet qui garde un pointeur vers _nom, tu vas devoir modifier l'implémentation de Fenetre. Et je te laisse imaginer la source d'erreurs que cela devient quand tu dépasses les 10 klocs.
La bonne solution est tout simplement d'utiliser std::string (ou QString :-). Mais ça n'est pas toujours aussi simple.
Comme tu le disais, on fait souvent des compteurs de références sur des ressources. C'est un boulot con, systématique, répétitif, et dans lequel il est très facile de faire des erreurs - ou plutôt il est impossible de ne pas en faire. Il est donc normal que la machine le fasse pour toi, c'est son boulot, et contrairement à ce que tu penses elle le fera le plus souvent bien mieux que toi. De la même façon que malloc()/free() ont libéré le programmeur du boulot con qu'était de gerer soi-même les zones mémoires où tu allais loger tes data. C'est pas gratuit, il y a un overhead, malloc va t'allouer 4Kb quand tu lui demande 10 bytes (je dis ça un peu au pif, ça dépend des implémentations), mais tu laisses la machine s'occuper de ça, c'est tout ce qui compte.
[^] # Re: Comment ça marche ?
Posté par Guillaume Laurent . En réponse à la dépêche Al Stevens n'aime pas QT. Évalué à 3.
Et pourtant, il suffit de regarder l'évolution des langages de programmations au fil des ans pour voir qu'ils sont de plus en plus haut niveau et libèrent le développeur de plus en plus de détails.
> Quand je fais du développement, c'est plutôt axé système
Dans ce cas là je comprends bien qu'un GC te semble inutile et lourd. Mais dans beaucoup d'autres domaines, c'est extrèmement utile.
> Je voulais attirer l'attention sur le fait que le GC à un cout non négligeable en termes de perf, et que heureusement il y a bien des projets ou l'on peut s'en passer.
Personne ne dit le contraire. Maintenant, quand un GC divise par 3 le temps de développement, le cout en perfs tu t'en tapes un peu, il suffit de prendre une machine plus grosse. Ça coute moins cher que de payer tes développeurs 3 fois plus longtemps sur le même truc.
> L'implémentation "forcée" de GC comme dans java me semble
Elle n'est pas forcée, elle est absolument nécéssaire, et tout les futurs langages destinés à occuper la même place que Java auront un GC. Je n'imagine pas qu'un langage ou le programmeur a la charge de la gestion mémoire puisse, si il apparaissait aujourd'hui, avoir un quelconque succès.
> on y voit aussi que le type de MS voudrait bien se passer de GC si il pouvait pour son projet
Il me semble plutôt qu'il voudrait avoir une destruction deterministe dans certains cas. Il conclut que c'est impossible de faire cohabiter ça avec un GC.
> Pourquoi des pointeurs vers une chaine interne à l'objet devraient-ils être conservés en dehors de l'objet ?
Imagine le menu de la liste des fenetres d'un window manager par exemple (bon, c'est pas implémenté comme ça sous X, mais ça pourrait l'être...). Et puis il pourrait y avoir une taskbar aussi, c'est courant. Donc 2 objets différents qui doivent garder un pointeur vers le nom.
Et si tu me dis que la Fenetre devrait signaler à ListeDesFenetres et à Taskbar qu'elle est effacée, ça veut dire que Fenetre contient un pointeur vers ListeDesFenetres et Taskbar, ce qui n'est pas terrible coté encapsulation... Sans compter que pour chaque nouvel objet qui garde un pointeur vers _nom, tu vas devoir modifier l'implémentation de Fenetre. Et je te laisse imaginer la source d'erreurs que cela devient quand tu dépasses les 10 klocs.
La bonne solution est tout simplement d'utiliser std::string (ou QString :-). Mais ça n'est pas toujours aussi simple.
Comme tu le disais, on fait souvent des compteurs de références sur des ressources. C'est un boulot con, systématique, répétitif, et dans lequel il est très facile de faire des erreurs - ou plutôt il est impossible de ne pas en faire. Il est donc normal que la machine le fasse pour toi, c'est son boulot, et contrairement à ce que tu penses elle le fera le plus souvent bien mieux que toi. De la même façon que malloc()/free() ont libéré le programmeur du boulot con qu'était de gerer soi-même les zones mémoires où tu allais loger tes data. C'est pas gratuit, il y a un overhead, malloc va t'allouer 4Kb quand tu lui demande 10 bytes (je dis ça un peu au pif, ça dépend des implémentations), mais tu laisses la machine s'occuper de ça, c'est tout ce qui compte.