做音乐头像网站,wordpress 判断登录页面跳转,装饰设计乙级资质,做网站要花钱吗点击蓝字关注我们Java的爱好者们经常批评C中没有提供与Java类似的垃圾回收(Gabage Collector)机制(这很正常#xff0c;正如C的爱好者有时也攻击Java没有这个没有那个#xff0c;或者这个不行那个不够好)#xff0c;导致C中对动态存储的官吏称为程序员的噩梦#xff0c;不是… 点击蓝字关注我们Java的爱好者们经常批评C中没有提供与Java类似的垃圾回收(Gabage Collector)机制(这很正常正如C的爱好者有时也攻击Java没有这个没有那个或者这个不行那个不够好)导致C中对动态存储的官吏称为程序员的噩梦不是吗你经常听到的是内存遗失(memory leak)和非法指针存取这一定令你很头疼而且你又不能抛弃指针带来的灵活性。在本文中我并不想揭露Java提供的垃圾回收机制的天生缺陷而是指出了C中引入垃圾回收的可行性。请读者注意这里介绍的方法更多的是基于当前标准和库设计的角度而不是要求修改语言定义或者扩展编译器。什么是垃圾回收作为支持指针的编程语言C将动态管理存储器资源的便利性交给了程序员。在使用指针形式的对象时(请注意由于引用在初始化后不能更改引用目标的语言机制的限制多态性应用大多数情况下依赖于指针进行)程序员必须自己完成存储器的分配、使用和释放语言本身在此过程中不能提供任何帮助也许除了按照你的要求正确的和操作系统亲密合作完成实际的存储器管理。标准文本中多次提到了“未定义(undefined)”而这大多数情况下和指针相关。某些语言提供了垃圾回收机制也就是说程序员仅负责分配存储器和使用而由语言本身负责释放不再使用的存储器这样程序员就从讨厌的存储器管理的工作中脱身了。然而C并没有提供类似的机制C的设计者Bjarne Stroustrup在我所知的唯一一本介绍语言设计的思想和哲学的著作《The Design and Evolution of C》(中译本C语言的设计和演化)中花了一个小节讨论这个特性。简而言之Bjarne本人认为“我有意这样设计C使它不依赖于自动垃圾回收(通常就直接说垃圾回收)。这是基于自己对垃圾回收系统的经验我很害怕那种严重的空间和时间开销也害怕由于实现和移植垃圾回收系统而带来的复杂性。还有垃圾回收将使C不适合做许多底层的工作而这却正是它的一个设计目标。但我喜欢垃圾回收的思想它是一种机制能够简化设计、排除掉许多产生错误的根源。需要垃圾回收的基本理由是很容易理解的用户的使用方便以及比用户提供的存储管理模式更可靠。而反对垃圾回收的理由也有很多但都不是最根本的而是关于实现和效率方面的。已经有充分多的论据可以反驳每个应用在有了垃圾回收之后会做的更好些。类似的也有充分的论据可以反对没有应用可能因为有了垃圾回收而做得更好。并不是每个程序都需要永远无休止的运行下去并不是所有的代码都是基础性的库代码对于许多应用而言出现一点存储流失是可以接受的许多应用可以管理自己的存储而不需要垃圾回收或者其他与之相关的技术如引用计数等。我的结论是从原则上和可行性上说垃圾回收都是需要的。但是对今天的用户以及普遍的使用和硬件而言我们还无法承受将C的语义和它的基本库定义在垃圾回收系统之上的负担。”以我之见统一的自动垃圾回收系统无法适用于各种不同的应用环境而又不至于导致实现上的负担。稍后我将设计一个针对特定类型的可选的垃圾回收器可以很明显地看到或多或少总是存在一些效率上的开销如果强迫C用户必须接受这一点也许是不可取的。关于为什么C没有垃圾回收以及可能的在C中为此做出的努力上面提到的著作是我所看过的对这个问题叙述的最全面的尽管只有短短的一个小节的内容但是已经涵盖了很多内容这正是Bjarne著作的一贯特点言简意赅而内韵十足。下面一步一步地向大家介绍我自己土制佳酿的垃圾回收系统可以按照需要自由选用而不影响其他代码。构造函数和析构函数C中提供的构造函数和析构函数很好的解决了自动释放资源的需求。Bjarne有一句名言“资源需求就是初始化(Resource Inquirment Is Initialization)”。因此我们可以将需要分配的资源在构造函数中申请完成而在析构函数中释放已经分配的资源只要对象的生存期结束对象请求分配的资源即被自动释放。那么就仅剩下一个问题了如果对象本身是在自由存储区(Free Store也就是所谓的“堆”)中动态创建的并由指针管理(相信你已经知道为什么了)则还是必须通过编码显式的调用析构函数当然是借助指针的delete表达式。智能指针幸运的是出于某些原因C的标准库中至少引入了一种类型的智能指针虽然在使用上有局限性但是它刚好可以解决我们的这个难题这就是标准库中唯一的一个智能指针::std::auto_ptr。它将指针包装成了类并且重载了反引用(dereference)运算符operator *和成员选择运算符operator -以模仿指针的行为。关于auto_ptr的具体细节参阅《The C Standard Library》(中译本C标准库)。例如以下代码#include cstring
#include memory
#include iostreamclass string
{
public:string(const char* cstr) { _datanew char [ strlen(cstr)1 ]; strcpy(_data, cstr); }~string() { delete [] _data; }const char* c_str() const { return _data; }
private:char* _data;
};void foo()
{::std::auto_ptr string str ( new string( hello ) );::std::cout str-c_str() ::std::endl;
}由于str是函数的局部对象因此在函数退出点生存期结束此时auto_ptr的析构函数调用自动销毁内部指针维护的string对象(先前在构造函数中通过new表达式分配而来的)并进而执行string的析构函数释放为实际的字符串动态申请的内存。在string中也可能管理其他类型的资源如用于多线程环境下的同步资源。下图说明了上面的过程。现在我们拥有了最简单的垃圾回收机制(我隐瞒了一点在string中你仍然需要自己编码控制对象的动态创建和销毁但是这种情况下的准则极其简单就是在构造函数中分配资源在析构函数中释放资源就好像飞机驾驶员必须在起飞后和降落前检查起落架一样。)即使在foo函数中发生了异常str的生存期也会结束C保证自然退出时发生的一切在异常发生时一样会有效。auto_ptr只是智能指针的一种它的复制行为提供了所有权转移的语义即智能指针在复制时将对内部维护的实际指针的所有权进行了转移例如auto_ptr string str1( new string( str1 ) );
cout str1-c_str();
auto_ptr string str2(str1); // str1内部指针不再指向原来的对象
cout str2-c_str();
cout str1-c_str(); // 未定义str1内部指针不再有效某些时候需要共享同一个对象此时auto_ptr就不敷使用由于某些历史的原因C的标准库中并没有提供其他形式的智能指针走投无路了吗另一种智能指针但是我们可以自己制作另一种形式的智能指针也就是具有值复制语义的并且共享值的智能指针。需要同一个类的多个对象同时拥有一个对象的拷贝时我们可以使用引用计数(Reference Counting/Using Counting)来实现曾经这是一个C中为了提高效率与COW(copy on write改写时复制)技术一起被广泛使用的技术后来证明在多线程应用中COW为了保证行为的正确反而导致了效率降低(Herb Shutter的在C Report杂志中的Guru专栏以及整理后出版的《More Exceptional C》中专门讨论了这个问题)。然而对于我们目前的问题引用计数本身并不会有太大的问题因为没有牵涉到复制问题为了保证多线程环境下的正确并不需要过多的效率牺牲但是为了简化问题这里忽略了对于多线程安全的考虑。首先我们仿造auto_ptr设计了一个类模板(出自Herb Shutter的《More Execptional C》)template typename T
class shared_ptr
{
private:class implement // 实现类引用计数{public:implement(T* pp):p(pp),refs(1){}~implement(){delete p;}T* p; // 实际指针size_t refs; // 引用计数};implement* _impl;public:explicit shared_ptr(T* p): _impl(new implement(p)){}~shared_ptr(){decrease(); // 计数递减}shared_ptr(const shared_ptr rhs): _impl(rhs._impl){increase(); // 计数递增}shared_ptr operator(const shared_ptr rhs){if (_impl ! rhs._impl) // 避免自赋值{decrease(); // 计数递减不再共享原对象_implrhs._impl; // 共享新的对象increase(); // 计数递增维护正确的引用计数值}return *this;}T* operator-() const{return _impl-p;}T operator*() const{return *(_impl-p);}private:void decrease(){if (--(_impl-refs)0){ // 不再被共享销毁对象delete _impl;}}void increase(){(_impl-refs);}
};这个类模板是如此的简单所以都不需要对代码进行太多地说明。这里仅仅给出一个简单的使用实例足以说明shared_ptr作为简单的垃圾回收器的替代品。void foo1(shared_ptr int val)
{shared_ptr int temp(val);*temp300;
}void foo2(shared_ptr int val)
{valshared_ptr int ( new int(200) );
}int main()
{shared_ptr int val(new int(100));coutval*val;foo1(val);coutval*val;foo2(val);coutval*val;
}在main()函数中先调用foo1(val)函数中使用了一个局部对象temp它和val共享同一份数据并修改了实际值函数返回后val拥有的值同样也发生了变化而实际上val本身并没有修改过。然后调用了foo2(val)函数中使用了一个无名的临时对象创建了一个新值使用赋值表达式修改了val同时val和临时对象拥有同一个值函数返回时val仍然拥有这正确的值。最后在整个过程中除了在使用shared_ptr 的构造函数时使用了new表达式创建新之外并没有任何删除指针的动作但是所有的内存管理均正确无误这就是得益于shared_ptr的精巧的设计。拥有了auto_ptr和shared_ptr两大利器以后应该足以应付大多数情况下的垃圾回收了如果你需要更复杂语义(主要是指复制时的语义)的智能指针可以参考boost的源代码其中设计了多种类型的智能指针。标准容器对于需要在程序中拥有相同类型的多个对象善用标准库提供的各种容器类可以最大限度的杜绝显式的内存管理然而标准容器并不适用于储存指针这样对于多态性的支持仍然面临困境。使用智能指针作为容器的元素类型然而标准容器和算法大多数需要值复制语义的元素前面介绍的转移所有权的auto_ptr和自制的共享对象的shared_ptr都不能提供正确的值复制语义Herb Sutter在《More Execptional C》中设计了一个具有完全复制语义的智能指针ValuePtr解决了指针用于标准容器的问题。然而多态性仍然没有解决我将在另一篇文章专门介绍使用容器管理多态对象的问题。语言支持为什么不在C语言中增加对垃圾回收的支持根据前面的讨论我们可以看见不同的应用环境也许需要不同的垃圾回收器不管三七二十一使用垃圾回收需要将这些不同类型的垃圾回收器整合在一起即使可以成功(对此我感到怀疑)也会导致效率成本的增加。这违反了C的设计哲学“不为不必要的功能支付代价”强迫用户接受垃圾回收的代价并不可取。相反按需选择你自己需要的垃圾回收器需要掌握的规则与显式的管理内存相比简单的多也不容易出错。最关键的一点 C并不是“傻瓜型”的编程语言他青睐喜欢和善于思考的编程者设计一个合适自己需要的垃圾回收器正是对喜爱C的程序员的一种挑战。*声明本文于网络整理版权归原作者所有如来源信息有误或侵犯权益请联系我们删除或授权事宜。戳“阅读原文”我们一起进步
