每當(dāng)一個(gè)類聲明僅將另一個(gè)類用作指針時(shí)，使用一個(gè)類正向聲明而不是包括頭文件是否有意義，以搶先避免循環(huán)依賴問(wèn)題？因此，與其具有：//file C.h#include "A.h"#include "B.h"class C{ A* a; B b; ...};改為這樣做：//file C.h#include "B.h"class A;class C{ A* a; B b; ...};//file C.cpp#include "C.h"#include "A.h"...有什么理由不這樣做嗎？C ++ 前向聲明
3 回答
拉莫斯之舞
TA貢獻(xiàn)1820條經(jīng)驗(yàn) 獲得超10個(gè)贊
前向聲明方法幾乎總是更好。（我想不出包含可以使用前向聲明的文件更好的情況，但我不會(huì)說(shuō)總是最好以防萬(wàn)一）。
前向聲明類沒(méi)有任何缺點(diǎn)，但是我可以想到一些不必要的包含標(biāo)頭的缺點(diǎn)：
編譯時(shí)間更長(zhǎng)，因?yàn)榘ㄔ趦?nèi)的所有翻譯單元
C.h也都將包含A.h，盡管他們可能不需要。可能包括您不需要間接使用的其他標(biāo)頭
用不需要的符號(hào)污染翻譯單元
您可能需要重新編譯包含該標(biāo)頭（如果更改）的源文件（@PeterWood）
溫溫醬
TA貢獻(xiàn)1752條經(jīng)驗(yàn) 獲得超4個(gè)贊
是的，使用前向聲明總是更好。
他們提供的一些優(yōu)勢(shì)是：
減少編譯時(shí)間。
沒(méi)有名稱空間污染。
（在某些情況下）可能會(huì)減小生成的二進(jìn)制文件的大小。
重新編譯時(shí)間可以大大減少。
避免潛在的預(yù)處理程序名稱沖突。
因此，實(shí)現(xiàn)PIMPL成語(yǔ)提供了一種從接口隱藏實(shí)現(xiàn)的方法。
但是，向前聲明一個(gè)類會(huì)使該特定類成為不完整類型，并且嚴(yán)格地限制了您可以對(duì)不完整類型執(zhí)行的操作。
您無(wú)法執(zhí)行需要編譯器知道類布局的任何操作。
使用不完整類型，您可以：
聲明一個(gè)成員是對(duì)不完整類型的指針或引用。
聲明接受/返回不完整類型的函數(shù)或方法。
定義接受/返回不完整類型的指針或引用的函數(shù)或方法（但不使用其成員）。
使用不完整類型，您不能：
將其用作基類。
用它聲明一個(gè)成員。
使用此類型定義函數(shù)或方法。
慕工程0101907
TA貢獻(xiàn)1887條經(jīng)驗(yàn) 獲得超5個(gè)贊
有什么理由不這樣做嗎？
方便。
如果您提前知道該頭文件的任何用戶一定也需要包括A做任何事情的定義（或者可能大多數(shù)時(shí)候）。然后，將其一勞永逸地包含進(jìn)去很方便。
這是一個(gè)相當(dāng)棘手的主題，因?yàn)檫^(guò)于寬松地使用此經(jīng)驗(yàn)法則將產(chǎn)生幾乎無(wú)法編譯的代碼。請(qǐng)注意，Boost通過(guò)提供特定的“便利”標(biāo)頭以不同的方式解決該問(wèn)題，該標(biāo)頭將幾個(gè)緊密的功能捆綁在一起。
- 3 回答
- 0 關(guān)注
- 504 瀏覽
添加回答
舉報(bào)
0/150
提交
取消