有没有一个具体的理由垃圾收集没有为C设计的？ [英] Was there a specific reason garbage collection was not designed for C?

问题描述

我听说，这是次优C到自动收集垃圾 - ？没有任何道理的。

I have heard that it was suboptimal for C to automatically collect garbage -- is there any truth to this?

有没有一个具体的理由垃圾收集下没有实现？

Was there a specific reason garbage collection was not implemented for C?

推荐答案

不要听C是旧的，这就是为什么它不具有气相色谱法乡亲。有借助于GC根本的问题，无法克服，这使得它用C不相容

Don't listen to the "C is old and that's why it doesn't have GC" folks. There are fundamental problems with GC that cannot be overcome which make it incompatible with C.

目前最大的问题是，准确的垃圾收集需要扫描内存和查明遇到任何指针的能力。一些高级语言限制整数不使用所有的位可用，使得高比特可被用于区分整数对象的引用。那么这种语言可以存储字符串（其中可能包含任意字节序列），在它们无法与指针相混淆特殊字符串区，一切都很好。 AC实现，但是，不能这样做，因为字节的整数，指针，以及其他一切可以一起存储在结构，联合，或由的malloc 返回块的一部分。

The biggest problem is that accurate garbage collection requires the ability to scan memory and identify any pointers encountered. Some higher level languages limit integers not to use all the bits available, so that high bits can be used to distinguish object references from integers. Such languages may then store strings (which could contain arbitrary octet sequences) in a special string zone where they can't be confused with pointers, and all is well. A C implementation, however, cannot do this because bytes, larger integers, pointers, and everything else can be stored together in structures, unions, or as part of chunks returned by malloc.

如果你扔掉的精度要求，并决定你没事与不得到释放，因为在节目中一些非指针数据具有相同的位模式，因为这些对象的地址几个对象？现在假设您的计划得到了外界的数据（网络/文件/等）。我要求我可以让你的程序泄露的内存是任意的，并最终耗尽内存，只要我能猜到足够的指点和我喂你的程序中的字符串效仿他们。如果你申请德布鲁因序列这变得轻松了许多。

What if you throw away the accuracy requirement and decide you're okay with a few objects never getting freed because some non-pointer data in the program has the same bit pattern as these objects' addresses? Now suppose your program receives data from the outside world (network/files/etc.). I claim I can make your program leak an arbitrary amount of memory, and eventually run out of memory, as long as I can guess enough pointers and emulate them in the strings I feed your program. This gets a lot easier if you apply De Bruijn Sequences.

除此之外，垃圾收集只是普通的缓慢。你可以找到数百谁喜欢声称另有学者，但是这不会改变的现实。 GC的性能问题可以分解成3个主要的类别：

Aside from that, garbage collection is just plain slow. You can find hundreds of academics who like to claim otherwise, but that won't change the reality. The performance issues of GC can be broken down into 3 main categories:

• 联合国predictability


• 缓存污染


• 步行时间所有内存

谁将会声称GC快这几天都简单地把它比作错事的人：写得不好的C和C ++程序而分配和释放几千或几百万每秒的对象。是的，这些也将是缓慢的，但至少$ P $你可以测量，如果需要修复的方式pdictably缓慢。一个写得很好的C程序会花这么少的时间的malloc / 免费的开销甚至不是衡量的。

The people who will claim GC is fast these days are simply comparing it to the wrong thing: poorly written C and C++ programs which allocate and free thousands or millions of objects per second. Yes, these will also be slow, but at least predictably slow in a way you can measure and fix if necessary. A well-written C program will spend so little time in malloc/free that the overhead is not even measurable.

这篇关于有没有一个具体的理由垃圾收集没有为C设计的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！