C++ 11和C++98相比有哪些新特性

C++11標準提供了許多有用的新特性。這篇文章特別針對使C++11和C++98相比看上去像一門新語言的特性，因為：

C++11改變了書寫C++代碼的風格和習慣，也改變了設計C++庫的方式。例如，你會看到更多的被當作參數和返回值的智能指針，還有按值(by value)返回巨大對象的函數。

它們被使用的非常廣泛，在大多數代碼中你都能看到它們。舉個例子，在現代C++中幾乎每5行C++代碼你就能看到auto關鍵字。

還有一些其它的非常好的C++11新特性，但先把這篇文章所描述的新特性熟悉起來把，因為這些被廣泛使用的特性展示了為什么C++11代碼是簡潔的，安全的和快速的，就像其它現代主流開發語言一樣，并且性能和傳統C++一樣強大。

1. Auto

在任何可能的時候使用auto。因為有兩個原因。第一，非常明顯，能夠避免重復輸入我們已經聲明的并且編譯器已經認識的類型名稱，這是非常方便的。

// C++98
map<int,string>::iterator i = m.begin();
double const xlimit = config["xlimit"];
singleton& s = singleton::instance(); 
// C++11
auto i = begin(m);
auto const xlimit = config["xlimit"];
auto& s = singleton::instance();

 第二，當有遇到一個你不知道或者無法用語言表達的類型時，auto就不僅僅是使用方便這么簡單了，比如，大多數lambda函數的類型，你不能夠容易的將其類型拼寫出來甚至根本就不能夠寫出來。

// C++98
binder2nd< greater > x = bind2nd( greater(), 42 ); 
// C++11
auto x = [](int i) { return i > 42; };

注意，使用auto并沒有修改代碼的語義。代碼仍然是靜態輸入(statically typed)的,并且每個表達式都干凈利落；只是不再強制我們多余的重新聲明類型的名稱。

一些人開始的時候害怕使用auto，因為給人的感覺像是并沒有聲明（重新聲明）我們想要的類型，這意味著我們可能會突然得到一個不同的類型。如果你想顯示的做強制類型轉換，這沒有問題；聲明目標類型就可以了。但是在大部分情況下，使用auto就足夠了，由于出現錯誤而得到另外一個類型的情況很少見，在使用強靜態類型（strong static typing）情況下，如果類型出現錯誤編譯器就會告訴你。

2. 智能指針，no delete

總是使用智能指針，不要用原生指針和delete。除非需要實現你自己的底層數據結構（把原生指針很好的封裝在類(class boundary)中

如果你知道你是另外一個對象的唯一擁有著，使用unique_ptr來表示唯一的擁有權。一個"new T"表達式能很快的初始化一個擁有 這個智能指針的對象，特別是unique_ptr。典型的例子是指向實現的指針（Pimpl Idiom）：

// C++11 Pimpl idiom: header file
class widget {
public:
  widget();
  // ... (see GotW #100) ...
private:
  class impl;
  unique_ptr<impl> pimpl;
};
// implementation file
class widget::impl { /*...*/ };
widget::widget() : pimpl{ new impl{ /*...*/ } } { }
// ...

使用shared_ptr來表示共享所有權（shared ownership）。使用make_shared來創建共享對象更好。

// C++98
widget* pw = new widget();
:::
delete pw;
// C++11
auto pw = make_shared<widget>();

使用weak_ptr來打破循環和表示可選性（比如實現一個對象緩存）

// C++11
class gadget;
class widget {
private:
  shared_ptr<gadget> g; // if shared ownership
};
class gadget {
private:
  weak_ptr<widget> w;
};

如果你了解到另外一個對象比你的生存周期要長，并且你想觀察這個對象，那么使用原生指針（raw pointer）。

// C++11
class node {
 vector<unique_ptr<node>> children;
 node* parent;
public:
 :::
};

3. Nullptr

用nullptr來表示一個空指針，不要再使用數字0或者宏NULL來表示空指針了，因為這些是模棱兩可的，既能表示整形也可表示指針。

 // C++98
int* p = 0;
// C++11
 int* p = nullptr;
 
4. Range for

對一個范圍內的元素進行有序訪問，基于range的for循環會是更方便的用法。

 // C++98
  for( vector<int>::iterator i = v.begin(); i != v.end(); ++i ) {
  total += *i;
 } 
// C++11
 for( auto d : v ) {
     total += d;
}

5. 非成員begin和end

使用非成員函數begin(x)和end(x)(不是x.begin()和x.end())，因為begin(x)和end(x)是可擴展的，能同所有容器類型一塊工作——甚至數組也可以——并不是只針對提供了STL風格的x.begin()和x.end()成員函數的容器。

如果你正在使用一個非STL集合類型，這個類型提供迭代器但不是STL風格的x.begin()和x.end()，你可以對他的非成員函數begin()和end()進行重載，這樣你就可以使用同STL容器同樣的風格進行編碼。標準中舉了一個例子：數組，并且提供了對象的begin和end函數：

 vector<int> v;
 int a[100]; 
  // C++98
 sort( v.begin(), v.end() );
  sort( &a[0], &a[0] + sizeof(a)/sizeof(a[0]) ); 
  // C++11
 sort( begin(v), end(v) );
 sort( begin(a), end(a) );

6. Lambda函數和算法

Lambda表達式改變了游戲規則，它會時不時的改變你的編碼方式，這種方式優雅并且快速。Lambda使現存STL算法實用性提高了百倍。
新增加的C++庫的設計都以支持lambad表達式為前提(例如：PPL)，甚至有一些庫需要通過你編寫lambda表達式來使用庫（例如：c++ AMP）。
這里有個例子，找到v中的>X并且<Y的第一個元素。在C++11中，最簡單并且干凈的代碼是使用標準算法。

 // C++98: write a naked loop (using std::find_if is impractically difficult)
 vector<int>::iterator i = v.begin(); // because we need to use i later
 for( ; i != v.end(); ++i ) {
     if( *i > x && *i < y ) break;
 } 
 // C++11: use std::find_if
 auto i = find_if( begin(v), end(v), [=](int i) { return i > x && i < y; } );

想使用一個循環或者類似的語言特性（language feature）但實際上在該語言中并不存在，怎么辦？將其實現成模板函數（庫算法）就可以了，多虧了lambda，使用它就像是用一個語言特性一樣的方便，但是更靈活，因為它確實是一個庫而不是一個固定的語言特性。

 // C#
  lock( mut_x ) {
     ... use x ...
  } 
  // C++11 without lambdas: already nice, and more flexible (e.g., can use timeouts, other options)
 {
      lock_guard<mutex> hold { mut_x };
      ... use x ...
 }
 // C++11 with lambdas, and a helper algorithm: C# syntax in C++
// Algorithm: template<typename T> void lock( T& t, F f ) { lock_guard hold(t); f(); }
 lock( mut_x, [&]{
     ... use x ...
 });

熟悉一下lambda吧，你會發現他們很有用，并不只是在c++中，它們已經在幾個主流語言中得到支持并且流行開來。

7. Move/&&

把move當作是對拷貝的優化最合適不過了，雖然它也包含其他方面的東西（像完美轉發(perfect forwarding)）
move語義改變了我們設計API的方式。我們會越來越多的將函數設計成return by value。

  // C++98: alternatives to avoid copying
  vector<int>* make_big_vector(); // option 1: return by pointer: no copy, but don't forget to delete
 :::
  vector<int>* result = make_big_vector(); 
  void make_big_vector( vector<int>& out ); // option 2: pass out by reference: no copy, but caller needs a named object
  :::
  vector<int> result;
  make_big_vector( result ); 
 // C++11: move
 vector<int> make_big_vector(); // usually sufficient for 'callee-allocated out' situations
 :::
 auto result = make_big_vector(); // guaranteed not to copy the vector

 
如果你想獲得比copy更高效的辦法，對你的類型使用move語義吧。

8. 統一初始化和初始化列表

沒有發生變化的：當初始化一個non-POD或者auto的本地變量時，繼續使用熟悉的不帶額外花括號{}的=語法。

 // C++98 or C++11
 int a = 42;        // still fine, as always 
 // C++ 11
auto x = begin(v); // no narrowing or non-initialization is possible

在其他情況中（特別是隨處可見的使用（）來構造對象），使用花括號{}會更好。使用花括號{}能避免一些潛在的問題：你不會突然得到一個收縮轉換(narrowing conversions)后的值(比如，float轉換成int),也不會有偶爾突發的未初始化POD成員變量或者數組的存在，也能避免在c++98中會碰到的奇怪事：你的代碼編譯沒問題，你需要的是變量但實際上你聲明了一個函數，這都源于C++聲明語法的模糊不清，Scott Meyers的著名說法：“C++最令人苦惱的解析”。通過使用新風格的語法上面解析問題會不復存在。

  // C++98
 rectangle       w( origin(), extents() );   // oops, declares a function, if origin and extents are types
  complex<double> c( 2.71828, 3.14159 );
  int             a[] = { 1, 2, 3, 4 };
  vector<int>     v;
  for( int i = 1; i <= 4; ++i ) v.push_back(i); 
  // C++11
  rectangle       w   { origin(), extents() };
 complex<double> c   { 2.71828, 3.14159 };
 int             a[] { 1, 2, 3, 4 };
 vector<int>     v   { 1, 2, 3, 4 };
 
新的{}語法在幾乎任何地方都能出色的工作。

 // C++98
 X::X( /*...*/ ) : mem1(init1), mem2(init2, init3) { /*...*/ }
// C++11
 X::X( /*...*/ ) : mem1{init1}, mem2{init2, init3} { /*...*/ }

最后，有時候傳遞不帶(type-named temporary)的函數參數是很方便的：

void draw_rect( rectangle );
 
// C++98
 draw_rect( rectangle( myobj.origin, selection.extents ) );
 // C++11
draw_rect( { myobj.origin, selection.extents } );

我不喜歡使用花括號{}的唯一地方是在初始化一個非POD變量的時候，像 auto x= begin(v);使用花括號會使代碼不必要的丑陋，因為我知道了它是一個類類型，所以我不必擔心收縮轉換，并且現代編譯器已經對額外的拷貝（或者額外move，如果類型是move-enabled）進行了優化。