c++中, 乙個引數的建構函式, 承擔了兩個角色。 1、是個構造器, 2、是個預設且隱含的型別轉換操作符。
explicit 是避免建構函式的引數自動轉換為類物件的識別符號。
在c++程式中很少有人去使用explicit關鍵字,不可否認,在平時的實踐中確實很少能用的上。再說c++的功能強大,往往乙個問題可以利用好幾種c++特性去解決。但稍微留心一下就會發現現有的mfc庫或者c++標準庫中的相關類宣告中explicit出現的頻率是很高的。了解explicit關鍵字的功能及其使用對於我們閱讀使用庫是很有幫助的,而且在編寫自己的**時也可以嘗試使用。既然c++語言提供這種特性,我想在有些時候這種特性將會非常有用。
按預設規定,只用傳乙個引數的建構函式也定義了乙個隱式轉換。舉個例子:
(下面這個cexample沒有什麼實際的意義,主要是用來說明問題)
#pragma once
class cexample
;#include "stdafx.h"
#include "example.h"
cexample::cexample(void)
: m_ifirst(0)
cexample::~cexample(void)
cexample::cexample(int ifirst, int isecond):m_ifirst(ifirst), m_isecond(isecond)
...//其它標頭檔案
#include "example.h"
int _tmain(int argc, _tchar* argv)
如果在建構函式宣告中加入關鍵字explicit,如下
explicit cexample(int ifirst, int isecond = 4);
那麼cexample objfour = 12; 這條語句將不能通過編譯。在vs05下的編譯錯誤提示如下:
error c2440: 'initializing' : cannot convert from 'int' to 'cexample'
constructor for class 'cexample' is declared 'explicit'
對於某些型別,這一情況非常理想。但在大部分情況中,隱式轉換卻容易導致錯誤(不是語法錯誤,編譯器不會報錯)。隱式轉換總是在我們沒有察覺的情況下悄悄發生,除非有心所為,隱式轉換常常是我們所不希望發生的。通過將建構函式宣告為explicit(顯式)的方式可以抑制隱式轉換。也就是說,explicit建構函式必須顯式呼叫。
引用一下bjarne stroustrup的例子:
class string;
string s1 = 'a'; //錯誤:不能做隱式char->string轉換
string s2(10); //可以:呼叫explicit string(int n);
string s3 = string(10);//可以:呼叫explicit string(int n);再呼叫預設的複製建構函式
string s4 = "brian"; //可以:隱式轉換呼叫string(const char *p);再呼叫預設的複製建構函式
string s5("fawlty"); //可以:正常呼叫string(const char *p);
void f(string);
string g()
在實際**中的東西可不像這種故意造出的例子。
發生隱式轉換,除非有心利用,隱式轉換常常帶來程式邏輯的錯誤,而且這種錯誤一旦發生是很難察覺的。
原則上應該在所有的建構函式前加explicit關鍵字,當你有心利用隱式轉換的時候再去解除explicit,這樣可以大大減少錯誤的發生。
c 中explicit關鍵字
c 中的explicit關鍵字用來修飾類的建構函式,表明該建構函式是顯式的。既然有 顯式 那麼必然就有 隱式 那麼什麼是顯示而什麼又是隱式的呢?按照預設規定,只有乙個引數的建構函式也定義了乙個隱式轉換,將該建構函式對應資料型別的資料轉換為該類物件,如下面所示 include using namesp...
c 中的explicit關鍵字
c 中的explicit關鍵字 c 中的explicit關鍵字用來修飾類的建構函式,表明該建構函式是顯式的,既然有 顯式 那麼必然就有 隱式 那麼什麼是顯示而什麼又是隱式的呢?如果c 類的建構函式有乙個引數,那麼在編譯的時候就會有乙個預設的轉換操作 將該建構函式對應資料型別的資料轉換為該類物件,如下...
c 中的explicit關鍵字
c 中的explicit關鍵字用來修飾類的建構函式,表明該建構函式是顯式的,既然有 顯式 那麼必然就有 隱式 那麼什麼是顯示而什麼又是隱式的呢?如果c 類的建構函式有乙個引數,那麼在編譯的時候就會有乙個預設的轉換操作 將該建構函式對應資料型別的資料轉換為該類物件,如下面所示 class myclas...