學(xué)生大本營中有同學(xué)提出這個問題，感覺有一定代表性，這里做個回答。 一家之言哈，歡迎拍磚。 問題： ?? C++中當(dāng)函數(shù)返回值類型時，系統(tǒng)會默認(rèn)調(diào)用拷貝構(gòu)造函數(shù)將返回值復(fù)制到函數(shù)作用域外，然后銷毀超出作用域的對象，再將作用域外的臨時對象拷貝到接收對象中。基于此問題，在下一直以為，不應(yīng)該依靠“隱式”的行為。而數(shù)周之前在《C++編程思想》中不慎找到了解決該問題的理論，但由于其理論過于合理以致代碼測試拖到了日前進(jìn)行，目前的問題在于：基于我所理解的該書中描述的理論，我所設(shè)計的代碼并不能正確運(yùn)行，因此想在此請教各位。 ??? 根據(jù)記憶，該書中出現(xiàn)的理論大概是這么個意思：
struct? X
{
????? int num;
};
X? fun (const? X?? &test)
{
????? X? copy;
????? copy.num=test.num;
????? return?? copy;
}
在這里書上指出了這個fun函數(shù)存在性能損失：在函數(shù)作用域內(nèi)建立了一個對象，在超出作用域之后它必須被銷毀，而在返回類型值的時候又必須調(diào)用一次拷貝構(gòu)造函數(shù)以建立函數(shù)作用域外的臨時對象，如此一來增加了無謂的性能損失。問題的關(guān)鍵在于，書上說可以將代碼改寫成如此形式提高性能：
X?? fun? (const X? &text)
{
????? return??? X(test);
}
一旦改成如此形式，由于構(gòu)造函數(shù)位于return語句中，那么此代碼的效果將指示編譯器直接將臨時對象創(chuàng)建在函數(shù)作用域之外而省去了一次對象的創(chuàng)建和銷毀工作。 ??? 現(xiàn)在進(jìn)入主題：如果按照這個理論，那么我認(rèn)為改寫之后的函數(shù)是屬于顯式調(diào)用拷貝構(gòu)造函數(shù)而將臨時對象創(chuàng)建在了函數(shù)作用域外，也就是說，如果此理論成立，那么即使我將拷貝構(gòu)造函數(shù)聲明為explicit的，那么測試這種機(jī)制的代碼也應(yīng)該能通過編譯并運(yùn)行——我顯式地調(diào)用了拷貝構(gòu)造函數(shù)傳值。但是，從我測試的代碼來看，即使使用第二個版本的函數(shù)也還是會隱式地調(diào)用拷貝構(gòu)造函數(shù)。 ??? 那么我想問的是，如何在不使用引用和指針，也不使用包裝器函數(shù)的情況下，在函數(shù)返回值類型的過程中消除構(gòu)造函數(shù)的隱式調(diào)用？ ??? 具體一些的話就是：如果我將拷貝構(gòu)造函數(shù)聲明為explicit的，不使用引用和指針，也不使用包裝器，如何設(shè)計返回值類型的函數(shù)？ ??? 我使用的編譯器是gcc，IDE是DEVCPP 4.9.9.2 。 我的回答： 這個問題很怪異，我覺得甚至不是一個問題。
首先，一般說來，我的習(xí)慣，不會使用struct的C++特性，如果要定義類，用class更好一點(diǎn)。struct用來存放純數(shù)據(jù)較好。
一般不建議返回復(fù)雜的函數(shù)返回值，比如你文中的例子，一定要返回一個對象，我的習(xí)慣是不要這么做。
在C和C++語言中，我一般習(xí)慣于區(qū)分簡單變量和復(fù)雜變量，int這類基本類型屬于簡單變量，系統(tǒng)可以默認(rèn)拷貝，處理就很簡單，而對象，結(jié)構(gòu)體實(shí)例一般數(shù)據(jù)復(fù)雜變量，一般不建議使用函數(shù)返回值形式默認(rèn)返回。一般是單獨(dú)構(gòu)建一個Copy函數(shù)，來針對性做拷貝動作，避免出錯。
原則很簡單，就是不要在函數(shù)中向外返回復(fù)雜變量，里面太多隱式操作，不直觀，不明顯。給自己造成潛在bug的可能性，就不劃算了。
因此，上述拷貝構(gòu)造函數(shù)，我其實(shí)在工程中，一次都沒有用過，這么多年也算把飯錢賺到手了，呵呵。
至于你說的性能損失，我要說有點(diǎn)吹毛求疵了。事實(shí)上，基于編譯器的性能損失，我一般不考慮，因?yàn)閷?shí)際工程中，有時候，換個算法，早就找補(bǔ)回來了。如果一個系統(tǒng)會對這點(diǎn)性能損失敏感，首先說明的是這個系統(tǒng)有問題，需要改系統(tǒng)設(shè)計。
因此，除了做游戲時，有時候高速圖形刷屏，對編譯器級的性能敏感外，一般工程應(yīng)用，都不考慮這個問題。
我們考慮更多的，反而是架構(gòu)的合理性。多一個無謂的節(jié)點(diǎn)，拓?fù)浣巧?#xff0c;有時候帶來的性能的損失更大。
一般說來，就語言談?wù)Z言，而不是和具體工程應(yīng)用結(jié)合著討論，一般性能意義不大。

轉(zhuǎn)載于:https://blog.51cto.com/tonyxiaohome/198796

總結(jié)

以上是生活随笔為你收集整理的商用工程开发中的一些习惯的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。