explicit 為毀滅而生的補丁

如果建構函式只有1個引數，則可以用等號隱式地呼叫建構函式，如下所示

#include
using
namespace std;
class
aprivate
:int number;};
intmain()

以上，main函式中的2種構造方式是等價的。

另外，對於有多個引數的建構函式，如果除了第1個引數外，其餘的引數都提供了預設值，則也可以進行上述隱式轉換動作。

一般情況下，這種特性並沒有帶來多大的好處，所以通常是要禁用掉這個隱式轉換的特性的。

正如上面注釋掉的**所示，在相應的建構函式前面加上關鍵字explicit，即可阻止建構函式的隱式轉換。此時，main函式中的第1種構造方式會報錯。

通過一種特殊的成員函式，可以使某個class具有「隱式地轉換為其它型別資料」的能力。

比如如下**中，operator int()函式使得class a可以隱式地轉換為int型別資料。

#include
using
namespace std;
class
a/* explicit */
operator
int(
)const
private
:int number;};
intmain()

以上，儘管operator int()的函式宣告形式比較詭異（嚴格來說連返回值的型別都沒有標明），但是這個函式是必須要返回int型資料的，並且這個函式是不能有引數的。

另外，也可以把int替換為double、char等其他資料型別。

與前面「禁用建構函式的隱式轉換」一樣，可以在相應的轉換函式前面加上關鍵字explicit，來阻止相應的隱式轉換。此時上述main函式中的第1個cout會報錯，第二個cout仍舊可用。

這種隱式轉換機制建立的初衷暫時還不知道為什麼，不過顯然這種特性引起的困惑也不小，所以還是建議禁用掉這種特性。而且，如果確實需要這樣一種型別轉化功能，最好還是通過成員函式來實現，比如說converttoint這種。

注意，如下**是編譯不過的，main函式中進行的加法有錯誤。

#include
using
namespace std;
class
aoperator
int(
)const
a operator+(
const a &rv)
const
private
:int number;};
intmain()

在進行a1 + 2動作時，編譯器認為有2種路徑可以選：

1、將a1通過轉換函式，隱式地轉換成int，然後再與2相加，得到int型的結果後，再通過a的建構函式隱式轉換為a型別物件。此時上述加法對應的實際動作為a a2 = a(int(a1) + 2);

2、通過a的建構函式，隱式地將數值2轉化為a型別物件，然後呼叫過載後的加法運算子進行2個a型別物件的加法。此時上述加法對應的實際動作為a a2 = a1 + a(2);

顯然這種二義性是不允許的，vscode中的錯誤提示為：

有多個運算子「+」與這些運算元匹配: – 內建運算子「arithmetic + arithmetic」 – 函式「a::operator+(const a &rv) const」 – 運算元型別為: a + int

經過上述討論，至少我認為「轉換函式」是可以徹底**掉了，而「建構函式的隱式轉換」功能也沒有什麼存在的意義了，explicit關鍵字的產生似乎也就是為了在保證向前相容的前提下，堵住這2個窟窿，扼殺掉一些抖機靈的code技巧，避免了實際工作中在一些犄角旮旯的問題上耗費過多的工時。

我覺得在不久的將來，會有一家公司率先在內部的《c++開發基本規範》中追加對explicit關鍵字的強制使用，以及對轉換函式的禁用。或者直接把這個規則寫到**規範檢查的指令碼裡去。立個flag，拭目以待吧。