睜開眼看大神們的C++11

1、首先有個C11和有個C++11。。但是我還是沒弄懂他們之前的差別。

2、本文主要讨論新增的變化中比較有争議性的部分。

3、C++存在的意義：有運作效率和開發效率的平衡性是接近最理想的，如果哪天出現了一門運作效率和開發效率總評估值超過C plus plus的語言，那CPP得進入曆史的垃圾桶。

争議1：初始化清單方式，強制提升編碼人員的素養

這種初始化方式怎麼覺得是從腳本語言這邊學習過來的，之前我在工作遇到同僚用table寫的的元件時他初始化的方式就是用這種大括号加内部指派的形式調用的。細節不同，但是思想是一緻的。

自定義的類要求重載[]、=操作才能支援C++11提供的初始化清單方式初始化，同時即要求自定義對象有無形參的構造函數（可以是隐式合成的）。 這樣子初始化的方式分别調用了無參構造函數、[]下标重載函數、=指派操作函數，之後或再調用指派構造函數、普通構造函數等完成init行為。整體而言，效率不高，但是完成了接口的适應性。記住接口、庫這兩個詞，感覺是這次C++11更新的核心目标之一。實際使用中，根據情況定義其他構造方法，這樣子其他人執行個體化這個對象的才能直接通過構造函數的提示完成傳參，而不是去閱讀庫或被調用子產品的源碼。簡單點了解：寫元件給别人使用時，要有接口說明，不要強迫别人去閱讀你的實作代碼才能使用之。

然而在注釋和命名規範中，有一條是：用命名去代替注釋。似乎這初始化清單構造和它是天敵，因為自定義類支援初始化清單方式意味着無處可命名，都是必要環節都是重載。庫或元件的作者必須在其他地方注釋，這樣子将會要求C++編碼人員有比較好的程式設計風格，意味着同僚間的代碼風格有一定類似，分分鐘會導緻工作者有負面情緒：who had written these codes。雖然{}方式增加檢測類型窄化檢測，提供了更加合理類型比對，但是這一個設計仍将會具有争議性。

争議2：auto/decltype  這對組合是把雙刃劍

這兩個關鍵字将會增加了代碼的不确定性，或者說降低可讀性吧。原則上，能用基礎類型和自定義類型聲明的資料，盡量不要使用auto，一旦使用auto，等于該資料的類型範圍被泛化了，隻能使用decltype來鎖定。但是這個組合有個很明顯的優越性，使用庫或者其他子產品互動時，auto因為有自推斷能力，進而比對資料來源，降低了庫或其他子產品代碼更新引發的編譯時或運作時錯誤，增強了代碼的向後相容性。

而僅自己使用的局部代碼除非必要，應該很少使用auto類型，可讀性很差，比如某些開源的庫代碼，大家懂的。

争議3：lambda。

std::for_each(

    Q.m_pHead,Q.m_pTail,

    [=](QueueItem<Type> i)

    {

       this->push_back(i.item);

    }

)

雙手點贊，真的很實用。代碼風格開始和其他java或者Python這些趨同啦。跟仿函數的思想類似，主要用于局部匿名資料操作，隻要注意參數的傳遞問題，其開發效率極高，具體的實作方式目前還沒挖到，敬請期待。可以當他是可為實參的手寫inline函數對象，這樣子了解之後，思維順暢了，再去認真補補它真正地設計思維，工作代碼更新無壓力。

争議4：線程的引入。這塊我沒啃完呢。至于final/overide、assert_static、智能指針優化之類，很早前就有類似的實作庫，并且被大家所接受啦，C++必須與時俱進。