Pourquoi ne pas le C++ ont un garbage collector?

Je ne suis pas poser cette question à cause des mérites de la collecte des ordures tout d'abord. Ma principale raison de la demande c'est que je sais que Bjarne Stroustrup a dit que C++ aura un garbage collector à un certain point dans le temps.

Avec cela dit, pourquoi n'a-t-il pas été ajouté? Il y a déjà quelques ramasseurs d'ordures pour le C++. Est-ce juste un de ces "plus facile à dire qu'à faire" type de choses? Ou existe-il d'autres raisons, il n'a pas été ajouté (et ne sera pas ajouté en C++11)?

De la croix-liens:

Juste pour clarifier, je comprends les raisons pour lesquelles C++ n'ai pas de garbage collector quand il a été créé. Je me demandais pourquoi le collecteur ne peut pas être ajouté dans.

  • C'est l'un des top dix mythes sur le C++ qui est le rageux toujours. La collecte des ordures n'est pas "intégrée", mais il y a plusieurs moyens faciles de le faire en C++. Poster un commentaire parce que d'autres ont déjà répondu mieux que je ne pourrais ci-dessous 🙂
  • Mais c'est tout l'intérêt de ne pas être intégré, vous devez le faire vous-même. Realibility de haut en bas : intégré, bibliothèque, home-made. J'utilise C++ moi-même, et certainement pas un hater, car c'est le meilleur langage du monde. Mais de gestion de mémoire dynamique est une douleur.
  • Je ne suis pas un C++ hater je ne suis même en essayant de même dire que le C++ a besoin d'un garbage collector. Je demande parce que je sais que Bjarne Stroustrup a dit qu'il SERA ajouté et c'était juste curieux de ce que les raisons de ne pas la mettre en œuvre ont été.
  • Voir aussi stackoverflow.com/questions/819425/....
  • je pense qu'une meilleure question est, pourquoi une collecte des ordures stratégie n'est pas une option en c++? et pourquoi le c++0x proposition initiale ne permet pas de partiel gc dans un programme?
  • Cet article Le Boehm Collecteur pour le C et le C++ du Dr Dobbs décrit un open source garbage collector qui peut être utilisé à la fois avec le C et le C++. Il traite de certaines des questions qui se posent avec l'aide d'un garbage collector avec C++ destructeurs ainsi que la Bibliothèque C Standard.
  • c++11 permet, "si la mise en œuvre choisissez" apparemment: stackoverflow.com/questions/15157591/...
  • Mais il n'est pas utile maintenant (voir ma réponse...) il est donc peu probable que les implémentations de investir en avoir un.

InformationsquelleAutor Jason Baker | 2008-09-29
  1. 149

    Implicite de collecte des ordures pourrait avoir été ajouté, mais il n'a tout simplement pas faire la coupe. Probablement en raison non seulement de la mise en œuvre des complications, mais aussi grâce à des gens de ne pas être en mesure de venir à un consensus général assez rapide.

    Une citation de Bjarne Stroustrup lui-même:

    J'espérais qu'un garbage collector
    ce qui pourrait éventuellement être activé
    serait une partie de C++0x, mais il y avait
    assez de problèmes techniques que j'ai
    à faire avec juste détaillé
    spécification de la façon dont un tel collecteur
    s'intègre avec le reste de la
    langue, si elle est fournie. Comme c'est le cas
    avec essentiellement toutes C++0x fonctionnalités,
    une mise en œuvre expérimentale existe.

    Il y a une bonne discussion sur le sujet ici.

    Aperçu général:

    C++ est très puissant et vous permet de faire presque n'importe quoi. Pour cette raison, il n'est pas automatiquement pousser beaucoup de choses sur vous qui pourrait influer sur les performances. La collecte des ordures peut être facilement mis en œuvre avec des pointeurs intelligents (les objets qui encapsulent des pointeurs avec un nombre de références, qui auto supprimer eux-mêmes lorsque le compteur de référence atteint 0).

    C++ a été construit avec des concurrents dans l'esprit qui n'a pas de collecte des ordures. L'efficacité a été la principale préoccupation que le C++ n'a pour parer aux critiques en comparaison à C et les autres.

    Il y a 2 types de collecte des ordures...

    Explicite de collecte des ordures:

    C++0x ont la collecte des ordures via des pointeurs créé avec shared_ptr

    Si vous le voulez, vous pouvez l'utiliser, si vous ne voulez pas, vous n'êtes pas forcé de l'utiliser.

    Vous pouvez actuellement utiliser boost:shared_ptr ainsi si vous ne voulez pas attendre pour C++0x.

    Implicite de collecte des ordures:

    Il n'a pas transparent de collecte des ordures bien. Il sera un point central pour l'avenir C++ specs bien.

    Pourquoi Tr1 n'a pas implicite de collecte des ordures?

    Il y a beaucoup de choses que tr1 de C++0x aurait dû, Bjarne Stroustrup dans de précédentes interviews a déclaré que tr1 n'avait pas comme beaucoup comme il l'aurait souhaité.

    • Je voudrais devenir un hater si C++ forcé de collecte des ordures sur moi! Pourquoi pas les gens utilisent smart_ptr's? Comment feriez-vous un faible niveau de style Unix bifurcation, avec un garbage collector dans le chemin? D'autres choses seraient touchés comme le filetage. Python a ses global interprète de verrouillage surtout à cause de la collecte des déchets (voir Cython). Garder hors de C / C++, merci.
    • Comment fais-tu transparent de collecte des ordures de void * système d'exploitation de l'API opaque structures?
    • Le principal problème avec un décompte de références de collecte des ordures (c'est à dire std::shared_ptr) est cyclique références, ce qui cause une fuite de mémoire. Par conséquent, vous devez soigneusement utilisation std::weak_ptr de briser les cycles, ce qui est pénible. Marque et de balayage de style GC n'ont pas ce problème. Il n'y a pas d'incompatibilité inhérente entre le filetage/bifurquer et de collecte des ordures. Java et C# les deux ont une haute performance de préemption le multithreading et et un garbage collector. Il y a des problèmes liés à des applications temps-réel et un garbage collector, comme la plupart des éboueurs arrêter le monde.
    • "Le principal problème avec un décompte de références de collecte des ordures (c'est à dire std::shared_ptr) est cyclique références" et terribles à la performance qui est ironique, parce que l'amélioration des performances est généralement la justification de l'utilisation de C++... flyingfrogblog.blogspot.co.royaume-uni/2011/01/...
    • "Comment voulez-vous faire de bas niveau style Unix bifurquer". De la même façon GC avais langages comme OCaml ont été faites pour ~20 ans ou plus.
    • "Python a son mondial interprète de verrouillage principalement à cause de la collecte des ordures". Strawman argument. Java et .NET tous les deux ont Cg, mais ni l'échelle d'écluses.
    • Le problème que j'ai avec forcé et l'utilisation généralisée de GC est la difficulté d'éviter les fuites. Si nous aller tout le chemin à la plupart manuel formes de gestion de la mémoire, comme en C, la seule façon de fuite de mémoire est de manquer d'avoir un correspondant free à un malloc/calloc. Au classement, l'auteur de quelque chose comme une texture de l'objet peut tout faire parfaitement, pour allouer de la texture et de supprimer toutes les références qu'il a créé, à l'heure qu'il est retiré -- absolument parfait, de l'unité testée. Et pourtant, il pourrait encore y avoir des centaines de lieux de la fuite de la texture -- tout ce qu'il faut en GC pour la texture de ressources pour...
    • ... avez un tas de logique fuites associés où il n'est pas libéré jusqu'à ce que le programme d'arrêt est pour n'importe quel développeur impliqués simplement stocker une référence à la texture dans certains globale et ne parviennent pas à supprimer la référence au moment opportun. Pire, ces sortes de fréquentes GC associée à la logique des fuites dans la très complexe des bases de codes et de grandes équipes sont beaucoup, beaucoup plus difficile à détecter, de débogage, et que l'absence d'une correspondance free à un malloc. Ils n'apparaissent pas dans valgrind, par exemple, car ils sont logiques fuites plutôt que physique des fuites.
    • Pour moi, c'est un plus gros problème que les plus fréquemment cités dans les performances de celles qui sont liées. Il a à voir avec l'exactitude et le code incorrect que les fuites sans GC exige seulement une négligence de la part de la personne de l'allocation de mémoire, et c'est souvent beaucoup plus facile à détecter/corriger, même dans le pire des cas. Avec GC, il ne nécessite qu'une négligence de la part de toute personne (même un plug-in tiers) à la fuite de certaines des plus grandes ressources dans le système, et ces types de fuites sont les plus difficiles à détecter/corriger (parfois rivalisant avec condition de course-comme les douleurs dans le débogage).
    • La "source" de lien est mort. Veuillez mettre à jour la réponse. J'ai essayé, mais le bouton modifier est désactivé.
    • Après n'importe quel développeur impliqués simplement enregistré une référence à la texture dans certains globale et n'a pas à supprimer la référence au bon moment, vous diligemment appel free et puis un autre hasard développeur utilise cette référence et vous avez tous de profiter de débogage de la undefined behavior mise à mort de vos chats et la gravure de vos maisons. Alors que valgrind trouve la référence et l'accès à code, je ne vois pas comment il est plus facile que l'analyse de la fuite de mémoire, vous obtiendrez de la cg à la place.
    • Pratiquement parlant, si un tel comportement indéfini pourrait facilement voler sous le radar et le programme pourrait sembler fonctionner normalement, ou plutôt, j'en serais d'accord. Mais la plupart du temps ces UB a tendance à se manifester sous la forme d'un crash, une corruption de segment de mémoire, erreur de segmentation, etc., tout ce qui peut être immédiatement pris lors du débogage. Si vous travaillez sur la mission de logiciels critiques où une fuite n'est pas la fin du monde, je suis d'accord que GC est un choix très judicieux. Mais sinon le principal désir pour moi est de faire des bugs aussi facile à reproduire de la façon la plus cohérente possible et le plus facile à repérer que possible
    • .. dans un tel cas, où le désir est le moyen le plus facile de reproduire une question et de la traiter le plus rapidement possible de la corriger dans les tests avant la sortie du produit, j'en serais heureux d'accepter le balançant pointeur de crash sur une table de fuite de ressources, depuis que je travaille dans un domaine où les fuites sont vraiment indésirables pendant le processus de test généralement des mauvaises herbes sur tous les grands plis à condition qu'ils puissent être facilement détecté (qui, malheureusement, une table de fuite n'est pas si facile à détecter).
    • Juste dans mon expérience personnelle, les bugs qui sont faciles à reproduire systématiquement comme des erreurs de segmentation ont tendance à être signalés et corrigés si pas pris dans notre unitaires/tests d'intégration avant que le produit officiellement navires. Pendant ce temps les bugs qui sont extrêmement difficiles à reproduire/détecter pouvez rester dans le produit pendant des années, parmi ceux que j'ai connu sont des conditions de course, les variables non initialisées, et GC fuites. Il suffit de considérer, comment voulez-vous écrire un test qui permet de détecter une telle GC fuite avec un enracinée de ressources? Je ne pense pas que c'est possible, mais il est possible de détecter immédiatement les balançant pointeur d'accès.
    • Enfin, valgrind ne peut pas détecter une logique de fuite autant que je sache. Un enracinée de ressources n'est pas nécessairement continuer à prendre de la mémoire après l'arrêt. Il continue juste à accaparer la mémoire alors que l'application est en cours d'exécution. Une fois que la demande commence à se fermer, l'objet (disons shader) qui stocke la texture est supprimé du système et donc la texture il des références de même être libéré. Depuis GC repose sur l'implicite de la destruction plutôt qu'explicite, il n'y a aucun moyen de savoir de quelle ressource est destinée à être libéré quand exactement. La texture n'était tout simplement pas libéré assez tôt, lorsque l'utilisateur l'a demandé.
    • Le type de fuite dont je parle est celui où, disons-le, ces shaders stocker des références à des textures qu'ils utilisent. Donc, l'image de la bibliothèque. Toutefois, l'utilisateur peut explicitement demander la suppression d'une texture à partir de l'image de la bibliothèque, à quel point les shaders doivent libérer leurs références à la texture afin de permettre GC pour recueillir leur mémoire. Cependant, ils ne pas supprimer/null ces références, afin de les textures silencieusement continuer à prendre de la mémoire jusqu'à ce que les shaders eux-mêmes sont supprimés. C'est le genre de GC fuite qui vole sous le radar et n'est jamais pris par essais/valgrind dans mon expérience.
    • En attendant, prenons l'équivalent explicite de la destruction. Dans ce cas, lorsque l'utilisateur demande de suppression de la texture de l'image de la bibliothèque, le développeur demande expressément de le détruire. Maintenant, si nous avons le même bug ci-dessus où les shaders ne libèrent pas leurs pointeurs/références à la texture, ils pourraient alors essayez d'y accéder conduisant à une balançant pointeur UB (généralement conduisant à un vilain crash). Mais qui a tendance à être immédiatement détectable et reproductible par QA si pas nos tests automatisés eux-mêmes -- donc, je trouve que beaucoup plus préféré.
    • Cela dit, en tant que mises en garde répétées je ne travaille pas dans la mission-critique des domaines où il est souhaitable pour l'application continue de fonctionner normalement en présence de bugs (là, je serais probablement voulez vraiment GC). Je travaille dans un qui préfère de détecter et de reproduire de tels bugs aussi rapidement et aussi facilement que possible et, de préférence avant que le produit même des navires, même si le bug conduit à un crash. Donc il y GC a effectivement été une épine dans mon côté, au moins pour les très grandes bases de codes avec des grosses équipes-ils conduire à certaines des plus difficiles à détecter une fuite de bugs que j'ai trouvé.
    • Et ouf, des excuses pour les longs commentaires, mais je pense que pour beaucoup d'applications qui fuit un peu au cours de l'exécution est probablement pas une grosse affaire. Mais il y a certains domaines comme les jeux ou, dans mon cas, VFX où non négligeable de ressources sont allouées assez fréquemment -- avec VFX un artiste peut charger une haute définition HDR texture qui s'étend sur une gigabyte. De sorte à ne pas libre au moment opportun est vraiment un vilain bug dans notre cas, pas quelque chose de relativement bénignes, et nous ne voulons pas de tels bugs facilement passer inaperçus car GC peut permettre.
    • Et une dernière chose, (la dernière je le promets!) -- considérons un scénario qui, GC n'autorise pas -- le scénario où le développeur d'origine jamais libéré de la texture à tous -- aucune partie du système libère de textures. C'est le genre de physique de fuite que valgrind détecte facilement, de sorte que, de même, a tendance à être très facile à détecter... c'est seulement le GC-style logique de fuite dans ce scénario que j'ai trouvé incroyablement difficile à détecter dans les grandes bases de code (en millions de LOC) parce que vous voyez, le fait que l'application de porcs de plus en plus et mem plus il s'exécute, mais qui le fait? Qui a échoué à null/supprimer un ref?
    • ... et dans mon cas, certains de longues enquêtes effectivement m'amener à découvrir qu'il n'était même pas notre code qui a été la cause de ces GC fuites. Il s'agissait de la troisième partie des plugins les utilisateurs ont le chargement.. et tous les plugins avait à faire pour le rendre massif des textures ou des mailles de fuite dans le système a été tout stocker une référence à eux et ne parviennent pas à les mettre à null au moment opportun... et c'est une perspective effrayante quand ce qui est écrit entre quelqu'un parmi des millions de LOC peut devenir une ressource partagée propriétaire par l'enregistrement d'une référence dans une application où la logique fuites ne devraient pas être ignorée.
    • Valgrind ne pouvez vraiment pas trouver logique des fuites et il n'y a pas moyen de les tester, mais il y a d'autres outils pour GC recueillies langues. Vous parlez d'un C++ point de vue, ce qui est quelque chose de complètement différent de Java. En effet, la GC n'aide pas avec la logique de fuites directement, mais il les rend improbable. Quel est ton shader de la tenue de la référence? En Java, il serait probablement un objet léger alloué en cas de besoin et il lui-même, serait d'obtenir GC avais. Il peut être un singleton plutôt la tenue d'une référence à la courant de la texture et puis il avait une fuite, il seulement jusqu'à ce qu'il sera remplacé par un nouveau.
    • C'est une ressource de gestion de la question qui n'est pas résolu par une fonctionnalité du langage autant que je sache (mais il pourrait y avoir quelques beaux outils de débogage en Java, je suis pas sur pour les aider à détecter ces fuites). Disons que vous avez un centrale du graphe de scène dans un logiciel. Scène graphiques stocker des choses comme les shaders, meshes, textures, caméras, etc, et certaines de ces choses sont mises en œuvre par des tiers (tiers shaders chargé par les plugins). Les types de fuites que j'ai rencontrées étaient ceux où vous pourriez avoir quelque chose comme la maille ou de la texture en question (et donc la propriété) par...
    • ... beaucoup de choses différentes -- appareils photo peut stocker une liste de mailles à exclure de rendu. Certains shaders peut faire référence spécifique meshes et les textures. Le convertisseur peut stocker des références à toutes sortes de scène d'objets qu'il veut rendre... c'est le fait que toutes ces choses sont effectivement le partage de la propriété de ces ressources, ce qui est devenu une épine dans mon côté. Logiquement il n'y a qu'un seul propriétaire -- le graphe de scène est propriétaire de mailles, l'image de la bibliothèque propriétaires de textures. Si notre équipe et de plug-in tiers devs étaient au courant de fantôme et de la faiblesse des références et de les utiliser...
    • ... de manière appropriée, je pourrais avoir une vision beaucoup plus positive.. mais trop souvent, ils ont juste stocké une référence à ces scènes d'objets, et parfois ils avaient oublier de libérer au bon moment... et puis je me retrouve face à ce scénario où l'application commence à prendre de plus en plus de mémoire, et les utilisateurs ne commencent à remarquer, mais c'est tellement difficile de comprendre la ligne de code qui n'a pas pu libérer la ressource(s)... surtout lorsqu'il n'est pas toutes les lignes de code sont encore sous notre contrôle.
    • Maintenant, dans notre cas les shaders ont été des objets légers, très légers -- juste la plupart du temps le code. Mais ils ont peut faire référence à quelque chose qui n'est pas la lumière, comme une maille avec un million de polygones, ou un 8000x8000 pixel HDR texture. Et lorsque l'utilisateur demande d'enlever une telle texture de l'image de la bibliothèque, le shader (qui pourrait être un plug-in tiers shader) pourrait ne pas réussir à gérer l'événement et de libérer correctement la texture.... et c'est alors que mes cauchemars commencer.
    • Je trouve ça profondément mal à l'aise, nightmarishly donc, cette idée que tout peut être devenir une ressource partagée propriétaire par tout simplement de stocker une référence à elle dans une base de code d'une telle ampleur, avec des plugins tiers, et un fort désir d'éviter une logique de fuite. Le problème ne s'est produite entre persistante scène des objets de stockage persistant des références à des ressources qu'ils n'avaient rien de partage de la propriété. Où j'ai trouvé GC extrêmement précieux personnellement multithreading -- parce que beaucoup de choses dans notre système n'a pas de sens partagé de la propriété persistante...
    • ... mais il y a des cas où il est fait beaucoup de sens pour une courte durée thread pour prolonger la durée de vie d'une ressource jusqu'à ce qu'il a terminé le traitement. J'y trouve GC extrêmement utile, mais la plupart des o le temps je le trouve trop effrayant et trop enclin à l'erreur lorsqu'il est utilisé pour stocker persistante des références autour de dans plus d'une persistante place.
    • Il semble que vous travaillez avec Java. Il y a des tonnes d'applications à mission critique dans Java et seulement très peu de fuite de mémoire plaintes. Il existe des chargeurs de classes fuites, qui sont un autre problème, nous allons donc les oublier. De nombreux problèmes en effet résolus à l'aide de la faiblesse des références, en particulier quelque chose comme "liste de mailles à exclure de rendu". Si vos shaders sont légers, vous pouvez les affecter et d'oublier après qu'ils ont fait leur travail, de sorte qu'ils obtiennent GD avais. Si c'est impossible, et le plugin ne peut pas être changé, vous pouvez être en mesure d'éviter de donner la vraie chose...
    • C'est vrai et j'ai vu ma part de très compétente applications développées en GC langues -- je ne veux pas la faire sonner comme il est automatiquement conduire à des fuites de logiciels. Mais je ne considère GC un peu d'une lame de rasoir ou la tronçonneuse en la matière si les fuites ne sont pas bénignes, compte tenu de la façon dont facilement, même à un tiers de l'écriture d'un plugin, peut entraîner l'utilisation du logiciel à une fuite massive des ressources par l'enregistrement d'une référence à elle et ne pas le lâcher en réponse à l'événement. Je souhaite qu'il y ait un terrain d'entente car je n'aime pas le manuel de gestion de la mémoire, mais préfère encore.
    • Laissez-nous continuer cette discussion dans le chat.
    • Ce que je n'aime pas dans la STL ATM est la façon maladroite que iteratiors sont utilisés pour contourner le manque GC. Dans Linq, je pourrais simplement faire un .Sélectionnez(), en C++ le filtrés éléments sont déplacés vers le début et l'itérateur sur le premier élément sélectionné. Je suppose que si vous pouvez libérer les éléments précédents. D'autre fuite de mémoire. Ces choses pourraient être beaucoup plus agréable avec le GC. Au moment où ils sont juste maladroit. À mon humble avis

    InformationsquelleAutor
  2. 138

    Pour ajouter au débat ici.

    Il y a des problèmes connus avec la collecte des ordures, et de les comprendre permet de comprendre pourquoi il n'y a aucune en C++.

    1. La Performance ?

    La première plainte est souvent question de performance, mais la plupart des gens n'ont pas vraiment conscience de ce qu'ils sont en train de parler. Comme illustré par Martin Beckett le problème peut ne pas être la performance en soi, mais la prévisibilité de la performance.

    Actuellement, il existe 2 familles de GC, qui sont largement déployés:

    • Mark-and-Sweep type
    • De référence de Comptage de type

    La Mark And Sweep est plus rapide (moins d'impact sur les performances d'ensemble) mais il souffre d'un "gel du monde" syndrome: c'est à dire lorsque le GC coups de pied dans, tout le reste est arrêté jusqu'à ce que le GC a fait son nettoyage. Si vous souhaitez créer un serveur qui répond en quelques millisecondes... certaines transactions ne sera pas à la hauteur de vos attentes 🙂

    Le problème de Reference Counting est différent: comptage de références ajoute-dessus, surtout en Multi-Threading environnements parce que vous devez avoir atomique comte. En outre il y a le problème des cycles de référence si vous avez besoin d'un algorithme intelligent pour détecter les cycles et les éliminer (généralement mise en œuvre par le "gel du monde" aussi, bien que moins fréquent). En général, à compter d'aujourd'hui, ce genre (même si normalement plus réactif, ou plutôt, le gel de moins en moins souvent) est plus lent que le Mark And Sweep.

    J'ai vu un papier par Eiffel maîtres d'œuvre qui ont essayé de mettre en œuvre un Reference Counting Garbage Collector qui sont similaires performance globale de Mark And Sweep sans le "Gel Du Monde" aspect. Il faut un thread séparé pour le GC (typique). L'algorithme a été un peu effrayant (à la fin), mais le papier fait un bon travail de l'introduction des concepts à la fois et en montrant l'évolution de l'algorithme de la "simple" version à part entière de l'un. Lecture recommandée si seulement je pouvais mettre ma main sur le fichier PDF...

    2. L'Acquisition De Ressources Est D'Initialisation

    Il s'agit d'un idiome dans C++ que vous enveloppez-la propriété des ressources à l'intérieur d'un objet pour s'assurer qu'ils sont correctement libérées. Il est principalement utilisé pour la mémoire puisque nous n'avons pas de collecte des ordures, mais il est aussi très utile quand même pour beaucoup d'autres situations:

    • serrures (multi-thread, descripteur de fichier, ...)
    • connexions (pour une base de données, un autre serveur, ...)

    L'idée est de bien contrôler la durée de vie de l'objet:

    • il devrait être en vie aussi longtemps que vous en avez besoin
    • il doit être tué lorsque vous avez terminé avec elle

    Le problème de la GC, c'est que si elle contribue à l'ancienne et, finalement, des garanties plus tard... cette "ultime" peut ne pas être suffisant. Si vous relâche un verrou, vous voulez vraiment qu'il soit libéré, de sorte qu'il ne bloque pas les appels supplémentaires!

    Langues avec les GC ont deux solutions:

    • n'utilisez pas de GC, l'allocation de pile est suffisante: c'est normalement pour les problèmes de performances, mais dans notre cas, il aide vraiment car le champ d'application définit la durée de vie
    • using construire... mais c'est explicite (faible) RAII alors qu'en C++ RAII est implicite, de sorte que l'utilisateur NE peut pas involontairement font l'erreur (en omettant les using mot-clé)

    3. Pointeurs Intelligents

    Pointeurs intelligents apparaissent souvent comme une balle d'argent à gérer la mémoire dans C++. Souvent de fois j'ai entendu: nous n'avons pas besoin GC après tout, puisque nous avons des pointeurs intelligents.

    On ne pouvait pas être plus faux.

    Pointeurs intelligents faire aider: auto_ptr et unique_ptr utilisation RAII concepts, très utile en effet. Ils sont si simples que vous pouvez écrire vous-même très facilement.

    Quand un besoin de partager la propriété toutefois, il devient de plus en plus difficile: vous risquez de partager entre plusieurs threads et il ya quelques questions subtiles avec la manipulation de la comte. Donc, on va naturellement vers shared_ptr.

    C'est génial, c'est ce coup de pouce pour après tout, mais ce n'est pas une balle d'argent. En fait, le principal problème avec les shared_ptr est qu'il émule un GC mis en œuvre par Reference Counting mais vous avez besoin pour mettre en œuvre le cycle de détection de tous par vous-même... Urg

    Bien sûr, il y a cette weak_ptr truc, mais j'ai malheureusement déjà vu des fuites de mémoire en dépit de l'utilisation de shared_ptr en raison de ces cycles... et quand vous êtes dans un environnement multithread, il est extrêmement difficile à détecter!

    4. Quelle est la solution ?

    Il n'y a pas de solution miracle, mais comme toujours, c'est certainement faisable. En l'absence de GC besoin d'être clair sur la propriété:

    • préfèrent avoir un seul propriétaire à un moment donné, si possible
    • si pas, assurez-vous que votre diagramme de classe n'a pas de cycle se rapportant à la propriété et à les briser avec de subtiles application de weak_ptr

    Donc en effet, il serait bon d'avoir un GC... mais c'est pas une question triviale. Et dans le même temps, nous avons juste besoin de retrousser nos manches.

    • Je souhaite que je pourrais accepter deux réponses! C'est tout simplement génial. Une chose à noter, en ce qui concerne la performance, la GC, qui s'exécute dans un thread séparé est en fait assez commun (il est utilisé en Java et .Net). D'accord, cela pourrait ne pas être acceptable dans les systèmes embarqués.
    • merci, très utile explication.
    • Seuls deux types? Comment 'bout de la copie de collectionneurs? Générations de collectionneurs? Assortis simultanées collectionneurs (y compris le pain dur en temps réel tapis roulant)? Divers collecteurs hybrides? L'homme, de la simple ignorance de l'industrie de ce domaine m'étonne parfois.
    • J'ai dit il n'y avait que 2 types ? J'ai dit qu'il y avait 2 qui ont été largement déployée. Autant que je sache, Python, Java et C# toute utilisation de Marque et de Balayage des algorithmes (Java utilisé pour avoir un algorithme de comptage de référence). Pour être encore plus précis, il me semble que C# utilise les Générations GC pour les cycles mineurs, de Marque Et de Balayage pour les grands et les cycles de la Copie de combattre la fragmentation de la mémoire; mais je dirais que le cœur de l'algorithme est de Marque Et de Balayage. Connaissez-vous une langue dominante qui utilise une autre technologie ? Je suis toujours heureux de l'apprendre.
    • Vous venez de nommer une langue dominante qui a utilisé trois.
    • MON OPINION correcte, Votre pure arrogance étonne moi régulièrement. Aussi arrogant que les gens sont plutôt cool, parfois... 😉
    • Il y a aussi des Différentiels Intergénérationnelle et de ramasseurs d'Ordures. Les GC peuvent affecter RAII, donc, si nous avons de nous GC pour les pointeurs, nous allons avoir une sorte de local type d'objet qui agit comme une pile d'objet ... aussi il ya tellement de nombreux cas où la Collecte des Ordures Automatique est tout simplement pas nécessaires.
    • cela a déjà été porté par JUSTE MON OPINION correcte. Je dirais que les Générations GC sont basées sur la Marque & Balayage (bien qu'ils limitent l'algorithme à un plus petit de la portée). Comme pour ne pas être de besoin, le problème, c'est que soit vous utilisez le GC et le risque d'avoir un espace de fuites ou vous avez recours à la manutention manuelle et le risque d'avoir des fuites de mémoire/références obsolètes. Je suis assez intéressé par la Rouille Régions du Système et je me demande si il va présenter une alternative au problème ci-dessus.
    • Principale différence est que, Générationnelle et Incrémentielles GC ne devez pas arrêter le monde de travailler, et vous pouvez le faire fonctionner sur un seul thread systèmes sans trop de frais généraux par parfois de l'exécution d'une itérations de l'arbre transversal lors de l'accès à la table des pointeurs (le facteur peut être déterminé par le nombre de nouveaux nœuds, avec une base de prédiction de la nécessité de recueillir l'). Vous pouvez prendre GC même plus loin en incluant des données sur où dans le code de la création/modification d'un nœud s'est produite, ce qui pourrait vous permettre d'améliorer vos prédictions, et vous obtenez Échapper à l'Analyse gratuitement avec elle.
    • eh bien, pour être juste, à propos de la Marque & Balayage vous pouvez également éviter l'arrêt de l'effet du monde par l'introduction de lire ou d'écrire des obstacles etc... donc vraiment je considère générationnel comme un raffinement de la Marque & Balayage. Évidemment, je l'ai vaguement abordé le sujet, d'abord parce que c'est une SORTE de réponse, et ensuite parce que je ne suis certainement pas un expert en la matière. Peut-être pourriez-vous ajouter votre propre réponse ?
    • vous avez dit " La Marque Et le Balayage est plus rapide (moins d'impact sur les performances d'ensemble) mais il souffre d'un "gel du monde" syndrome', c'est tout ce que je répond trop. Je ne m'inquiète pas si vous peut appeler Mark & Balayage des variations, ou si vous voulez les appeler "des Œufs et du Bacon", tout ce qui m'intéresse est la mise en œuvre et la communication entre les programmeurs, pas ce que l'on valoir doit être appelé 🙂 ... maintenant, revenons au sujet, GC (ou appelons-Automatique GC comme Python appelle) ne pas avoir à arrêter le monde, c'est tout ce que je laissait présager (et les autres choses que j'ai mentionnées) 🙂
    • Quant à, "peut-être pourriez-vous ajouter votre propre réponse", il n'y a pas besoin de ces réponses sont beaux, comme l'est le vôtre 🙂 Et comme vous l'avez dit, ces algorithmes sont des raffinements de la Marque & Sweep, mais je voudrais aller plus loin pour montrer qu'ils ne sont jamais va être traversant les nœuds (ce qui est ce qui les fait se démarquer comme des variantes de M&S). Ce qui définit le plus, c'est leur comportement qui les différencie, par exemple, je ne suis pas juste la marque, j'ai 5 partitions/node unis, Mark&Sweep a 2, et j'ai vu sur Wikipédia avec 3. Je n'ai jamais essayé d'en faire une question de génération, mais j'ai quelques idées.
    • "souffre d'un "gel du monde" syndrome". Dijkstra a résolu le problème en 1975, avec son drapeau tricolore régime de marquage différentiel de mark-sweep. Des langages comme OCaml (1996) utilisent ce et, par conséquent, ne souffrent pas de ce problème. cs.utexas.edu/~EWD/ewd05xx/EWD595.PDF
    • J'ai touché sur les améliorations possibles après le "Comptage de Référence" système, cependant simultanées GCs sont loin d'être anodines et induire un coût de leur propre; vous avez besoin de lire des obstacles ou écrire des obstacles dans les autres threads, ce qui est le la coopération partie de Dijkstra parlé, je suppose. Je devrais peut-être mettre un naïfs avant de Marquer et de Balayage ?
    • Notez que je parlais des différentiels GCs et ne sont pas simultanées GCs. Différentiels GCs sont triviales. Véritable concurrente GCs ont tendance à être compliqué mais simple simultanées GCs existent (par exemple, la VCGC). Vous pouvez éliminer la surabondance de la GC pauses en utilisant les tas distincts avec des GCs (par exemple OCaml et Erlang) au lieu d'un mondial simultanées GC, mais vous avez besoin de copie en profondeur des messages. Votre déclaration est certainement vrai pour les naïfs mark-sweep mais, alors, personne ne l'utilise naïf mark-sweep. La Production GCs ont tendance à être générationnel avec la copie de collectionneurs entre les jeunes générations et mark-sweep/compact pour la vieille génération.
    • Le problème, lorsqu'il est appliqué à C et C++, c'est que la copie de collectionneurs ne fonctionnent pas: vous avez le droit en C et C++ pour stocker une valeur de type pointeur sur un entier, et même d'un décalage par rapport à votre propre adresse, de sorte que le GC ne peut pas retrouver les références de les mettre à jour lorsque vous vous déplacez. De même, les adresses peuvent être utilisés comme identificateurs d'objets, de sorte que vous ne pouvez pas copier un objet derrière le développeur est de retour. Et bien sûr, la mémoire est facilement partagé entre les threads. Cela limite sérieusement les implémentations possibles de GCs.
    • Pour aller encore plus loin: supposons qu'un programme à plusieurs reprises alloué de 1 000 objets avec new, les remplit avec certaines données, convertit leur adresse, les numéros, les affiche de 1/60 de seconde, puis abandonne les objets sans procéder à un delete. Le programme plus tard permet à l'utilisateur de taper un nombre, convertit une adresse, et l'utilise sur l'hypothèse qu'il représente un objet valide. Si le numéro de l'utilisateur tape dans a été affiché comme l'adresse d'un objet, la norme C++ exige que l'adresse est toujours valide.
    • Alors qu'il serait peu probable qu'un utilisateur de gérer à copier vers le bas chaque numéro qui s'affiche [un appareil photo numérique peut certainement saisir arbitraire écran fulls], et de tout objet associé à une adresse qui a disparu de l'écran avant d'être transcrit pourraient être supprimés en toute sécurité, il serait de toute évidence absolument 100% impossible pour le programme pour connaître les adresses qui existait encore quelque part à l'extérieur de l'ordinateur et qui n'a pas.

    InformationsquelleAutor Matthieu M.
  3. 54

    Quel type? devrait-il être optimisé pour les systèmes embarqués machine à laver les contrôleurs, les téléphones portables, stations de travail ou les supercalculateurs?

    Faut-il privilégier la réactivité de l'interface graphique ou la charge serveur?

    faut-il utiliser beaucoup de mémoire ou il y a beaucoup de CPU?

    C/c++ est utilisé dans de trop nombreuses circonstances différentes.
    Je soupçonne quelque chose comme des pointeurs intelligents de boost sera suffisant pour la plupart des utilisateurs

    Edit - Automatique éboueurs ne sont pas tellement un problème de performance, vous pouvez toujours acheter plus de serveur) c'est une question d'être prévisible performance.

    Ne sachant pas quand le GC va à coup de pied dans est comme employant un neuroleptique de pilote de ligne, la plupart du temps, ils sont grands, mais quand vous avez vraiment besoin de réactivité!

    • Je vois votre point, mais je me sens obligé de demander: n'est-ce pas Java utilisé à peu près autant d'applications?
    • Pas de. Java n'est pas adapté pour les applications de haute performance, pour la simple raison qu'il n'a pas des garanties de performance à la même mesure que le C++. Donc, vous le trouverez dans une cellule de téléphone, mais vous ne le trouverez dans une cellule interrupteur ou d'un superordinateur.
    • Vous pouvez toujours acheter plus de serveur, mais vous ne pouvez toujours acheter plus de CPU pour le téléphone cellulaire déjà dans les poches du client!
    • Java a fait beaucoup de rattrapage à l'efficacité de l'UC. Vraiment intraitable problème est l'utilisation de la mémoire, Java est forcément moins efficace en terme de mémoire de C++. Et que l'inefficacité est due au fait qu'il est des ordures collectées. La collecte des ordures ne peut pas être à la fois rapide et efficace en terme de mémoire, et cela devient évident si vous regardez à quelle vitesse GC algorithmes de travail.
    • java peut gagner sur le débit b/c de l'optimisation jit, mais pas de latence (boo en temps réel), et certainement pas de la mémoire.
    • Java sur l'ordinateur central: www-03.ibm.com/systems/z/os/zos/tools/java. Java commutateur de contrôleur - floodlight.openflowhub.org. Performance temps réel garanties ne sont pas important pour un sous-groupe relativement petit de des applications de haute performance, dans la plupart des régions du HPC Java a été forte pendant une longue période.
    • Ne 864 cœurs ne pas se qualifier pour un supercalculateur? Ne 6 millions de commandes par seconde sur un seul thread en temps réel de trading sont pas admissibles à haute performance? Java a encore quelques inconvénients, mais il est assez bon pour presque toutes les tâches.

    InformationsquelleAutor Martin Beckett
  4. 33

    L'une des plus grandes raisons que le C++ n'est pas construit dans la collecte des ordures est que l'obtention de la collecte des ordures à jouer gentil avec les destructeurs est vraiment, vraiment dur. Autant que je sache, personne ne sait vraiment comment le résoudre complètement encore. Il ya beaucoup de questions à traiter:

    • déterministe de la durée de vie des objets (comptage de référence vous donne ceci, mais le GC n'a pas. Même si elle ne peut être que grand d'une affaire).
    • ce qui se passe si un destructeur jette quand l'objet est d'ordures collectées? La plupart des langues ignorer cette exception, car il y a vraiment aucun bloc catch pour être en mesure de transport, mais ce n'est probablement pas une solution acceptable pour le C++.
    • Comment faire pour l'activer/la désactiver? Naturellement, il serait probablement un moment de la compilation décision, mais le code est écrit pour GC vs code qui est écrit pour ne PAS GC va être très différent et probablement incompatible. Comment conciliez-vous cela?

    Ce sont quelques-uns des problèmes rencontrés.

    • GC et destructeurs est un problème résolu, par un beau pas de côté à partir de Bjarne. Les destructeurs de ne pas courir pendant GC, parce que ce n'est pas le point de GC. GC en C++ existe afin de créer la notion de l'infini mémoire, n'est pas infinie d'autres ressources.
    • Si les destructeurs ne cours pas complètement la sémantique de la langue. Je suppose à tout le moins, vous auriez besoin d'un nouveau mot-clé "gcnew" ou quelque chose de sorte que vous autorisent explicitement cet objet à GC ed (et, par conséquent, vous ne devriez pas l'utiliser pour envelopper les ressources en plus de mémoire).
    • C'est un faux argument. Depuis C++ explicite de gestion de la mémoire, vous devez savoir quand chaque objet doit être libéré. Avec GC, c'est pas plus mal; au contraire, le problème est réduit à essayer de comprendre lorsque certains objets sont libérés, à savoir ceux des objets qui nécessitent une attention particulière lors de la suppression. Expérience de la programmation en Java et C# révèle que la grande majorité des objets nécessitent pas de considérations particulières et peuvent être laissés à la GC. Comme il s'avère, l'une des principales fonctions de destructeurs en C++ est de libérer de l'enfant des objets, GC gère automatiquement pour vous.
    • Une chose qui est améliorée en GC vs non-GC (peut-être la chose la plus importante est la capacité d'un solide GC système pour s'assurer que chaque référence continuera à pointer vers le même objet, tant que la référence existe. L'appel de Dispose sur un objet peuvent rendre inutilisables, mais les références, qui fait référence à l'objet lorsqu'il était vivant continuera de le faire après c'est mort. En revanche, dans les systèmes du GC, les objets peuvent être supprimés alors que les références existent, et il y a rarement une limite sur les ravages que peut être infligée si l'un de ces références est utilisé.
    InformationsquelleAutor Greg Rogers
  5. 20

    Bien que ce soit un vieux question, il y a encore un problème que je ne vois personne s'étant adressé à tous: la collecte des ordures est presque impossible à préciser.

    En particulier, la norme C++ est assez prudent de spécifier la langue dans les termes de l'extérieur et les comportements observables, plutôt que la façon dont la mise en œuvre réalise que le comportement. Dans le cas de la collecte des ordures, cependant, il y est pratiquement pas de l'extérieur et les comportements observables.

    La idée générale de la collecte des ordures, c'est qu'il doit faire un effort raisonnable pour s'assurer qu'une allocation de mémoire va réussir. Malheureusement, il est quasiment impossible de garantir que toute allocation de mémoire va réussir, même si vous avez un garbage collector en fonctionnement. Cela est vrai dans une certaine mesure en tout cas, elle l'est tout particulièrement dans le cas de C++, parce que c'est (probablement) pas possible d'utiliser une copie du collecteur (ou quelque chose de similaire) qui déplace les objets en mémoire au cours d'un cycle de collecte.

    Si vous ne pouvez pas déplacer des objets, vous ne pouvez pas en créer une seule, la mémoire contiguë de l'espace pour faire vos allocations -- et cela signifie que votre tas (ou free store, ou ce que vous préférez l'appeler) peut, et devrait, être fragmentés au fil du temps. Ceci, à son tour, peut empêcher une allocation de réussir, même quand il n'y a plus de mémoire libre que le montant demandé.

    Alors qu'il pourrait être possible de venir avec certains garantie qui dit (en substance) que si vous répétez exactement le même modèle de répartition à plusieurs reprises, et il a réussi la première fois, il va continuer à réussir sur les itérations suivantes, à condition que la mémoire allouée est devenu inaccessible entre les itérations. C'est comme une faiblesse de la garantie c'est essentiellement inutile, mais je ne vois pas d'espoir raisonnable de le renforcer.

    Même ainsi, il est plus fort que ce qui a été proposé pour le C++. Le proposition précédente [avertissement: PDF] (qui a chuté) n'a pas de garantie de quoi que ce soit. En 28 pages de la proposition, ce que vous avez dans la voie de l'extérieur et les comportements observables a qu'un seul (non normatif) note disant:

    [ Note: Pour les ordures ménagères collectées programmes, une haute qualité hébergé mise en œuvre devrait essayer de maximiser le montant de l'inaccessible à la mémoire qu'il récupère. —fin de la remarque ]

    Au moins pour moi, cela soulève un grave question sur le retour sur investissement. Nous voulons briser le code existant (personne n'est sûr de combien exactement, mais certainement un peu), imposent de nouvelles exigences sur la mise en œuvre et de nouvelles restrictions sur le code, et ce que nous obtenons en retour est peut-être rien du tout?

    Même, au mieux, ce que nous obtenons sont des programmes qui, basé sur test avec Java, aura probablement besoin d'environ six fois plus de mémoire pour fonctionner à la même vitesse qu'ils font maintenant. Pire, la collecte des ordures a été une partie de Java depuis le début -- C++ endroits assez plus de restrictions sur le garbage collector qu'il sera presque certainement avoir une même pire rapport coût/bénéfice (même si nous allons au-delà de ce que la proposition de la garantie et de supposer qu'il y aurait quelques avantages).

    Je voudrais résumer la situation mathématiquement: ce une situation complexe. Comme tout mathématicien sait, un nombre complexe est composé de deux parties: le réel et l'imaginaire. Il me semble que ce que nous avons ici sont des coûts qui sont réels, mais les avantages qui sont (au moins pour la plupart) de l'imaginaire.

    • Je voudrais émettre l'hypothèse que, même si l'on précise que, pour le bon fonctionnement de tous les objets doivent être supprimés, et seuls les objets qui ont été supprimés seraient admissibles pour la collecte, le compilateur soutien de référence-suivi de la collecte des ordures pourrait toujours être utile, puisque cette langue pourrait s'assurer que l'utilisation de la suppression du pointeur (de référence) serait garanti à piéger, plutôt que de provoquer un Comportement Indéfini.
    • Même en Java, le GC n'est pas spécifié de faire quelque chose d'utile autant que je sache. Il pourrait faire appel free pour vous (où je veux dire free comme pour le langage C). Mais Java ne garantit jamais à appeler les finaliseurs ou quelque chose comme ça. En fait, le C++ ne prend beaucoup plus de Java à courir autour de commettre des écritures de base de données, bouffées de chaleur descripteurs de fichiers, et ainsi de suite. Java prétend avoir "GC", mais les développeurs de Java méticuleuse appel close() tous les temps et ils doivent être très conscients de la gestion des ressources, en faisant attention de ne pas appeler close() trop tôt ou trop tard. C++ nous libère de que. ...(suite)
    • .. mon commentaire il y a un moment n'est pas destiné à critiquer Java. Je suis juste en observant que le terme de "garbage collection" est un très bizarre terme, cela signifie beaucoup moins de gens pensent qu'il fait et par conséquent, il est difficile de parler sans savoir clairement ce que cela signifie.
    • Il est vrai que la GC n'aide pas avec les ressources de la mémoire à tous. Heureusement, de telles ressources sont alloués assez rarement quand par rapport à la mémoire. En outre, plus de 90% d'entre eux peut être libéré dans la méthode qui a alloué, donc try (Whatever w=...) {...} elle n'en résout (et vous obtenez un avertissement lorsque vous oubliez). Les autres sont problématiques, RAII, trop. L'appel de close() "tout le temps" signifie peut-être une fois par des dizaines de milliers de lignes, ce qui n'est pas si mal que ça, alors que la mémoire est attribué à peu près sur tous les Java ligne.
    InformationsquelleAutor Jerry Coffin
  6. 15

    Si vous souhaitez automatique de collecte des ordures, il y a de bons commerciaux
    et du domaine public, ramasseurs d'ordures, pour le C++. Pour les applications où l'
    la collecte des ordures est approprié, C++ est un excellent ordures collectées
    langue avec une performance qui se compare favorablement avec les autres déchets
    recueillies langues. Voir Le Langage de Programmation C++ (4ème
    Edition)     pour une discussion de la collecte des ordures automatique en C++.
    Voir aussi, Hans-J. Boehm site pour C et C++ de collecte des ordures (archive).

    Aussi, C++ prend en charge la programmation des techniques qui permettent de mémoire
    la gestion coffre-fort et de manière implicite, sans un garbage collector. Je considère que la collecte des ordures un dernier choix et d'une manière imparfaite de manipulation pour la gestion de la ressource. Cela ne veut pas dire qu'il n'est jamais utile, juste qu'il y a de meilleures approches dans de nombreuses situations.

    Source: http://www.stroustrup.com/bs_faq.html#garbage-collection

    Quant à savoir pourquoi il ne l'a construit dans, Si je me souviens bien, il a été inventé avant le GC a été le chose, et je ne crois pas que la langue pourrait avoir eu des GC pour plusieurs raisons(I. E vers l'Arrière de compatibilité avec C)

    Espère que cette aide.

    • "avec un rendement qui se compare favorablement avec les autres déchets collectés langues". Citation?
    • Mon lien était rompu. J'ai écrit cette réponse il y a 5 ans.
    • Ok, je m'attendais à une vérification indépendante de ces revendications, c'est à dire pas par Stroustrup ou Boehm. 🙂
    InformationsquelleAutor Rayne
  7. 12

    Stroustrup fait quelques bons commentaires sur ce en 2013, les Natifs de la conférence.

    Il suffit de sauter à propos de 25m50s dans cette vidéo. (Je vous recommande de regarder la vidéo en entier effectivement, mais cela saute aux choses à propos de la collecte des ordures.)

    Lorsque vous avez vraiment une grande langue qui le rend facile (et sûr et prévisible, et facile à lire et facile à apprendre) pour traiter des objets et des valeurs d'une manière directe, en évitant (explicite) de l'utilisation du tas, alors vous n'avez même pas voulez la collecte des ordures.

    Avec C++ moderne, et les choses que nous avons en C++11, la collecte des ordures n'est plus souhaitable, sauf dans des circonstances limitées. En fait, même si une bonne garbage collector est l'un des principaux compilateurs C++, je pense qu'il ne sera pas utilisé très souvent. Il sera plus facile, pas plus dur, pour éviter la GC.

    Il montre cet exemple:

    void f(int n, int x) {
    Gadget *p = new Gadget{n};
    if(x<100) throw SomeException{};
    if(x<200) return;
    delete p;
}

    C'est dangereux en C++. Mais c'est aussi dangereux en Java! En C++, si la fonction retourne au début, le delete ne sera jamais appelé. Mais si vous avez eu plein de collecte des ordures, comme en Java, il vous suffit simplement faire une suggestion que l'objet sera détruite "à un certain moment dans l'avenir" (mise à Jour:, c'est même pire que cela. Java ne pas promesse d'appeler le finaliseur jamais - peut-être ne jamais être appelé). Ce n'est pas assez bon si Gadget est titulaire d'un descripteur de fichier ouvert, ou d'une connexion à une base de données, ou des données que vous avez mis en mémoire tampon pour écrire dans une base de données à un moment plus tard. Nous voulons que le Gadget à être détruits dès que c'est fini, afin de libérer ces ressources dès que possible. Vous ne voulez pas que votre serveur de base de données aux prises avec des milliers de connexions de base de données qui ne sont plus nécessaires - il ne sait pas que votre programme est terminé de travailler.

    Alors quelle est la solution? Il existe quelques approches. L'approche évidente, que vous utiliserez pour la grande majorité de vos objets est:

    void f(int n, int x) {
    Gadget p = {n};  //Just leave it on the stack (where it belongs!)
    if(x<100) throw SomeException{};
    if(x<200) return;
}

    Cela prend moins de caractères à taper. Il n'a pas new obtenir de la manière. Il ne nécessite pas le type de Gadget deux fois. L'objet est détruit à la fin de la fonction. Si c'est ce que vous voulez, c'est très intuitif. Gadgets ont le même comportement que int ou double. Prévisible, facile à lire, facile à enseigner. Tout est une "valeur". Parfois une grande valeur, mais les valeurs sont plus faciles à enseigner, car vous n'avez pas cette "action à distance" chose que vous obtenez avec des pointeurs (ou références).

    La plupart des objets sont à utiliser uniquement dans la fonction qui les a créés, et peut-être passé comme entrées des fonctions enfant. Le programmeur ne devrait pas avoir à penser à la gestion de la mémoire " quand le retour des objets, ou partager des objets dans l'ensemble largement séparés les parties du logiciel.

    Portée et durée de vie sont importantes. La plupart du temps, c'est plus facile si la durée de vie est le même que le champ d'application. C'est plus facile à comprendre et plus facile à enseigner. Quand vous voulez une autre vie, il devrait être évident à la lecture du code que vous faites cela, par l'utilisation de shared_ptr par exemple. (Ou retour (grand) des objets par valeur, en tirant parti de déménagement de la sémantique ou de unique_ptr.

    Cela peut sembler comme un problème d'efficacité. Que faire si je souhaite retourner un Gadget de foo()? C++11 de la sémantique de déplacement, de faciliter le retour de grands objets. Il suffit d'écrire Gadget foo() { ... } et il va juste travailler, et de travailler rapidement. Vous n'avez pas besoin de jouer avec && vous-même, juste retour des choses par la valeur et la langue sera souvent en mesure de faire le nécessaire optimisations. (Même avant le C++03, compilateurs fait un très bon travail en évitant la copie inutile.)

    Comme Stroustrup dit ailleurs dans la vidéo (paraphrase): "Seulement un informaticien voudrais insister sur la copie d'un objet, puis de détruire l'original. (le public rit). Pourquoi ne pas simplement déplacer l'objet directement vers le nouvel emplacement? C'est ce que les humains (non informaticiens) attendre."

    Quand vous pouvez garantir qu'une seule copie d'un objet est nécessaire, il est beaucoup plus facile de comprendre la vie de l'objet. Vous pouvez choisir ce que la durée de vie de la politique que vous voulez, et la collecte des ordures est là, si vous le souhaitez. Mais quand vous comprenez les avantages des autres approches, vous trouverez que la collecte des ordures est au bas de votre liste de préférences.

    Si cela ne fonctionne pas pour vous, vous pouvez utiliser unique_ptr, ou, à défaut, shared_ptr. Bien écrit en C++11 est plus court, plus facile à lire, et plus faciles à enseigner que beaucoup d'autres langues quand il s'agit de la gestion de la mémoire.

    • GC ne doit être utilisée que pour les objets qui n'ont pas à acquérir des ressources (c'est à dire demander à d'autres entités de faire des choses sur leur compte "jusqu'à nouvel avis"). Si Gadget ne demande pas autre chose à faire n'importe quoi en son nom, le code d'origine serait parfaitement en sécurité dans Java si le sens (pour Java) delete déclaration ont été supprimés.
    • les objets avec ennuyeux destructeurs sont intéressantes. (Je n'ai pas défini "ennuyeux", mais, fondamentalement, les destructeurs que jamais besoin d'être appelé, sauf pour la libération de la mémoire). Il pourrait être possible pour un individu compilateur de traiter shared_ptr<T> spécialement lorsque T est "ennuyeux". Il pourrait décider de ne pas réellement gérer un ref compteur de ce type, et au lieu d'utiliser GC. Cela permettrait à la GC pour être utilisé sans le développeur qui a besoin d'avis. Un shared_ptr pourrait tout simplement être vu comme une table de pointeur, pour adapté T. Mais il y a des limites dans ce domaine, et il ferait beaucoup de programmes plus lent.
    • Un bon type de système doit disposer de différents types de GC et RAII-tas managé des objets, puisque certains modèles d'utilisation très bien fonctionner avec une seule et très mal avec les autres. Dans .NET ou Java, une déclaration string1=string2; va exécuter très rapidement quelle que soit la longueur de la chaîne (c'est littéralement rien de plus qu'un registre de charger et d'enregistrer store), et ne nécessite pas de verrouillage pour s'assurer que si la déclaration ci-dessus est exécutée alors que string2 est en cours d'écriture, string1 tiendra la valeur ancienne ou la nouvelle valeur, sans un Comportement Indéfini).
    • En C++, l'attribution d'un shared_ptr<String> nécessite beaucoup de derrière-le-scènes de la synchronisation, et l'attribution d'un String peut se comporter bizarrement si une variable est de lire et d'écrire simultanément. Les cas où l'on aurait envie d'écrire et de lire un String simultanément ne sont pas très commun, mais peuvent survenir si, par exemple, du code souhaite faire des cours des rapports d'état à la disposition des autres threads. Dans .NET et Java, de telles choses juste "travail".
    • Pourriez-vous clarifier un peu les choses, alors que nous comparons des choses comparables? En C++, tu veux dire un String classe qui est immuable, tout comme la classe String en Java? Et, par conséquent, vous n'avez jamais vraiment attribuer à une Chaîne. Vous pouvez affecter à un String* ou un shared_ptr<String> (ou d'une Chaîne de caractères Java-référence en Java). Je suis confus au sujet de votre discussion de "cession" et "lire et écrire", parce que je préfère la clarté que l'objet sous-jacent est immuable.
    • En Java et .NET, le type le plus commun utilisé pour encapsuler une séquence de caractères est String, immuable type de référence qui est utilisé, car c'est la seule chose qui peut donner de la valeur sémantique de Java, et la seule chose qui pourrait donner de la valeur sémantique .NET sans excès de boxe [dans .NET, une structure qui rend un char[] peut-être mieux que tas objet, sauf pour la boxe problème]. Pour fins de comparaison, je dirais que doit être comparé avec quel que soit le type en C++ le plus efficace pour représenter...
    • ...une séquence de caractères avec la valeur sémantique. Pour certains modèles d'utilisation, C++ String serait le mieux; pour d'autres, shared_ptr<string> serait mieux. Il y a quelques modèles d'utilisation, cependant, pour laquelle aucun C++, type peuvent atteindre l'efficacité et de la sémantique de la GC chaînes, puisque la seule synchronisation est nécessaire avec la GC lui-même, et il a des pouvoirs magiques pour forcer la synchronisation avec des fils qui n'ont pas d'autres mécanismes de synchronisation intégrée.
    • Désolé de me répéter, mais c'est votre C++ String immuable? Vous avez dit plus tôt au sujet de la lecture et de l'écriture, mais l'écriture n'a pas de sens avec un immuable String. quelque chose comme using String = const std::vector<char>;. Je ne peux pas penser à d'autres questions avant d'être clair que le type est.
    • L'intention est d'avoir une variable qui, à différentes époques peuvent être faites pour encapsuler des différentes séquences de caractères, indépendamment de toute autre chaîne-type de la variable. En C++, qui peut être réalisé en ayant la variable encapsule une mutable chaîne directement, un pointeur vers un partageables exemple d'une chaîne qui ne sera jamais muté, un pointeur vers une instance d'une chaîne qui ne sera muté si il n'a jamais été partagé (et dans le cas contraire, être remplacé par une nouvelle instance que le propriétaire pourrait alors muter). Le point clé est que le variable peut-être changer.
    • En bref, pour les fins de la comparaison équitable, quel que soit le genre de type à laisser de C++ obtenir les meilleures performances pour chaque type d'utilisation. Qu' .NET et Java utiliser un mutable référence de immuable objet que leur type de chaîne ne signifie pas que le C++ ne devrait pas être autorisé à utiliser quelque chose de mieux si l'on peut.
    • "Java n'a pas de promesse d'appeler le finaliseur jamais - peut-être ne jamais être appelé", fait Amusant: premières versions de Java a permis le finaliseur à exécuter pendant que l'objet est encore utilisé; en effet, dès le début de l'ctor est terminé!!! Apparemment, ce n'est pas la cause se plaint beaucoup de la "C++ suce, car l'ordre de f()+g() n'est pas déterministe, Java règles parce qu'il est déterministe" de la foule.

    InformationsquelleAutor Aaron McDaid
  8. 10

    L'idée derrière C++, vous ne paierez aucun impact sur les performances pour les fonctionnalités que vous n'utilisez pas. Ainsi, l'ajout de la collecte des ordures aurait signifié avoir certains programmes de s'exécuter directement sur le matériel, la façon dont C ne et certains, dans une sorte d'exécution de la machine virtuelle.

    Rien ne vous empêche d'utiliser une certaine forme de pointeurs intelligents qui sont liés à certains tiers mécanisme de collecte des déchets. Je me souviens de Microsoft de faire quelque chose comme ça avec COM et que ça ne va pas bien.

    • Je ne pense pas que GC nécessite une machine virtuelle. Le compilateur pourrait ajouter du code pour toutes les opérations de pointeur pour mettre à jour un état global, tandis qu'un autre thread s'exécute en arrière-plan suppression d'objets que nécessaire.
    • Je suis d'accord. Vous n'avez pas besoin d'une machine virtuelle, mais à la seconde où vous commencez à avoir quelque chose de gérer votre mémoire pour vous comme que dans le fond, ma sensation est que vous avez à gauche le "fils électriques" et ont en quelque sorte une machine virtuelle situation.
    InformationsquelleAutor Uri
  9. 8

    Pour répondre à la plupart des "pourquoi" des questions à propos de C++, lire La conception et l'Évolution de C++

    InformationsquelleAutor Nemanja Trifunovic
  10. 7

    Parce que C++ moderne n'a pas besoin de la collecte des ordures.

    Bjarne Stroustrup de la FAQ de la réponse à cette question, dit:

    Je n'aime pas les ordures. Je n'aime pas l'abandon de détritus. Mon idéal est d'éliminer la nécessité d'un garbage collector en ne produisant pas de déchets. C'est maintenant possible.

    La situation, pour le code écrit ces jours (C++17 et suivants de l'officiel Lignes Directrices De Base) est comme suit:

    • Plus de mémoire à la propriété code est dans les bibliothèques (en particulier ceux qui fournissent des conteneurs).
    • Plus utilisation de code impliquant la mémoire de la propriété suit le RAII modèle, de sorte que la répartition est faite sur la construction et la désallocation de la destruction, ce qui se passe lors de la sortie de l'étendue dans laquelle une chose a été alloué.
    • Vous ne font pas explicitement allouer ou libérer de la mémoire directement.
    • Raw pointeurs ne possèdent pas de mémoire (si vous avez suivi les lignes directrices), de sorte que vous ne pouvez pas de fuite en les passant autour de.
    • Si vous vous demandez comment vous allez passer les adresses de départ de séquences de valeurs dans la mémoire - vous le ferez avec un span; pas de pointeur brut nécessaire.
    • Si vous avez vraiment besoin de posséder un "pointeur", vous utilisez C++' standard-bibliothèque des pointeurs intelligents - ils ne peuvent pas fuir, et sont très efficaces. Alternativement, vous pouvez passer de la propriété à travers les limites du champ d'application avec "propriétaire pointeurs". Ces sont rares et doivent être utilisés de façon explicite; et ils permettent partielle de la vérification statique contre les fuites.

    "Ah ouais? Mais qu'en est...

    ... si je viens d'écrire le code de la façon dont nous avons utilisé pour écrire en C++ dans les vieux jours?"

    En effet, vous pourrait il suffit de les ignorer toutes les lignes directrices et d'écriture qui fuit le code de l'application et sera de compiler et d'exécuter (et de fuite), comme toujours.

    Mais ce n'est pas un "juste ne pas faire" de la situation, où le développeur est prévu pour être vertueux et exercer beaucoup de contrôle de soi, c'est juste pas plus simple d'écrire non conforme au code, ni est-il plus rapide à écrire, ni est-il un meilleur rendement. Progressivement, il sera aussi plus difficile à écrire, comme vous le feriez pour faire face à une hausse "d'adaptation d'impédance" avec ce conforme code offre et attend.

    ... si je reintrepret_cast? Ou faire de l'arithmétique des pointeurs? Ou d'autres hacks?"

    En effet, si vous mettez votre esprit à lui, vous pouvez écrire du code qui sème la pagaille en dépit de jouer gentil avec les lignes directrices. Mais:

    1. Vous le faire rarement (en termes d'endroits dans le code, pas nécessairement en termes de fraction de temps d'exécution)
    2. Vous ne le faire intentionnellement, n'est pas par hasard.
    3. Le faire se démarquer dans une base de code conforme aux lignes directrices.
    4. C'est le genre de code qui vous permettrait de contourner le GC dans une autre langue, de toute façon.

    ... le développement des bibliothèques?"

    Si vous êtes une bibliothèque C++ développeur ensuite, vous écrivez le code unsafe impliquant des premières pointeurs, et vous êtes tenus de code avec soin et de manière responsable, mais elles sont autonomes, des morceaux de code écrites par des experts (et, plus important encore, revu par les experts).

    Donc, c'est juste comme Bjarne dit: Il n'y a vraiment aucune motivation pour ramasser les ordures en général, comme vous tous, mais assurez-vous de ne pas produire de déchets. GC est en train de devenir un non-problème en C++.

    Qui n'est pas à dire que GC n'est pas un problème intéressant pour certaines applications spécifiques, lorsque vous souhaitez employer allocation personnalisé et de-les allocations de stratégies. Pour ceux que vous voulez personnalisée d'allocation et de répartition, pas une langue au niveau de la cg.

    • Eh bien, il n' (besoin G C) si vous êtes de broyage des chaînes .. Imaginez que vous avez de grands tableaux de chaîne (pensez à des centaines de méga-octets) que vous êtes la construction fragmentaire, puis de traitement et de reconstruction dans différentes longueurs, de supprimer ceux qui sont inutiles, combinant des autres etc. Je le sais parce que j'ai eu à passer à un haut niveau de langues pour y faire face. (Bien sûr, vous pourriez construire votre propre G C ainsi).
    • C'est un cas dans lequel un allocateur personnalisé serait utile. Cela ne nécessite pas une langue intégrale GC...
    • pour einpoklum : vrai. C'est juste de chevaux pour les cours. Mon exigence était de processus de changement dynamique de gallons de Transport de Passagers de l'Information. Sujet fascinant .. s'agit Vraiment de la philosophie du logiciel.
    InformationsquelleAutor einpoklum
  11. 4

    L'un des principes fondamentaux sur lesquels repose l'origine du langage C est que la mémoire est composée d'une séquence d'octets, et le code ont uniquement besoin de soins sur le contenu de ces octets est-à dire au moment précis où ils sont utilisés. Moderne C permet de compilateurs pour imposer des restrictions supplémentaires, mais C comprend--et C++ conserve--la possibilité de décomposer un pointeur dans une séquence d'octets, de les assembler une séquence d'octets contenant les mêmes valeurs dans un pointeur, puis utilisez le pointeur pour accéder le plus tôt objet.

    Alors que cette aptitude peut être utile, voire indispensable dans certains types d'applications, une langue que comprend cette capacité sera très limitée dans sa capacité à soutenir toute sorte d'informations utiles et fiables de collecte des ordures. Si un compilateur ne sait pas tout ce qui a été fait avec les morceaux qui ont fait un pointeur, il n'aura aucun moyen de savoir si des informations suffisantes pour reconstruire le pointeur peut exister quelque part dans l'univers. Car il serait possible pour que les informations soient stockées dans les moyens que l'ordinateur ne serait pas en mesure d'accéder, même si elle savait à leur sujet (par exemple, les octets qui composent le pointeur peut avoir été montré à l'écran assez longtemps pour que quelqu'un à les écrire sur un morceau de papier), il peut être littéralement impossible pour un ordinateur pour savoir si un pointeur pourrait éventuellement être utilisé dans l'avenir.

    Une intéressante caprice de nombreux garbage collector de cadres est qu'un objet de référence non définie par les modèles de bits qui y sont contenues, mais par la relation entre les bits tenu de l'objet de référence et d'autres informations ailleurs. En C et C++, si le motif de bits stockés dans un pointeur identifie un objet, que le motif de bits permettra d'identifier cet objet jusqu'à ce que l'objet est explicitement détruit. Dans un typique GC système, un objet peut être représenté par une séquence de bits 0x1234ABCD à un moment donné dans le temps, mais la prochaine GC cycle pourrait remplacer toutes les références à 0x1234ABCD avec des références à des 0x4321BABE, après quoi l'objet est représenté par le dernier modèle. Même si l'on afficher la séquence de bits associé à un objet de référence, puis plus tard le lire à partir du clavier, il n'y aurait aucun espoir que le même modèle de bits pourrait être utilisée pour identifier le même objet (ou un objet).

    • C'est vraiment un bon point, j'ai récemment volé quelques bouts de mes pointeurs car sinon, il serait stupide quantités de défauts de cache.
    • Je me demande combien d'applications qui utilisent des pointeurs 64 bits serait plus utile, soit à l'aide de l'échelle des pointeurs 32 bits comme les références de l'objet, ou bien de garder presque tout dans 4GiB de l'adresse de l'espace et d'utiliser des objets spéciaux pour stocker/récupérer des données à partir de stockage haute vitesse au-delà? Les Machines ont assez de RAM que la consommation de RAM de 64 bits pointeurs n'est pas pour déplaire, sauf qu'ils absorber deux fois plus de cache que les pointeurs 32 bits.
    InformationsquelleAutor supercat
  12. 3

    Toutes les techniques qui parle de surcharger le concept.

    Si vous mettez GC en C++ pour la mémoire automatiquement, pensez à quelque chose comme un navigateur web. Le navigateur doit charger un complet de documents web ET d'exécuter des scripts web. Vous pouvez stocker web script variables dans l'arborescence du document. Dans un GRAND document dans un navigateur avec plusieurs onglets ouverts, cela signifie que chaque fois que le GC doit faire une collection complète, il faut aussi analyser tous les éléments d'un document.

    Sur la plupart des ordinateurs, ce qui signifie que les DÉFAUTS de PAGE va se produire. Donc, la raison principale, pour répondre à la question, c'est que les DÉFAUTS de PAGE va se produire. Vous le saurez quand votre PC commence à faire beaucoup d'accès disque. C'est parce que le GC doit toucher beaucoup de mémoire pour prouver pointeurs invalides. Lorsque vous avez une véritable demande en utilisant beaucoup de mémoire, ayant pour analyser tous les objets de chaque collection est le chaos à cause des DÉFAUTS de PAGE. Un défaut de page est lorsque la mémoire virtuelle a besoin pour aller lire dans la mémoire vive sur le disque.

    Donc la bonne solution est de diviser une application dans les parties qui doivent GC et les pièces qui ne le sont pas. Dans le cas du navigateur web exemple ci-dessus, si le document de l'arbre a été alloué avec malloc, mais le javascript a couru avec GC, puis à chaque fois que la GC coups de pied dans l'analyse uniquement une petite partie de la mémoire PAGINÉE éléments de la mémoire de l'arborescence du document n'a pas besoin d'obtenir paginé de retour dans.

    À mieux comprendre ce problème, chercher de la mémoire virtuelle et la façon dont il est mis en œuvre dans les ordinateurs. Il est tout au sujet du fait que 2GO est disponible dans le programme quand il n'y a pas vraiment de beaucoup de mémoire vive. Sur les ordinateurs modernes, avec 2 go de RAM pour un système 32 bits, il n'est pas un problème à condition qu'un programme est en cours d'exécution.

    Comme autre exemple, considérons une collection complète qui doit retrouver tous les objets. Vous devez d'abord analyser tous les objets accessibles via les racines. Deuxième analyse tous les objets visibles à l'étape 1. Puis balayez l'attente des destructeurs. Ensuite, allez à toutes les pages, encore et éteindre tous les objets invisibles. Cela signifie que le nombre de pages peut obtenir échangé et en arrière plusieurs fois.

    Donc, ma réponse à apporter, il court, c'est que le nombre de DÉFAUTS de PAGE qui se produisent à la suite de toucher à toutes les causes de la mémoire full GC pour tous les objets dans un programme irréalisable et donc le programmeur doit afficher GC comme une aide pour des choses comme les scripts de base de données et de travail, mais faire des choses normales avec le manuel de gestion de la mémoire.

    Et l'autre raison très importante est bien sûr variables globales. Pour le collecteur de savoir qu'une variable globale pointeur se trouve dans la GC, elle aurait besoin de mots-clés spécifiques, et ainsi le code C++ existant ne fonctionnerait pas.

    InformationsquelleAutor Bob Holmes
  13. 3

    RÉPONSE COURTE:
    Nous ne savons pas comment faire la collecte des ordures efficacement (avec de légères temps et de l'espace, les frais généraux) et correctement tout le temps (dans tous les cas possibles).

    RÉPONSE LONGUE:
    Tout comme le C, le C++ est un des systèmes de la langue; cela signifie qu'il est utilisé lorsque vous écrivez du code dans le système, par exemple, le système d'exploitation. En d'autres termes, le C++ est conçu, exactement comme en C, avec le meilleur possible performance comme cible principale. La langue standard ne permet pas d'ajouter une fonctionnalité qui pourrait nuire à l'objectif de rendement.

    Ce met en pause la question: Pourquoi la collecte des ordures diminue les performances? La raison principale est que, quand il s'agit de la mise en œuvre, nous [les scientifiques de l'informatique] je ne sais pas comment faire la collecte des ordures avec un minimum de frais généraux, pour tous les cas. Par conséquent, il est impossible de le compilateur C++ et système d'exécution pour effectuer la collecte des ordures efficace de tous les temps. D'autre part, un programmeur C++, devrait connaître sa conception/mise en œuvre et il est la meilleure personne à décider de la meilleure façon de faire de la collecte des déchets.

    Dernier, si le contrôle (matériel, détails, etc.) et de la performance (temps, espace, énergie, etc.) ne sont pas les principales contraintes, puis C++ n'est pas l'écriture de l'outil. D'autres langues pourraient servir au mieux et d'offrir plus de [hidden] runtime de gestion, avec le nécessaire de frais généraux.

    InformationsquelleAutor Sqandr
  14. 3

    Lorsque vous comparez le C++ et Java, vous pouvez voir immédiatement que le C++ n'a pas été conçu avec implicite de Collecte des Ordures à l'esprit, alors que Java a été.

    Avoir des choses comme arbitraire des pointeurs en C-Style et déterministe destructeurs n'est pas seulement de ralentir la performance de la GC-implémentations, il pourrait aussi détruire la compatibilité descendante pour une grande quantité de C++-legacy-code.

    En plus de cela, le C++ est un langage qui est destiné à exécuter en tant qu'exécutable autonome au lieu d'avoir un complexe de l'environnement d'exécution.

    Dans l'ensemble:
    Oui, il serait possible d'ajouter de Collecte des Ordures pour le C++, mais par souci de continuité, il est préférable de ne pas le faire. Le coût de l'inaction serait supérieur au bénéfice.

    • La libération de la mémoire et de l'exécution des destructeurs sont trop complètement distinctes. (Java n'a pas destructeurs, qui est un pain PITA.) GC libère de la mémoire, il ne fonctionne pas dtors.
    InformationsquelleAutor Mike76
  15. 0

    Principalement pour deux raisons:

    1. Parce qu'il n'en a pas besoin (à mon humble avis)
    2. Parce que c'est absolument incompatible avec le RAII, qui est la pierre angulaire de C++

    C++ offre déjà le manuel de gestion de la mémoire, l'allocation de pile, RAII, conteneurs, automatique pointeurs, pointeurs intelligents... Qui devrait être suffisant. Les éboueurs sont pour les programmeurs paresseux qui ne veulent pas passer 5 minutes pour penser à qui devrait propres objets ou lorsque les ressources devraient être libérés. Ce n'est pas la façon dont nous faisons les choses en C++.

    • Il existe de nombreux (plus récente) des algorithmes qui sont intrinsèquement difficiles à mettre en œuvre sans la collecte des ordures. Le temps passait. L'Innovation vient aussi de nouvelles perspectives qui correspondent bien à (nettoyage) de haut niveau de langues. Essayez de rétroporter l'un de ces GC C++ libre, vous remarquerez que les bosses de la route. (Je sais que je devrais donner des exemples, mais je suis un peu pressé dès maintenant. Désolé. Celui que je pense dès maintenant tourne autour persistante des structures de données, où le comptage de référence ne fonctionne pas.).
    InformationsquelleAutor Marc Coll
  16. 0

    Imposant la collecte des ordures est vraiment d'un niveau bas à un niveau élevé de paradigme.

    Si vous regardez la façon dont les chaînes sont traitées dans une langue avec la collecte des ordures, vous trouverez, elles ne permettent de haut niveau des fonctions de manipulation de chaîne et ne permettent pas l'accès binaire à cordes. Simplement, tous les fonctions de chaîne, vérifiez d'abord les pointeurs pour voir où la chaîne est, même si vous êtes seulement en dessin sur un octet. Donc, si vous faites une boucle qui traite chaque octet dans une chaîne de caractères dans une langue avec la collecte des ordures, il doit calculer l'emplacement de la base de plus de décalage pour chaque itération, car il ne peut pas savoir quand la chaîne s'est déplacé. Ensuite, vous devez penser à des tas, des piles, des fils, etc etc.

    InformationsquelleAutor www-0av-Com