在構造函數範圍初始化而不是成員初始化列表

我最近加入了一個項目，項目中的一個主要接口類在下面進行了初始化。在構造函數範圍初始化而不是成員初始化列表

class CCom_Itf 
{ 
    CCom_Itf(IGlobalInterfaceTable *git_ptr): m_git_ptr(NULL), m_ComInitialized(false) 
    { 
     m_git_ptr = git_ptr; 
    } 
...

有沒有像上面那樣初始化m_git_ptr有什麼優勢/缺點，或者我錯過了什麼？謝謝。

來源

2014-12-23 cihanyyt

優點：無，除非有一些隱藏的依賴需要這個奇怪的初始化。缺點：你在浪費時間思考某件事情，而你可能正在做其他事情（除非有一些隱藏的依賴關係等等） – juanchopanza

缺點是它以兩種不同的方式被初始化兩次。這不是性能問題，因爲優化編譯器會消除第一個賦值，但這對於代碼可讀性來說是一個問題。選擇一種風格並堅持下去。

注意，在C++ 11這種「雙重初始化」的回來成時尚，具有一流的成員初始化：

class CCom_Itf 
{ 
    m_git_ptr = nullptr; // in-class init 
...

在這樣的情況下，在類初始化將被忽略如果構造函數有一個具有相同成員的初始化列表。然而，這種雙重初始化似乎不太可以避免。

來源

2014-12-23 09:14:35

這個奇怪的初始化 - 分配舞蹈沒有優勢，除非你每個字符的源代碼付費。

對於一個簡單的非常數成員來說，缺點是微不足道的：您編寫的代碼比您需要的要多，並且依靠編譯器注意到舞蹈可以被單個初始化（帶有如果不這樣做，可能會影響性能）。

對於更復雜的類型，可能會有性能成本，因爲默認初始化之後的賦值可能比直接初始化更有效。如果該類型不可轉讓，或者該成員被宣佈爲const，那麼跳舞根本不起作用。

來源

2014-12-23 09:14:49

「正在爲每個字符的源代碼付費」這是一個很好的功能！ –

在構造函數範圍初始化而不是成員初始化列表

回答

相關問題