Meeting C ++ 2013

デュッセルドルフ会議C ++

C ++のカンファレンスに参加できたことがわかりました。 もちろん、レベルはGoingNativeではありません。レポートは異なるレベルでした。 非常に強くて興味深い、そして完全に空です。 私にとって最も重要なことは雰囲気でした-長い間、誰とでも多くの興味深いトピックを個人的に議論していませんでした。 とても気に入ったので、同僚とより個人的にコミュニケーションをとるために、サンクトペテルブルクにC ++ユーザーグループを作成するというアイデアを得ました。 しかし、それについては後で詳しく説明しますが、今のところは会議についてです。 すべてのレポートについて説明したり、語ったりするのではなく、私にとって最も興味深いトピックと、ほとんどすべてのレポートで取り上げられたトピックのみに注目します。

主な傾向

• セマンティクスを移動します。
• 非同期;
• ネット
• 生産性の増加を陰陽で割ったもの
  
  
  • マルチコアアーキテクチャでのC ++アプリケーションのスケーリング。
  • 組み込みシステムのc ++。

移動セマンティクス

それ自体、移動セマンティクスは誰もが知っていると思います。 クイック検索では、Habré（ 1、2、3 ）にいくつかの投稿があります。 ほとんどすべてのスピーカーが彼女から何かを絞り出した。 おもしろいことに、エリック・ニブラーは、どのようにパラメータを関数に渡し、どのパラメータを返すのが良いのかを推測しました。 シンク引数とコンパイラが右辺値を認識できるという事実を考慮すると、すばらしい要約版が得られました¹ 。

カテゴリー	C ++ 11の推奨事項
入力パラメータ ： 小さい値とシンク値 他のみんな	値渡し const ref
戻り値	値渡し
入力/出力パラメーター	ステートフルアルゴリズムオブジェクト2の使用

非同期性

「非同期は設計から始まる」などの一般的な言葉に加えて、苦情がほとんど聞かれました。結局、言語の非同期入力/出力はまだ存在していません。 同期入出力を持つ非同期プログラムがすべての意味を失うことは明らかです。 したがって、将来の標準、std :: asyncおよびstd :: futureについての話がありましたが、残念ながら、C ++の非同期性は生きているというよりはむしろ死んでいます。 さまざまな優れたライブラリまたはプラットフォーム固有のソリューションを使用できますが、この場所にあった言語にはまだ価値があります。

ステートメントによると、ユニバーサル非同期モデルはC ++ 17にのみ含まれます。 ここで彼女の説明を知ることができますが。

地球上のこの楽園を見越して、私たちは正確に何を使うことができますか？ 新しいものはありません！

• POSIX：aio;
• FreeBSD：kqueue;
• Linux：epoll;
• どこでもブースト:: asio。

ネットワーク

すべてが非同期性と同じくらい悲しいです（悪化していなければ）。 WG21 / SG4 （ネットワークを扱う標準化委員会の研究グループ）の代表者は、今後数年間のロードマップをもたらしました。

• 2014-ネットワークバイトオーダー、URI、IPアドレス。
• 201X-ユニバーサル非同期モデル（同じモデル）、HTTP、リゾルバー。
• 201Y-ソケット、非同期入出力ストリーム。
• 201Z-SSL、ICMP。

個人的には、標準のHTTPがソケットよりも早く表示されることを非常に憂慮しています。 私が正しく理解している場合、これはHTTPの需要がはるかに高いという事実によるものです。

生産性を向上

生産性の改善について話すとすぐに、「アプリケーションを複数のコアに適切にスケーリングするにはどうすればよいですか？」および「組み込み用にアプリケーションを最適化するにはどうすればよいですか？」 C ++と埋め込みがナンセンスだと思うなら、慣れ親しむためのドキュメントのリストを以下に示します。

• システム開発およびデモンストレーションプログラムのジョイントストライクファイター航空車両C ++コーディング標準、ロッキードマーティンコーポレーション、2005年。
• MISRA-C：2008-重要なシステムでのC ++言語の使用に関するガイドライン、MIRA Limited、2008;
• C ++パフォーマンスに関する技術レポート 、第7章組み込みシステムでのC ++の使用。

C ++ 11の側面では、両方の問題を共通の観点から考えることができます。

• 私たちのお気に入りの非同期性：マルチコアアーキテクチャでロックと待機が不要になり、組み込みの多数のスレッドから離れつつあります。
• どこでPODを使用できますか？is_pod、is_trivial、is_standard_layoutがあり、標準ライブラリ（はい、私たちも）がメモリをブロック単位でコピーできる場所とビット単位のコピーを行う必要がある場所を見つけることができます。
• 移動セマンティクスなしではどこにもありません。 不要な動きを節約します。
• コンパイル段階で可能なすべてを取り出します。 特に、標準のアルゴリズムで使用できるstd ::配列がありますが、同時に動的なメモリ割り当てを避けています。
• std :: shared_ptr、std :: unique_ptrを使用してメモリを管理します。

ちなみに、std :: shared_ptrについては。 Going Native'2012レビューでは、std :: shared_ptrコンストラクターの代わりにstd :: make_sharedを使用する必要がある理由について言及しています。

auto sp1 = make_shared<T>( args ); // 1 allocation, 24 bytes overhead shared_ptr<T> sp2( new T( args ) ); // 2 allocations, 40 bytes overhead
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Rainer Grimmは、通常のポインター、std :: shared_ptr、std :: unique_ptrなど、さまざまなアプローチのパフォーマンスを比較するのが面倒ではありませんでした。 ³

 auto st = std::chrono::system_clock::now(); for (long long i=0 ; i < 100000000; ++i){ int* tmp(new int(i)); delete tmp; // std::unique_ptr<int> tmp(new int(i)); // std::shared_ptr<int> tmp(new int(i)); // std::shared_ptr<int> tmp= std::make_shared<int>(i); } std::chrono::duration<double> dur=std::chrono::system_clock::now() - st(); std::cout << dur.count();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのような比較表を得た。

ポインタ型	実際のハードウェア	仮想化
ネイティブ	3.0秒	5.7秒
std :: unique_ptr	2.9秒	5.7秒
std :: shared_ptr	6.0秒	11.8秒
std :: make_shared		6.5秒

---

参照資料

1. エリック・ニーブラー、C ++ 11および妥協のないライブラリー設計

2.出力パラメーター、移動セマンティクス、およびステートフルアルゴリズム

3. Rainer Grimm、C ++ 11を使用した組み込みプログラミング