Pourquoi des langages tels que C et C ++ nont pas de garbage collection, contrairement à Java? [fermé]

La collecte des ordures nécessite des structures de données pour suivi des allocations et / ou comptage des références. Ceux-ci créent une surcharge de mémoire, de performances et de complexité du langage. C ++ est conçu pour être « proche du métal », en dautres termes, il prend le côté plus performant des fonctionnalités de compromis par rapport à la commodité. Dautres langues font ce compromis différemment. Cest lune des considérations lors du choix dune langue que vous préférez.

Cela dit, il existe de nombreux schémas de comptage de références en C ++ qui sont assez légers et performants, mais ils se trouvent dans des bibliothèques, à la fois commerciales et open source, plutôt que dans le langage lui-même. Le comptage de références pour gérer la durée de vie des objets nest pas la même chose que le ramasse-miettes, mais il résout bon nombre des mêmes types de problèmes et correspond mieux à lapproche de base de C ++.

Commentaires

• Un problème secondaire est que le GC nest pas déterministe. Lobjet peut ou non être encore en mémoire longtemps après que le programme a " supprimé " it. Les cycles de vie Refcount sont déterministes, lorsque la dernière référence est supprimée, la mémoire est supprimée. Cela a des implications non seulement pour lefficacité de la mémoire, mais également pour le débogage. Une erreur de programmation courante est lobjet " zombie ", mémoire de référence qui a théoriquement été supprimée. GC est beaucoup plus susceptible de masquer cet effet et de produire des bogues qui sont intermittents et extrêmement difficiles à retracer.
• – les gc modernes ' ne suivent pas les allocations ni ne comptent les références. Ils construisent un graphique à partir de la veille rything actuellement sur la pile et juste condenser et effacer tout le reste (simplifié), et GC entraîne normalement une complexité de langage réduite . Même l’amélioration des performances est discutable.
• Euh, @kylben, l’intérêt d’avoir un GC automatique dans le langage est qu’il devient impossible de référencer des objets zombies, car le GC ne libère que les objets impossibles à référencer! Vous obtenez le genre de bogues difficiles à suivre dont vous ' parlez lorsque vous faites des erreurs avec la gestion manuelle de la mémoire.
• -1, GC ne compte pas les références. De plus, en fonction de votre utilisation de la mémoire et de votre schéma dallocation, un GC peut être plus rapide (avec une surcharge dutilisation de la mémoire). Largument concernant la performance est donc également une erreur. Seul le proche du métal est un point valide en fait.
• Ni Java ni C # nutilisent le comptage de références: les schémas GC basés sur le comptage de références sont assez primitifs en comparaison et fonctionnent bien moins bien que les garbage collector modernes (principalement parce quils besoin de faire des écritures en mémoire pour modifier le nombre de références chaque fois que vous copiez une référence!)

Strictement parlant, il ny a pas du tout de gestion de la mémoire en langage C. malloc () et free () ne sont pas des mots-clés dans le langage, mais simplement des fonctions appelées à partir dune bibliothèque.Cette distinction peut être pédante maintenant, car malloc () et free () font partie de la bibliothèque standard C, et seront fournies par toute implémentation conforme à la norme C, mais ce nétait pas toujours vrai dans le passé.

Pourquoi voudriez-vous un langage sans standard pour la gestion de la mémoire? Cela remonte aux origines de C en tant qu « assemblage portable ». Il existe de nombreux cas de matériel et dalgorithmes qui peuvent bénéficier, voire exiger, des techniques de gestion de mémoire spécialisées. Pour autant que je sache, il ny a aucun moyen de désactiver complètement la gestion de la mémoire native de Java et de la remplacer par la vôtre. Ce nest tout simplement pas acceptable dans certaines situations de hautes performances / ressources minimales. C offre une flexibilité presque complète pour choisir exactement quelle infrastructure votre programme va utiliser. Le prix payé est que le langage C fournit très peu daide pour écrire un code correct et sans bogue.

Commentaires

• +1 un pour la bonne réponse globale, mais aussi surtout pour " Le prix payé est que le langage C fournit très peu daide pour écrire un code correct et sans bogue "
• C a une gestion de la mémoire – mais cela fonctionne, donc les gens le remarquent à peine. Il y a ' la mémoire statique, les registres et le Jusquà ce que vous commenciez à allouer hors du tas, vous ' allez bien et dandy. Cela ' est lallocation de tas qui gâche les choses . Comme pour Java, chacun peut écrire son propre environnement dexécution Java – il y a beaucoup de choix parmi ', y compris ce que lon pourrait appeler " System ' s Java ". .NET peut faire à peu près tout ce que C peut – il est seulement en retard sur les capacités natives de C ++ ' (par exemple, les classes sont gérées uniquement dans .NET). Bien sûr, vous avez aussi C ++. NET, qui contient tout ce que fait C ++, et tout ce que fait .NET.
• @Luaan I ' d dire que ' est une définition très généreuse davoir " gestion de la mémoire " " Jusquà ce que vous commenciez à allouer hors du tas, vous ' allez bien et dandy. ' est lallocation de tas qui gâche les choses ", cela ' est comme dire une voiture est un très bon avion, il nest simplement pas ' capable de voler.
• @ CharlesE.Grant Eh bien, un langage purement fonctionnel peut tout faire avec ça sorte de gestion de la mémoire. Ce nest pas ' que lallocation de tas est un bon compromis dans certains cas dutilisation quelle ' est la référence pour toutes les langues / environnements dexécution . Ce ' nest pas comme si la gestion de la mémoire cesse dêtre " gestion de la mémoire " simplement parce quelle ' est simple, direct, caché dans les coulisses. La conception de lallocation de mémoire statique est toujours une gestion de la mémoire, tout comme une bonne utilisation de la pile et de tout ce dont vous disposez.
• " toute implémentation conforme à la norme " nest pas vrai, uniquement pour limplémentation dun environnement hôte conforme à la norme. Certaines plates-formes / bibliothèques standard, la plupart pour les microcontrôleurs embarqués 8 ou 16 bits, ne fournissent pas malloc() ou free(). (par exemple, MLAP-Compilers for PIC)

La vraie réponse est que la seule façon de faire un mécanisme de récupération de place sûr et efficace consiste à avoir une prise en charge au niveau de la langue pour les références opaques. (Ou, au contraire, un manque de support au niveau du langage pour la manipulation directe de la mémoire.)

Java et C # peuvent le faire car ils ont des types de référence spéciaux qui ne peuvent pas être manipulés. Cela donne au runtime la liberté de faire des choses comme déplacer les objets alloués en mémoire , ce qui est crucial pour une implémentation GC haute performance .

Pour mémoire, aucune implémentation moderne du GC nutilise le comptage de références , donc cest complètement rouge hareng. Les GC modernes utilisent la collection générationnelle, où les nouvelles allocations sont traitées essentiellement de la même manière que les allocations de pile sont dans un langage comme C ++, puis périodiquement tous les objets nouvellement alloués qui sont encore en vie sont déplacés vers un espace « survivant » séparé, et une génération entière des objets est désalloué à la fois.

Cette approche a des avantages et des inconvénients: lavantage est que les allocations de tas dans un langage prenant en charge GC sont aussi rapides que les allocations de pile dans un langage qui ne prend pas en charge GC, et linconvénient est que les objets qui doivent effectuer un nettoyage avant dêtre détruits nécessitent soit un mécanisme séparé (par exemple, C # » s using) ou bien leur code de nettoyage sexécute de manière non déterministe.

Notez quune des clés dun GC haute performance est quil doit y avoir un support de langage pour une classe spéciale de références. C ne prend pas en charge ce langage et ne le fera jamais; parce que C ++ a une surcharge dopérateurs, il pourrait émuler un type de pointeur GC « d, bien que cela doive être fait avec soin. En fait, lorsque Microsoft a inventé leur dialecte de C ++ qui fonctionnerait sous le CLR (le runtime .NET), ils ont dû inventer une nouvelle syntaxe pour les «références de style C #» (par exemple Foo^) pour les distinguer des « références de style C ++ » (par exemple Foo&).

Ce que C ++ a, et ce qui est régulièrement utilisé par les programmeurs C ++, est pointeurs intelligents , qui ne sont en réalité quun mécanisme de comptage de références. Je ne considérerais pas le comptage de références comme un « vrai » GC, mais il offre beaucoup des mêmes avantages, au prix de performances plus lentes que la gestion manuelle de la mémoire ou le vrai GC, mais avec lavantage de la destruction déterministe.

À la fin de la journée, la réponse se résume vraiment à une fonctionnalité de conception de langage. C a fait un choix, C ++ a fait un choix qui lui a permis dêtre rétrocompatible avec C tout en fournissant des alternatives qui sont assez bonnes pour la plupart des objectifs, et Java et C # ont fait un choix différent qui est incompatible avec C mais qui est également assez bon pour la plupart des applications. Malheureusement, il ny a pas de solution miracle, mais connaître les différents choix disponibles vous aidera à choisir le bon quel que soit le programme que vous essayez de créer.

Commentaires

• Voici la réponse à la question
• Pour la partie c ++, de nos jours vous devriez regarder std :: unique_ptr et std :: move 🙂
• pas dimplément GC moderne entation utilise le comptage de références : cPython utilise à la fois le comptage de références et la collecte automatique .
• @ Mike76: Du côté de lallocation, un allocateur GC fonctionnera à peu près aussi vite que lallocation de pile, et le GC peut désallouer des milliers dobjets en même temps. Peu importe ce que vous faites avec une implémentation de comptage de ref, lallocation et la désallocation ne seront jamais plus rapides que malloc et free. Alors oui, un GC peut être beaucoup plus rapide. (Notez que jai dit que " peut être " – bien sûr, les performances exactes de chaque programme sont affectées par de nombreux facteurs.)
• aucune implémentation moderne du GC nutilise le comptage des références Swift utilise le comptage automatique des références.

Parce que, lorsque vous utilisez la puissance du C ++, ce nest pas nécessaire.

Herb Sutter: » Je « nai » pas écrit de suppression depuis des années.  »

voir Écrire du code C ++ moderne: comment le C ++ a évolué au fil des ans 21:10

Cela peut en surprendre beaucoup programmeurs C ++ expérimentés.

Commentaires

• Intéressant. Mon matériel de lecture pour aujourdhui.
• Bah, une vidéo. Mais jamais moins, déjà intéressante.
• vidéo intéressante. 21 minutes et 55 minutes ont été les meilleurs morceaux. Dommage que les appels WinRT semblaient toujours être des bumpf C ++ / CLI.
• @ dan04: Cela ' est vrai. Mais alors, si vous écrivez en C, vous obtenez ce que vous demandez.
• La gestion des pointeurs intelligents n’est pas plus exigeante que de s’assurer de ne pas ' t avoir des références inutiles dans un environnement garbage collection. Parce que GC ne peut ' lire dans vos pensées, ce nest ' pas magique non plus.

« Tout » un garbage collector est un processus qui sexécute périodiquement pour vérifier sil y a des objets non référencés en mémoire et sil y en a des suppressions. (Oui, je sais que cest une simplification excessive). Ce nest pas une propriété du langage, mais du framework.

Il existe des garbage collector écrits pour C et C ++ – celui-ci par exemple .

Une des raisons pour lesquelles on na pas été « ajouté » au langage pourrait être à cause du volume de code existant qui ne lutiliserait jamais car ils utilisent leur propre code pour gérer la mémoire. Une autre raison pourrait être que les types d’applications écrites en C et C ++ n’ont pas besoin de la surcharge associée à un processus de garbage collection.

Commentaires

• Mais les programmes futurs écrit commencerait à utiliser le ramasse-miettes, non?
• Bien que le garbage collection soit théoriquement indépendant de tout langage de programmation, il est assez difficile décrire un GC utile pour C / C ++, et même impossible den créer un infaillible (au moins aussi infaillible que Java ' s) – la raison pour laquelle Java peut le retirer est parce quil fonctionne dans un environnement virtualisé contrôlé. Inversement, le langage Java est conçu pour GC, et vous ' aurez du mal à écrire un compilateur Java qui ne ' que GC .
• @tdammers: Je suis daccord que le garbage collection doit être pris en charge par le langage pour être possible. Cependant, le point principal nest pas la virtualisation et lenvironnement contrôlé, mais un typage strict. C et C ++ sont faiblement typés, donc ils permettent des choses comme stocker le pointeur dans une variable entière, reconstruire des pointeurs à partir de décalages et dautres choses qui empêchent le collecteur de pouvoir dire de manière fiable ce qui est accessible (C ++ 11 interdit au plus tard dautoriser au moins collectionneurs conservateurs). En Java, vous savez toujours ce quest une référence, vous pouvez donc la collecter précisément, même si elle est compilée en natif.
• @Thorbj ø rnRavnAndersen: je peux écrire un programme C valide qui stocke les pointeurs de telle manière quaucun garbage collector ne puisse les trouver. Si vous accrochez ensuite un ramasse-miettes à malloc et free, vous interrompriez mon programme correct.
• @Thorbj ø rnRavnAndersen: Non, je ne ' pas appeler free jusquà ce que jen ai terminé . Mais votre garbage collector proposé qui ne ' libère pas la mémoire jusquà ce que jappelle explicitement free isn ' ta garbage collector du tout.

C a été conçu à une époque où le garbage collection était à peine une option. Il était également destiné à des utilisations où le garbage collection ne fonctionnait généralement pas – des environnements en temps réel sans système dexploitation avec une mémoire minimale et une prise en charge minimale de lexécution. Rappelez-vous que C était le langage dimplémentation du premier Unix, qui fonctionnait sur un pdp-11 avec 64 * K * octets de mémoire. C ++ était à lorigine une extension de C – le choix avait déjà été fait, et il est très difficile de greffer le ramasse-miettes sur un langage existant. Cest le genre de chose qui doit être intégrée depuis le rez-de-chaussée.

Je nai pas les guillemets exacts, mais Bjarne et Herb Sutter disent quelque chose du genre:

C ++ na pas besoin dun ramasse-miettes, car il na pas de déchets.

Dans la version moderne C ++ vous utilisez des pointeurs intelligents et donc pas de déchets.

Commentaires

• Que sont les pointeurs intelligents?
• si cétait ça simple, personne naurait implémenté de GC.
• @deadalnix: Cest vrai, parce que personne nimplémente jamais rien de trop compliqué, lent, gonflé ou inutile. Tous les logiciels sont 100% efficaces tout le temps, non?
• @deadalnix – Lapproche C ++ de la gestion de la mémoire est plus récente que celle des garbage collector. RAII a été inventé par Bjarne Stroustrup pour C ++. Le nettoyage des destructeurs est une idée plus ancienne, mais les règles pour garantir la sécurité des exceptions sont essentielles. Je ne sais ' quand exactement quand lidée elle-même a été décrite pour la première fois, mais le premier standard C ++ a été finalisé en 1998, et Stroustrups " Design et Evolution du C ++ " na pas été ' publié jusquen 1994, et les exceptions étaient un ajout relativement récent au C ++ – après la publication du " Manuel de référence C ++ annoté " en 1990, je crois. GC a été inventé en 1959 pour Lisp.
• @deadalnix – savez-vous quau moins une machine virtuelle Java utilisait un GC de comptage de références qui pouvait (presque) être implémenté en utilisant RAII de style C ++ en utilisant une classe de pointeur intelligent – précisément parce que était plus efficace pour le code multithread que pour les VM existantes? Voir www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf. Lune des raisons pour lesquelles vous ' ne voyez pas cela en C ++ en pratique est la collection GC habituelle – elle peut collecter des cycles, mais ne peut ' choisir un ordre de destruction sûr en présence de cycles, et ne peut donc pas garantir un nettoyage fiable du destructeur.

Vous demandez pourquoi ces langages nont pas été mis à jour pour inclure un ramasse-miettes optionnel.

Le problème avec le ramasse-miettes optionnel est que vous ne pouvez pas mélanger du code qui utilise les différents modèles. Autrement dit, si jécris du code qui suppose que vous utilisez un garbage collector, vous ne pouvez pas lutiliser dans votre programme qui a désactivé le garbage collection. Si vous le faites, il fuira partout.

Il existe différents problèmes, notamment …

• Bien que GC ait été inventé avant C ++, et peut-être avant C, C et C ++ ont été implémentés avant que les GC soient largement acceptés comme pratiques.
• Vous ne pouvez pas facilement implémenter un Langage et plate-forme GC sans langage non GC sous-jacent.
• Bien que GC soit manifestement plus efficace que GC pour le code dapplication typique développé à des échelles de temps typiques, etc., il y a des problèmes où plus defforts de développement sont un bon commerce -off et la gestion de la mémoire spécialisée surclassera un GC à usage général. De plus, C ++ est généralement plus efficace que la plupart des langages GC, même sans effort de développement supplémentaire.
• GC nest pas universellement plus sûr que le RAII de style C ++ . RAII permet de nettoyer automatiquement les ressources autres que la mémoire, essentiellement parce quil prend en charge des destructeurs fiables et opportuns. Ils ne peuvent pas être combinés avec des méthodes GC conventionnelles en raison de problèmes avec les cycles de référence.
• Les langages GC ont leurs propres caractéristiques types de mémoire les fuites, en particulier concernant la mémoire qui ne sera plus jamais utilisée, mais où des références existantes existaient qui nont jamais été annulées ou écrasées. La nécessité de le faire explicitement nest pas différente en principe de la nécessité de delete ou free explicitement. Lapproche GC a toujours un avantage – pas de références pendantes – et lanalyse statique peut attraper certains cas, mais encore une fois, il « ny a pas de solution parfaite pour tous les cas.

Fondamentalement, en partie » Cest à peu près lâge des langues, mais il y aura toujours une place pour les langues non GC de toute façon – même si cest un peu une place de niche. Et sérieusement, en C ++, le manque de GC nest pas un gros problème – votre mémoire est gérée différemment, mais elle nest pas non gérée.

Le C ++ géré par Microsofts a au moins une certaine capacité à mélanger GC et non- GC dans la même application, permettant un mix-and-match des avantages de chacun, mais je nai pas lexpérience pour dire à quel point cela fonctionne dans la pratique.

Liens de rep-whoring vers des réponses connexes à moi …

• https://stackoverflow.com/questions/1529679/how-do-you-program-safely-outside-of-a-managed-code-environment/1529731#1529731
• https://stackoverflow.com/questions/1424660/garbage-collection-vs-non-garbage-collection-programming-languages/1496547#1496547
• https://stackoverflow.com/questions/4984849/why-circular-referenced-objects-with-del-defined-are-uncollectable-in-python/4984934#4984934
• https://stackoverflow.com/questions/5009869/how-to-implement-garbage-collection-in-c/5009984#5009984

Pouvez-vous imaginer écrire un gestionnaire de périphérique dans un langage avec ramasse-miettes? Combien de bits pourraient ligne pendant que le GC était en cours dexécution?

Ou un système dexploitation? Comment pourriez-vous démarrer le ramasse-miettes en cours dexécution avant même de démarrer le noyau?

C est conçu pour un niveau bas proche des tâches matérielles. Le problème? est-ce un langage si agréable que cest un bon choix pour de nombreuses tâches de niveau supérieur. Les czars du langage sont conscients de ces utilisations, mais ils doivent en priorité prendre en charge les exigences des pilotes de périphériques, du code intégré et des systèmes dexploitation.

Commentaires

• C bon pour le haut niveau? Jai reniflé mon verre sur tout mon clavier.
• Eh bien, il a dit " de nombreuses tâches de niveau supérieur ". Il pourrait compter les trolls (un, deux, plusieurs …). Et il na pas ' dire plus haut que quoi. Blagues à part, cependant, ' est vrai – la preuve étant que de nombreux projets importants de niveau supérieur ont été développés avec succès en C. Il peut y avoir de meilleurs choix maintenant pour beaucoup de ces projets, mais un projet qui fonctionne est une preuve plus solide que la spéculation sur ce qui aurait pu être.
• Il existe ' des systèmes dexploitation gérés, et ils fonctionnent plutôt bien. En fait, lorsque vous faites gérer lensemble du système, les performances liées à lutilisation du code managé diminuent encore, jusquà être plus rapide que le code non managé dans des scénarios réels. Bien sûr, ce sont tous des " OS de recherche " – il ny a ' quasiment pas moyen de les rendre compatibles avec le code non géré existant en plus de créer un système dexploitation non géré entièrement virtualisé dans le système dexploitation géré. Microsoft a suggéré à un moment donné quils pourraient remplacer Windows Server par lun de ceux-ci, car de plus en plus de code serveur est écrit sur .NET.

La réponse courte et ennuyeuse à cette question est quil doit y avoir un langage non ramassé pour les personnes qui écrivent les ramasse-miettes. Ce n’est pas facile du point de vue conceptuel d’avoir un langage qui permet en même temps un contrôle très précis de la disposition de la mémoire et a un GC en haut.

Lautre question est pourquoi C et C ++ nont pas de ramasse-miettes.Eh bien, je sais que le C ++ en a quelques-uns mais ils ne sont pas vraiment populaires car ils sont obligés de gérer un langage qui na pas été conçu pour être GC-ed en premier lieu, et les personnes qui utilisent encore C ++ dans cet âge nest pas vraiment celui qui manque un GC.

De plus, au lieu dajouter GC à un ancien langage non GC-ed, il est en fait plus facile de créer un nouveau langage qui a la plupart des même syntaxe tout en prenant en charge un GC. Java et C # en sont de bons exemples.

Commentaires

• Quelque part sur programmers.se ou SO, il y a ' est une affirmation que quelquun ma fait savoir que quelquun travaillait sur un objet de récupération de mémoire auto-amorçable – IIRC implémentant essentiellement la VM en utilisant un langage GC, avec un sous-ensemble damorçage utilisé pour implémenter le GC lui-même . Jai oublié le nom. Quand je lai regardé, il sest avéré quils ' navaient pratiquement jamais franchi le pas du sous-ensemble-sans-GC au niveau de travail-GC. est possible en principe, mais AFAIK cela na jamais été réalisé dans la pratique – il ' est certainement un cas de faire les choses à la dure.
• @ Steve314: I ' Jadorerais voir ça si jamais vous vous souvenez où vous lavez trouvé!
• la trouvé! Consultez les commentaires sur stackoverflow.com/questions/3317329/… concernant la machine virtuelle Klein. Une partie du problème pour la trouver – la question a été fermée.
• BTW – Je semble incapable de commencer mes commentaires avec @missingno – quest-ce qui donne?
• @ steve314: Après avoir écrit la réponse ceci thread est attaché à, je reçois déjà une notification pour tous les commentaires. Faire un @ -post dans ce cas serait redondant et nest pas autorisé par SE (ne ' ne me demandez pas pourquoi cependant). (La vraie cause est que mon numéro est manquant)

Le ramassage des ordures est fondamentalement incompatible avec un langage système utilisé pour développer des pilotes pour du matériel compatible DMA.

Il est tout à fait possible que le seul pointeur vers un objet soit stocké dans un registre matériel sur un périphérique. Puisque le ramasse-miettes ne le saurait à ce sujet, il penserait que lobjet était inaccessible et le collecterait.

Cet argument vaut le double pour le compactage de GC. Même si vous preniez soin de conserver en mémoire les références aux objets utilisés par les périphériques matériels, lorsque le GC a déplacé lobjet, il ne saurait pas comment mettre à jour le pointeur contenu dans le registre de configuration des périphériques.

Donc maintenant vous avez besoin dun mélange de tampons DMA immobiles et dobjets gérés par GC, ce qui signifie que vous avez tous les inconvénients des deux.

Commentaires

• Sans doute tous les inconvénients des deux, mais moins dexemples de chaque inconvénient, et les mêmes pour les avantages. Il est clair quil est difficile de gérer plus de types de gestion de la mémoire, mais il peut également être difficile déviter la complexité en choisissant le bon cheval pour chaque cours de votre code. Peu probable, jimagine, mais il y a ' une lacune théorique. Jai ' avoir spéculé sur le mélange de GC et de non-GC dans le même langage auparavant, mais pas pour les pilotes de périphériques – plus pour avoir une application principalement GC, mais avec un faible niveau de mémoire géré manuellement bibliothèques de structures de données de niveau.
• @ Steve314: Ne ' t-il pas dire que se souvenir des objets à libérer manuellement est aussi onéreux que de se souvenir de tout libérer? (Bien sûr, les pointeurs intelligents peuvent aider avec lun ou lautre, donc aucun nest un énorme problème) Et vous avez besoin de pools différents pour les objets gérés manuellement par rapport aux objets collectés / compactables, car le compactage ne ' t fonctionnent bien lorsquil y a des objets fixes dispersés partout. Donc beaucoup de complexité supplémentaire pour rien.
• Pas sil y a ' une division claire entre le code de haut niveau qui est tout GC, et le bas niveau code qui opte pour GC. Jai principalement développé lidée en regardant D il y a quelques années, ce qui vous permet de désactiver GC mais ne vous permet ' de vous réinscrire. Prenons par exemple une bibliothèque darborescence B + . Le conteneur dans son ensemble devrait être GC, mais les nœuds de structure de données probablement pas – il ' est plus efficace de faire une analyse personnalisée à travers les nœuds feuilles uniquement que de forcer le GC à faire un recherche récursive à travers les nœuds de branche. Cependant, cette analyse doit rapporter les éléments contenus au GC.
• Le fait est que ' est une fonctionnalité contenue. Traiter les nœuds darbre B + comme une gestion de mémoire WRT spéciale nest pas différent de les traiter comme des nœuds darbre WRT étant B + spéciaux. Il ' est une bibliothèque encapsulée, et le code de l’application n’a pas ' besoin de savoir que le comportement du GC a été contourné / casse spéciale.Sauf que, du moins à lépoque, cétait impossible en D – comme je lai dit, aucun moyen de réactiver et de signaler les éléments contenus au GC en tant que racines potentielles du GC.

Parce que C & C ++ sont des langages de niveau relativement bas destinés à un usage général, même, par exemple, pour fonctionner sur un processeur 16 bits avec 1 Mo de mémoire dans un système embarqué, qui ne pouvait pas se permettre de gaspiller de la mémoire avec gc.

Commentaires

• " Système embarqué "? Au moment de la normalisation de C (1989), il devait être capable de gérer PC avec 1 Mo de mémoire.
• Je suis daccord, je citais un exemple plus récent.
• 1 Mo ??? Holy schmoley, qui aurait besoin de autant de RAM? < / billGates >

Il existe des garbage collector en C ++ et C. Je ne sais pas comment cela fonctionne en C, mais en C ++, vous pouvez utiliser RTTI pour découvrir dynamiquement votre graphe dobjets et lutiliser pour le ramasse-miettes.

À ma connaissance, vous ne pouvez pas écrire Java sans garbage collector. Une petite recherche a été effectuée this .

La principale différence entre Java et C / C ++ est quen C / C ++, le choix vous appartient toujours , alors quen Java, vous êtes souvent laissé sans options par conception.

Commentaires

• Et aussi que les garbage collors dédiés sont mieux implémentés, plus efficaces et sintégrer mieux dans le langage. 🙂
• Non, vous pouvez ' t utiliser RTTI pour découvrir dynamiquement le graphe dobjets en C / C ++: Il ' sont les vieux objets de données simples qui gâchent tout. Il ny a simplement aucune information RTTI stockée dans un ancien objet de données qui permettrait à un ramasse-miettes de différencier les pointeurs et les non-pointeurs dans cet objet. Pire encore, les pointeurs nont pas besoin dêtre parfaitement alignés sur tout le matériel, donc, étant donné un objet de 16 octets, il y a 9 emplacements possibles où un pointeur de 64 bits peut être stocké, dont seulement deux don ' t chevauchement.

Cest un compromis entre performances et sécurité.

Il ny a aucune garantie que vos déchets seront collectés en Java, donc il peut traîner en utilisant de lespace pendant une longue période, tandis que la recherche dobjets non référencés (cest-à-dire les déchets) prend également plus de temps que la suppression ou la libération explicite dun objet inutilisé.

Lavantage est, bien sûr, que on peut construire un langage sans pointeurs ou sans fuites de mémoire, donc on est plus susceptible de produire du code correct.

Il peut y avoir un petit côté « religieux » à ces débats parfois – soyez prévenu!

Voici une liste de problèmes inhérents à GC, qui le rendent inutilisable dans un langage système comme C:

• Le GC doit fonctionner en dessous du niveau du code dont il gère les objets. Il ny a tout simplement pas de tel niveau dans un noyau.

• Un GC doit arrêter le code géré de temps en temps. Pensez maintenant à ce qui se passerait sil faisait cela à votre noyau. Tout traitement sur votre machine sarrêterait pendant, disons, une milliseconde, tandis que le GC analyse toutes les allocations de mémoire existantes. Cela tuerait toutes les tentatives de création de systèmes fonctionnant sous des exigences strictes en temps réel.

• Un GC doit être capable de faire la distinction entre les pointeurs et les non-pointeurs. Autrement dit, il doit être capable de regarder chaque objet mémoire existant, et être capable de produire une liste de décalages où ses pointeurs peuvent être trouvés.

  Cette découverte doit être parfaite: le GC doit être capable pour chasser tous les pointeurs quil découvre. Sil déréféré un faux positif, il planterait probablement. Sil échouait à découvrir un faux négatif, il détruirait probablement un objet qui est toujours utilisé, plantant le code géré ou corrompant silencieusement ses données.

  Cela nécessite absolument que les informations de type soient stockées dans chaque objet existant. Cependant, C et C ++ autorisent tous deux des objets de données anciens simples qui ne contiennent aucune information de type.

• GC est une activité intrinsèquement lente. Les programmeurs qui ont été socialisés avec Java peut ne pas sen rendre compte, mais les programmes peuvent être bien plus rapides lorsquils ne sont pas implémentés en Java. Et lun des facteurs qui ralentissent Java est GC. Cest ce qui empêche les langages GC comme Java dêtre utilisés dans le calcul intensif. Si votre machine coûte un million par an en consommation dénergie, vous ne voulez même pas en payer 10% pour le ramasse-miettes.

C et C ++ sont des langages créés pour prendre en charge tous les cas dutilisation possibles. Et, comme vous le voyez, bon nombre de ces cas dutilisation sont exclus par le garbage collection. Donc, pour prendre en charge ces cas dutilisation, C / C ++ ne peut pas être récupéré.