スコットマイヤーズの効果的なモダンC ++への注釈

数ヶ月前、Scott Meyersは新しい本、 Effective Modern C ++をリリースしました。 近年、彼は間違いなく「これについて」ライターNo. 1であり、さらに彼は素晴らしい講師であり、彼の新しい本はそれぞれC ++ライターによって読まれる運命にあります。 さらに、私は長い間このような本を待っていました、C ++ 11標準が出て、C ++ 14が続き、C ++ 17の前にすでに言語が急速に変化していることがわかりますが、すべての変更が一般的に説明されている場所はありませんそれら、危険な場所、推奨されるパターン。



それでも、Habrを定期的に見て、新しい本に関する出版物を見つけられませんでした。自分で書く必要があるようです。 もちろん、私は完全な翻訳には十分ではないので、簡単に絞り、控えめに注釈と呼ぶことにしました。 私はまた、素材を再編成する自由を取りました、この順序の短い言い直しがより良いように思えます。 すべてのコード例は本から直接引用されており、時々追加されています。



1つの警告：Myers は構文を説明していません。読者がキーワード、ラムダ式の書き方などを知っていると想定されています 。 したがって、誰かがこの本からC ++ 11/14の学習を開始することに決めた場合、参照用に追加資料を使用する必要があります。 ただし、これは問題ではなく、ワンクリックですべてがグーグルになります。

C ++ 98からC ++ 11/14へ。 すべてのニュースのギャロップ

自動 -一見すると、それは単なる大きな砂糖のスプーンにすぎませんが、本質ではないにしても、C ++コードの形式を変えることができます。 Straustrupは、1983年に現在の意味でこのキーワード（具体的だがCでは無用）を導入しようとしていたが、Cコミュニティからの圧力の下でこの考えを放棄したことが判明した。 これによりコードがどのように変更されるかを確認してください。

template<typename It> void dwim(It b, It e) { while(b != e) { typename std::iterator_traits<It>::value_type value=*b; .... } } template<typename It> void dwim(It b, It e) { while(b != e) { auto value=*b; ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目の例は単に短いだけでなく、ここでは、完全に不要な正確な式* bを非表示にします。 さらに、本質的に、式std :: iterator_traits <It> :: value_typeは、参照解除時に取得されるイテレーターのタイプを決定するためにSTLのd明期に発明された独創的な松葉杖にすぎません。ただし、2番目の唯一の演算子には*（）が必要です。 松葉杖でダウン！



納得できない？ ここに別の例がありますが、私の意見では単なるキラーです：

 std::unorderd_map<std::string,int> m; for(std::pair<std::string,int>& p : m) { ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードはコンパイルされません。

、事実は、std :: unordered_map <std :: string、int>の正しい型はstd :: pair < const std :: string、int>であるということです。キーは定数でなければならないのは明らかですが、 autoを使用する方が正確であるよりもはるかに簡単です頭の中の表現のタイプ。

言語に厳密さを追加するいくつかのポイント：

 int x1=1; //1  int x2; //2    ! auto x3=1; //3  auto x4; //4 !    std::vector<int> v; unsigned x5=v.size(); //5   size_t,    auto x6=v.size(); //6  int f(); int x7=f(); //7     f() ? auto x8=f(); //8 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの例からわかるように、 autoを体系的に使用すると、デバッグ時に多くの神経を節約できます。



そして最後に、 autoがなければ、ラムダ式は単に不可能です：

 auto derefUPLess= [](const std::unique_ptr<Widget>& p1, const std::unique_ptr<Widget>& p2) { return *p1 < *p2; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、正確な型derefUPLessはコンパイラーのみが知っており、 autoを使用せずに変数に格納することはできません。 もちろん、次のように書くこともできます。

 std::function<bool (const std::unique_ptr<Widget>&, const std::unique_ptr<Widget>&)> derefUPLess= [](const std::unique_ptr<Widget>& p1, const std::unique_ptr<Widget>& p2) { return *p1 < *p2; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、std :: function <>とlambdaは同じ型ではないため、コンストラクターが呼び出され、おそらくヒープにメモリが割り当てられます。さらに、std :: function <>の呼び出しは、ラムダ関数を直接呼び出すよりも高価になることが保証されています 。

そして最後に-軟膏のハエ、 自動は中括弧で初期化されたときに異なる動作をします：

 int x1=1; int x2(1); int x3{1}; int x4={1};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、これらの式はすべて完全に同等です。

 auto x1=1; auto x2(1); auto x3{1}; auto x4={1};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

x1とx2はint型ですが、x3とx4は異なる型std :: initializer_list <int>になります。 autoが{}イニシャライザーに出会うとすぐに、そのような構成体の内部C ++型-std :: initializer_list <>を返します。 なぜそうなのか、マイヤーズでさえ彼が知らないことを認めており、私も推測しません。



decltype-ここではすべてが多かれ少なかれ単純です。この設計は、テンプレート、特にテンプレートパラメータに応じた戻り値の型を持つ関数の記述をより便利にするために追加されました。

 template<typename Container, typename Index> auto access(Container& c, Index i) -> decltype(c[i]) { .... return c[i]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、 autoは関数名の後に戻り値の型が示されることを単に示し、 decltype（）は戻り値の型、通常はコンテナのi番目の要素への参照を決定しますが、一般的な場合、正確にc [i]が返すものは何でも。

統一された初期化 -名前が新しい標準で暗示しているように、変数を初期化する普遍的な方法を導入しようとしましたが、これは問題ありません。たとえば、次のように記述できます。

 std::vector<int> v{1,2,3}; //    sockaddr_in sa={AF_INET, htons(80), inet_addr("127.0.0.1")};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、中括弧を使用して、クラスの非静的メンバーを初期化することもできます（通常の括弧は機能しません）。

 class Widget { ... int x{0}; int y{0}; int z{0}; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、クローゼットの中で常に足元にあった常緑のレーキを最終的に隠します。特にテンプレート開発者を悩ますのは次のとおりです。

 Widget w1(); //      , //    Widget w2{}; //         
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、言語の厳密性に向けたもう1つのステップである、新しい初期化により、精度の低下を伴う型変換（縮小変換）が防止されます。

 double a=1, b=2; int x=a+b; // fine int y={a+b}; // error
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし...、すべて同じように、何かがうまくいかなかったという感覚はまだ残っていません。 まず、中括弧が含まれる場合、初期化は常に内部タイプstd :: initializer_list <>を介して行われますが、何らかの理由で、クラスがこのパラメーターを持つコンストラクターの1つを定義する場合、このコンストラクターは常にコンパイラーによって優先されます。 例：

 class Widget { Widget(int, int); Widget(std::initializer_list<double>); }; Widget w1(0, 0); // calls ctor #1 Widget w2{0, 0}; // calls ctor #2 !?
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべての証拠に反して、2番目のケースでは、コンパイラーは理想的な適切なconstructor_1を無視し、constructor_2を呼び出して、intをdoubleに変換します。 ちなみに、クラス定義でint型とdouble型を交換すると、{double、double}のstd :: initializer_list <int>への変換が精度を失うために、コードのコンパイルが通常停止します。



この衝突は、C ++ 11の規則に従って、現在どのコードでも発生する可能性があります。

std :: vector（10、20）は10要素のオブジェクトを作成しますが、

std :: vector {10、20}は、2つの要素のみからオブジェクトを作成します。

上記から、すべてをディルブランチで装飾します-コピーコンストラクターとムーブコンストラクターでは、このルールは機能しません：

 class Widget { Widget(); Widget(const Widget&); Widget(Widget&&); Widget(std::initializer_list<int>); operator int() const; }; Widget w1{}; Widget w2{w1}; Widget w3{std::move(w1)};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

文字通り法の文字に従い、コンパイラがstd :: initializer_listパラメータを使用してコンストラクタを選択し、実際のパラメータがint（）演算子を介して変換されることを期待します。 この場合（コピー/移動コンストラクター）、呼び出されるのはコピーコンストラクターです。



一般に、丸括弧または中括弧のいずれかのタイプの括弧を常に使用するという推奨事項は、間違いなく機能しません。 マイヤーズは、1つの方法に固執し、必要な場合にのみ他の方法を適用することをお勧めします。彼自身は括弧に傾いています。 ただし、テンプレートには問題が残っており、原因はテンプレートパラメータによって決定されます。少なくとも、C ++は退屈な言語のままです。



nullptr-話すことすらありません。明らかにNULLと0 はポインターではありません 。これは、オーバーロードされた関数を呼び出してテンプレートを実装するときに多くのエラーにつながります。 この場合、 nullptrはポインターであり、エラーにはなりません。

エイリアス宣言とtypedef

通常の型宣言の代わりに

 typedef std::unique_ptr<std::unordered_map<std::string,std::string>> UPtrMapSS;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この設計を使用することを提案します

 using UPtrMapSS=std::unique_ptr<std::unordered_map<std::string,std::string>>;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これら2つの式は完全に同等ですが、話はこれで終わりではありません。エイリアスはエイリアステンプレートとして使用でき、これにより柔軟性が高まります。

 template<typename T> using MyAllocList=std::list<T, MyAlloc<T>>; MyAllocList<Widget> lw;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

C ++ 98では、このような構造を作成するために、MyAllocListはテンプレート構造を宣言し、その中の型を宣言し、次のように使用する必要があります。

 MyAllocList<Widget>::type lw;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、物語は続きます。 typedefを介して宣言された型をテンプレートクラス内の依存型として使用する場合、追加のキーワードを使用する必要があります

 template<typename T> class Widget { typename MyAllocList<T>::type lw; ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しい構文ではすべてがはるかに単純です

 template<typename T> class Widget { MyAllocList<T> lw; ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般に、メタプログラミングは、この構文構造によりはるかに簡単になると約束されています。 さらに、C ++ 14以降では、対応する同義語が<type_traits>に導入されます。つまり、通常の代わりに

 typename remove_const<...>::type //   remove_const_t<...>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シノニムを使用することは非常に有用な習慣であり、今すぐ自分自身で耕作を開始する必要があります。 かつて、 typedefはマクロを容赦なく処理しました。忘れず、許さず、同じコインでそれを返済します。

scoped enumsは、言語の内部調和に向けたもう1つのステップです。 実際、クラシック列挙型はブロック内で宣言されましたが、それらのスコープはグローバルなままでした。

 enum Color { black, white, red };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Colorと同じブロックに黒、白、赤が表示されているため、名前空間の競合と目詰まりが発生します。 新しい構文：

 enum class Color { black, white, red }; Color c=Color::white;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はるかにエレガントに見えます。 ひとつだけ-同時に、列挙型から整数型への自動変換が削除されました

 int x=Color::red; //  int y=static_cast<int>(Color::white); // ok
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは確かに言語の厳密さを増すだけですが、私が見たコードの大部分では、少なくともswitchへの転送またはstd :: coutへの出力のために、enumが何らかの形でintに変換されます。

オーバーライド、削除、およびデフォルトは、関数を宣言するときに役立つ新しい単語です。

クラスのこの仮想メンバー関数が基本クラスの特定の関数をオーバーライドする必要があることをコンパイラに通知し、適切なオプションがない場合は、親切にエラーを通知します。 おそらく、ランダムなタイプミスや署名の変更によって仮想関数が通常の関数に変わる状況に遭遇した可能性があります。最も不愉快なことは、すべてが正常にコンパイルされることですが、どういうわけか動作が異なります。 したがって、これは二度と起こりません。 使用を強くお勧めします。

delete-古い（そして美しい）トリックをデフォルトのコンストラクターと代入演算子のprivate宣言で置き換えることを目的としています。 見た目は一貫していますが、それだけではありません。 この手法は、不要な引数の変換を防ぐために、無料の関数にも適用できます。

 bool isLucky(int); bool isLucky(char) =delete; bool isLucky(bool) =delete; bool isLucky(double) =delete; isLucky('a'); // error isLucky(true); // error isLucky(3.5); // error
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同じ手法をテンプレートに使用できます

 template<typename T> void processPointer(T*); template<> void processPointer(void*) =delete; template<> void processPointer(char*) =delete;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後の2つの宣言は、いくつかのタイプの引数に対する関数の生成を禁止しています。

デフォルト -この修飾子は、コンパイラーに自動クラス関数を生成させるため、実際に使用する必要があります。 C ++ 98で自動的に生成される関数には、パラメーターなしのコンストラクター、コンストラクターをコピーするデストラクター、および代入演算子が含まれていました。これらはすべて、必要に応じてよく知られたルールに従って作成されました。 C ++ 11では、移動コンストラクターと代入演算子が追加されましたが、自動関数を作成する規則自体が変更されただけではありません。 ロジックは単純です。自動デストラクタはクラスメンバーと基本クラスのデストラクタを順番に呼び出し、コピー/移動コンストラクタはそのメンバーの対応するコンストラクタを順番に呼び出します。 ただし、これらの関数のいずれかを手動で定義することに突然決めた場合、この合理的な動作は私たちに合わず、コンパイラは動機を理解することを拒否します。その場合、移動するコンストラクタと代入演算子は自動的に作成されません。 もちろん、このロジックはコピーペアにも適用できますが、下位互換性のためにそのままにすることが[今のところ]決定されました。 つまり、C ++ 11では、次のように記述するのが理にかなっています。

 class Widget { public: Widget() =default; ~Widget() =default; Widget(const Widget&) =default; Widget(Widget&&) =default; Widget& operator=(const Widget&) =default; Widget& operator=(Widget&&) =default; ... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

後でデストラクタを定義することにした場合、何も変わりません。そうしないと、移動する関数が単純に消えてしまいます。 コードのコンパイルは続行されますが、対応するコピーが呼び出されます。

noexept-最後に、標準は、C ++ 98に存在する例外の仕様が非効率的であると認識し、その使用を望ましくない（ 非推奨 ）と認識し、代わりに1つの大きな赤いフラグを設定します-noexceptは、関数が例外をスローしないことを宣言します 例外がまだスローされる場合、プログラムは終了することが保証されますが、 throw（）とは異なり、スタックでさえも巻き戻されるとは限りません。 フラグ自体は効率性の考慮から除外されています。スタックを昇格の準備ができている必要がないだけでなく、コンパイラーによって生成されるコードは異なる場合があります。 以下に例を示します。

 Widget w; std::vector<Widget> v; ... v.push_back(w);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しい要素をベクトルに追加するとき、遅かれ早かれ、内部バッファ全体をメモリ内で移動する必要がある状況が発生します。C++ 98では、要素は1つずつコピーされます。 新しい標準では、ベクトルの要素を移動することは論理的であり、桁違いに効率的ですが、注意が1つあります...コピー処理中にいずれかの要素が例外をスローした場合、新しい要素は自然には挿入されませんが、ベクトル自体は通常の状態のままになります。 要素を移動した場合、それらの一部は既に新しいバッファにあり、一部はまだ古いバッファにあり、メモリを動作状態に復元することはすでに不可能です。 解決策は簡単です。Widgetクラスで移動代入演算子がnoexceptとして宣言されている場合、オブジェクトは移動されますが、そうでない場合はコピーされます。

タイプ、その派生、およびそれに関連するすべて

C ++ 98の型推定は、テンプレートの実装、新しい標準、 ユニバーサルリンク 、キーワードautoおよびdecltypeでのみ使用されました 。 ほとんどの場合、引き出しは直感的ですが、競合が発生し、動作メカニズムを理解すると非常に役立ちます。 この擬似コードを取得します。

 template<typename T> void f(ParamType param); f(expr);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでの主なことは、TとParamTypeが一般に2つの異なるタイプであるということです。たとえば、ParamTypeはconst T＆です。 正確な型Tは、実際の型exprとParamTypeビューの両方からテンプレートの実装中に推定され、いくつかのオプションが可能です。

• 最も単純な場合は、ParamTypeがポインターでもリンクでもない場合、式は値によって関数に渡され、すべての参照、const修飾子はexprから削除され、純粋な型は残ります
  
  

   template<typename T> void f(T param); int x=1; const int cx=x; const int& rx=x; f(x); //       param - int f(cx); f(rx);
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• ParamTypeがポインターまたは通常の（ユニバーサルではない）リンクである場合、タイプTが派生すると、リンクは削除されますが、const / volatile修飾子は保存されます
  
  

   template<typename T> void f(T& param); int x=1; const int cx=x; const int& rx=x; f(x); //   - int, param - int& f(cx); //   - const int, param - const int& f(rx); //   - const int, param - const int&
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  直感的には、すべてが完全に透過的であり、テンプレートに示されているように参照によって値を渡しますが、転送されたオブジェクトへのアクセス権を侵害しないように読み取り/書き込み修飾子を保存します。
  
  
• ParamTypeが汎用参照である場合、式のタイプはexprのタイプに依存します。 左辺値の場合、TとParamTypeの両方がリンクとして扱われ、expr- rvalueの場合、通常のリンクと同様のルールが適用されます。
  
  

   template<typename T> void f(T&& param); int x=1; const int cx=x; const int& rx=x; //    - lvalue f(x); //   - int&, param - int& f(cx); //   - const int&, param - const int& f(rx); //   - const int&, param - const int& //  f(1); //   - int, param - int&&
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  

autoの場合、型推論のルールはまったく同じです。この場合、 autoはTパラメーターの役割を果たします。ただし、前述の1つの例外はあります。autoが中括弧で式を見ると、 std :: initializer_list型が表示されます。

decltypeの場合、彼に渡された型はほとんど常に返されますが、最終的に彼らが思いついたのはまさにこのためでした。 ただし、1つのニュアンスがまだ存在します。decltypeは、名前以外のすべての式のリンクを返します。

 int x=1; decltype(x); // x -,   int decltype((x)); // (x) - ,   int&
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、これは、マクロを積極的に使用しているライブラリ以外の人を傷つけることはほとんどありません。

---

私は書かれたものを読み直しました、何かがたくさん判明しました。 しかし、最も興味深いのはこれからです。おそらく2つの投稿に分割する方が良いでしょう。 継続する。