Déjà, il est faux de dire (comme le faisait un post plus haut) que les interfaces de Go sont "équivalents" aux templates de C++.
Je ne disais pas ça, je disais qu'avec des templates C++ (et les concepts qui ne font pas encore partie de C++), on avait un équivalent des interfaces Go. Certes, on peut faire beaucoup plus de choses avec les templates, mais je n'en ai absolument pas parlé.
Mais à force de se focaliser sur des détails bas niveau sans grand intérêt, on se fossilise dans des conceptions dépassées qui sont au final moins performantes.
Déjà croire que les GC sont la solution miracle à tous les problèmes d'allocation mémoire, c'est se mettre le doigt dans l'oeil parce qu'un GC n'est jamais parfait. Ensuite, dans certains domaines comme l'embarqué, la consommation mémoire doit être strictement encadrée parce qu'il y en a peu. Et c'est plus souvent ce point qui pousse à utiliser une allocation manuelle que la "performance". Il est montré qu'un GC peut être aussi performant que l'allocation manuelle mais qu'il prend 5 fois plus de mémoire !
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 2.
Je ne disais pas ça, je disais qu'avec des templates C++ (et les concepts qui ne font pas encore partie de C++), on avait un équivalent des interfaces Go. Certes, on peut faire beaucoup plus de choses avec les templates, mais je n'en ai absolument pas parlé.
Déjà croire que les GC sont la solution miracle à tous les problèmes d'allocation mémoire, c'est se mettre le doigt dans l'oeil parce qu'un GC n'est jamais parfait. Ensuite, dans certains domaines comme l'embarqué, la consommation mémoire doit être strictement encadrée parce qu'il y en a peu. Et c'est plus souvent ce point qui pousse à utiliser une allocation manuelle que la "performance". Il est montré qu'un GC peut être aussi performant que l'allocation manuelle mais qu'il prend 5 fois plus de mémoire !