考察以下代碼：

extern float _x;//user code class Point3d { public:Point3d(float, float, float);//問題來了， 是哪一個(gè) _x？float X() const {return _x;}void X(float x) const { _x = x;} private:float _x, _y, _z; };

許多人可能會(huì)說， 應(yīng)該是 class 中的 _x，但是很難保證在不同的編譯器上行為一致， 因此就有了以下兩種防御性的設(shè)計(jì)風(fēng)格：

class Point3d {//#1//在 class 聲明的起頭處放置所有的 data memberfloat x, y, z; public:float X() const {return _x;}//... }；class Point3d {//#2//把 inline 移到 class 之外 Point3d();float X() const;void X(float) const;//... };inline float Point3d:: X() const {return _x;}

這種風(fēng)格至今存在， 但已不是必要手段， C++ 2.0 之后， 有了這樣一個(gè)規(guī)則：如果一個(gè) inline 函數(shù)實(shí)體在整個(gè) class 聲明未被看見之前， 是不會(huì)被評估求值的。也就是說， 考察以下代碼：

extern int _x;class Point3d { public://對于函數(shù)本身的分析將延遲//直到 class 聲明的右大括號出現(xiàn)才開始float X() const {return _x;} private:float _x; }; //事實(shí)上， 對 class 的分析從這才剛開始

因此，在一個(gè) inline member function 軀體之內(nèi)的一個(gè) data member 綁定操作， 會(huì)在整個(gè) class 聲明后才發(fā)生。
但是， 這對于 member function 的 argument list 并不為真。Argument list 中的名稱還是會(huì)在它們第一次遭遇時(shí)被適當(dāng)?shù)?resolve。 因此在 extern 和 nested type names 之間的非直覺綁定還是會(huì)發(fā)生， 考察以下代碼：

typedef int length;class Point3d { public://wtf！length 被 resolve 為 global//沒問題， _val 被 resolve 為 Pointd：：_valvoid mumble(length val) {_val = val;} //此處在接下來 定義 length 后會(huì)被認(rèn)定不合法length mumble() {return _val;}//... private://length 必須在此 class 對它的第一個(gè)參考操作之前被發(fā)現(xiàn)//這樣就導(dǎo)致編譯器顯示先前的參考操作不合法typedef float length;length _val; };

在這樣的情況下， 就需要之前的防御風(fēng)格： 把 nwsted type 聲明放在 class 的起始處， 就可以避免導(dǎo)致的非直覺綁定。

轉(zhuǎn)載于:https://www.cnblogs.com/wuOverflow/p/4104467.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的Data Member 的绑定的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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