内网网站开发报价,今天重庆发生大新闻,在linux上做网站搭建,软件定制图片“自我赋值”发生在对象被赋值给自己时#xff1a; 1 classWidget {...}; 2 Widget w; 3 ... 4 w w; //赋值给自己这看起来有点愚蠢#xff0c;但它合法#xff0c;所以不要认定客户绝不会那么做。此外赋值动作并不总是那么可被一眼辨认出来#xff0c;例如#xff1a; a[… “自我赋值”发生在对象被赋值给自己时 1 class Widget {...}; 2 Widget w; 3 ... 4 w w; //赋值给自己 这看起来有点愚蠢但它合法所以不要认定客户绝不会那么做。此外赋值动作并不总是那么可被一眼辨认出来例如 a[i] a[j]; //潜在的自我赋值 如果i和j有相同的值这便是个自我赋值。再看 *px *py; //潜在的自我赋值 如果*px和*py恰好指向同一个东西这也是自我赋值。这写并不明显的自我赋值是“别名”带来的结果所谓“别名”就是“有一个以上的方法指称(指涉)某对象”。一般而言如果某段代码操作pointers或references而它们被用来“指向多个相同类型的对象”就需要考虑这些对象是否为同一个。实际上两个对象只要来自同一个继承体系它们甚至不需要声明为相同类型就可能造成“别名”因为一个base class的reference或pointer可以指向一个derived class对象 1 class Base { ... }; 2 class Derived: public Base {...}; 3 void doSomething(const Base rb, Derived* pd); //rb和*pd有可能其实是同一对象。 如果遵循条款13和条款14的忠告你会运用对象来管理资源而且你可以确定所谓“资源管理对象”在copy发生时有正确的举措。这种情况下你的赋值操作符或许是“自我赋值安全的”不需要额外操心。然而如果你尝试自行管理资源(如果你打算写一个用于资源管理的class就得这样做)可能会掉进“在停止使用资源之前意外释放了它”的陷阱。假设你建立一个class用来保存一个指针指向一块动态分配的位图(bitmap) 1 class Bitmap { ... }; 2 class Widget { 3 ... 4 private: 5 Bitmap* pb; //指针指向一个从heap分配而得的对象 6 }; 下面是operator实现代码表面上看起来合理但是自我赋值出现时并不安全(它也不具备异常安全性但我们稍后才讨论这个主题)。 1 Widget Widget::operator(const Widget rhs) //一份不安全的operator实现版本。 2 { 3 delete pb; //停止使用当前的bitmap 4 pb new Bitmap(*rhs.pb); //使用rhss bitmap的副本(复件)。 5 return *this; //见条款10. 6 } 这里的自我赋值问题是operator函数内的*this(赋值的目的端)和rhs有可能是同一个对象。果真如此delete就不只是销毁当前对象的bitmap它也销毁rhs的bitmap。在函数末尾Widget——它原本不该被自我赋值动作改变的——发现自己持有一个指针指向一个已被删除的对象 欲阻止这种错误传统做法是由operator最前面的一个“证同测试”达到“自我赋值”的检验目的 1 Widget Widget::operator(const Widget rhs) 2 { 3 if(this rhs) return *this; //证同测试如果是自我赋值就不做任何事。 4 5 delete pb; 6 pb new Bitmap(*rhs.pb); 7 return *this; 8 } 这样做行得通。稍早我曾经提过前一版operator不仅不具备“自我赋值安全性”也不具备“异常安全性”这个新版本仍然存在异常方面的麻烦。更明确地说如果new Bitmap”导致异常(不论是因为分配时内存不足或因为Bitmap的copy构造函数抛出异常)Widget最终会持有一个指针指向一块被删除的Bitmap。这样的指针有害。你无法安全地删除它们甚至无法安全地读取它们。唯一能对它们做的安全事情就是付出许多调试能量找出错误的起源。 令人高兴的是让operator具备“异常安全性”往往自动获得“自我赋值安全”的回报。因此愈来愈多人对“自我赋值”的处理态度是倾向不去管它把焦点放在实现“异常安全性”上。条款29深度探讨了异常安全性本条款只要你注意“许多时候一群精心安排的语句就可以导出异常安全(以及自我赋值安全)的代码”这就够了。例如以下代码我们只需注意在复制pb所指东西之前别删除pb 1 Widget Widget::operator(const Widget rhs) 2 { 3 Bitmap* pOrig pb; //记住原先的pb 4 pb new Bitmap(*rhs.pb); //令pb指向*pb的一个复件(副本) 5 delete pOrig; //删除原先的pb 6 return *this; 7 } 现在如果“new Bitmap”抛出异常pb(及其栖身的那个Widget)保持原状。即使没有证同测试这段代码还是能够处理自我赋值因为我们对原bitmap做了一份复件、删除原bitmap、然后指向新制造的那个复件。它或许不是处理“自我赋值”的最高效办法但它行得通。 如果你很关心效率可以把“证同测试”再次放回函数起始处。然而这样做之前先问问自己你估计“自我赋值”的发生频率有多高因为这项测试也需要成本。它会使代码变大一些(包括原始码和目标码)并导入一个新的控制流分支而两者都会降低执行速度。Prefetching、caching和pipelining的指令的效率都会因此降低。 在operator函数内手工排列语句(确保代码不但“异常安全”而且“自我赋值安全”)的一个替代方案是使用所谓的copy and swap技术。这个技术和“异常安全性”有密切关系所以由条款29详细说明。然而由于它是一个常见而够好的operator撰写办法所以值得看看其实现手法像什么样子 1 class Widget { 2 ... 3 void swap(Widget rhs); //交换*this和rhs的数据详见条款29 4 ... 5 }; 6 Widget Widget::operator(const Widget rhs) 7 { 8 Widget temp(rhs); //为rhs数据制作一份复件(副本) 9 swap(temp); //将*this数据和上述复件的数据交换。 10 return *this; 11 } 这个主题的另一个变奏曲乃利用以下事实(1)某class的copy assignment操作符可能被声明为“以by value方式接受实参”(2)以by vlaue方式传递东西会造成一份复件/副本(见条款20) 1 Widget Widget::operator(Widget rhs) //rhs是被传对象的一份复件(副本)注意这里是pass by value。 2 { 3 swap(rhs); //将*this的数据和复件/副本的数据互换 4 return *this; 5 } 我个人比较忧虑这个做法我认为它为了伶俐巧妙的修补而牺牲了清晰性。然而将“copy 动作”从函数本体内移至“函数参数构造阶段”却可令编译器有时生成更高效的代码。 请记住 1、确保当对象自我赋值时operator有良好行为。其中技术包括比较“来源对象”和“目标对象”的地址、精心周到的语句顺序、以及copy-and-swap。 2、确定任何函数如果操作一个以上的对象而其中多个对象是同一个对象时其行为仍然正确。
