3. C++Now! 2013

最終更新日時:
が更新

履歴 編集

C++Now! 2013

セッション資料

セッションリスト

キーノート： DOEによるC++の高性能コンピューティング - 過去と未来

C++11とBoostにおけるマルチスレッドプログラミングサポートの概説

  • Survey of Multi-Threaded Programming Support in C++11 and Boost
  • スピーカー： Rob Stewart

このチュートリアルではBoostとC++11によるマルチスレッドプログラミング向けのツールについて概説します。

このセッションの内容に取り入れる事が明らかな項目としては、例えば std::thread や boost::thread 、またより先進的な機能、 例えば std::async 、それに、これらを実現する為のより基本的な部品として、例えばミューテックス(std::mutex)、条件変数(std::condition_variable)、アトミック(std::atomic) などが挙げられる。

つまるところこのセッションでは全体として、BoostやC++11が如何に皆さんのマルチスレッドプログラムのコーディングを助けてくれるのかについて概説します。

Qtのイベントループ、ネットワーク、入出力 API

Qtフレームワークが誕生したのは1990年台始めの頃の事、その時Qtはまだ、単純な目的の為だけに開発されたんだ。そう、グラフィカルプリケーションを作る為のクロスプラットフォームなAPI（それもその当時はせいぜいデスクトップとワークステーション程度を対象にね）としてね。それからQtはその目標を遥かに超えてよく成長してくれました。今日ではGUIツールキットの枠を超えて他の多くのサブシステム群、データベース接続、WEB技術との統合、そしてパワフルな非同期I/Oとネットワーク周りの機能等々を提供するに至っている。このセッションではそれらの中から、QtのI/Oとネットワーク周りについてチュートリアル形式で紹介します。

Qtの全ての非同期的なメカニズム群はイベントループないしメインループによるセントラルイベントハンドリングのループから呼び出されています。そうしてQtが提供する非同期I/Oによる子プロセスの動作や、TCP接続群のアクセプト、TCP接続群の発信の生成、TCPとUDPのI/Oハンドリング、その他のタスク群が構築されています。もちろんそれはHTTPとFTPのダウンロードとアップロードと言った高レベルなイベントにも至ります。このセッションではそれら全てのサブシステム群についてを取り上げ、どうやってアプリケーションにそれらを組み込んで使うのかについて、例示をしたり、それに一緒に議論をしたいと考えています。このセッションを通じてライブラリー開発者とアプリケーション開発者、双方の理解をQtを通して深める機会として頂ければ幸いです。

Boostのコンテナ

Boostライブラリは、多くの便利なコンテナと、標準コンテナの素敵な拡張を提供している。このセッションでは、Boostにある以下のコンテナ群を見ていく： Boost.Multiindex、Boost.Bimap、Boost.CircularBuffer、Boost.PropertyTree、Boost.DynamicBitset、Boost.PointerContainer、Boost.Intrusive。開発者は、自分のプロジェクトに恩恵をもたらすコンテナを選択できるようになるだろう。

C++11での低レベルスレッディング

  • Low Level Threading with C++11
  • スピーカー： Tony Van Eerd

C++は現在、「メモリモデル」を持っている。それは何を意味するのか、それはなぜあるのか、それが必要ならなぜこれまでなかったのか？これがあると我々は何ができるのか？これは新しく入ったアトミック操作と多少関連があるようだ。うーん・・・。

(これは昨年やったチュートリアル「C++11の新たなメモリモデルとアトミック」のアップデートである。)

'優しきそよ風'の見たC++11

  • A Zephyr Overview of C++11
  • スピーカー： Leor Zolman

去年の事、私はC++11の殆どの機能について、たった90分だけの"嵐の様な"セッションで質問に答える間も無く、その可能性について示すに留まった。

そして今年、私は1本90分のセッション枠を拡大して、2本分のセッションを使える事になった。参加してくれるみんな（それに私自身も含めて）、今回はきちんと息をする余裕もあるよ。だから今回は質問に答えたり、それにひょっとしたらライブコーディングをできるチャンスもあるかもしれないね。

内容については凡そ去年のそれと同じにするつもりだけど、去年は時間が無くて扱えなかった言語とライブラリーの機能、それと実装例なんかも用意したいね。

(訳者註: Zephyr(ゼファー)はギリシア神話の風の神様の中で最も温和で春の訪れを告げる豊穣の優しいそよ風の神様のこと。)

Proto-0x初お披露目

Boost.Protoは、C++に組み込みドメイン特化言語(EDSL)を構築するためのライブラリである。Boostでは、Spirit、Phoenix、Xpressive、MSM、それと提案中ではあるがBoost.SIMDのようなライブラリが、Protoによる式テンプレートベースで構築されている。Protoで定義されたEDSLは、手間のかかるテンプレートメタプログラミングの雑用からライブラリ作者を解放し、構文やセマンティックアクションといった面で、高レベルに表現できる。

Boost.Protoの現在利用可能なバージョンは、C++03言語の限界を押し上げてはいるが、言語によって課せられる制約で苦しんでいる。このトークでは、C++11で再設計されたProtoの新バージョンについて話す。これは、EDSLの設計を、これまで以上に簡単かつ安全にできる。

このトークでは、Proto-0xによる小さなEDSL定義の基本をカバーする。新しいProtoは、古いProtoと異なるポイントはあるが、その事前知識は必要ない。C++11の新機能がProtoの設計にどのような影響をもたらしたか、また、それらの機能が一般的なライブラリ設計を、根本的なところでより良くすることを紹介する。

アロケートしないstd::future／promise

  • Non-Allocating std::future/promise
  • スピーカー： Tony Van Eerd

共有状態 - mutex/convarが待ち合わせるように別スレッドの処理の結果を置く場所 - は、futureとpromiseはいつでもムーヴ、破棄され得るので、futureとpromiseで別々にアロケートされる必要があると予想される。故に共有状態には別個のメモリ配置が必要である。

本当にそうだろうか？

このセッションでは、等式の右辺、左辺ともにムーヴ中もしくは破棄されようとしていても、アロケートなしで状態を共有するために細心の注意を払ってロックフリーの技術を用いるstd::future／promiseの草案について説明する。

このセッションは非常にインタラクティヴなものになるだろう。聴者諸氏は実装に漏れがなくなるまで、実装のどのステップについても問題点を指摘していただきたい。このセッションでは、ロックフリーテクニックを現実のコードにどう適用したらいいか、感覚がつかめるだろう。

C++テンプレートメタプログラムのデバッグとプロファイリング

  • Debugging and Profiling C++ Template Metaprograms
  • スピーカー： Zoltan Porkolab

C++テンプレートメタプログラミングは、テンプレートの巧妙な定義によって、C++コンパイラにコンパイル時にアルゴリズムを実行させる、よく知られた手法である。アプリケーションにおけるテンプレートメタプログラムには、式テンプレート、静的なインタフェースチェック、アダプトによるコード最適化、組み込みドメイン特化言語とアクティブライブラリなどがある。C++11の新機能は、テンプレートメタプログラミングをさらに魅力的にする。

その重要性にもかかわらず、C++テンプレートメタプログラミングの設計、保守、分析を支援するためのツールは、驚くほど少ない。テンプレートの重いコードを使用することでプログラムに増加されるコンパイル時間は、その分野への挑戦が少なくなっている理由のひとつである。利用できるデバッガ、プロファイラといったツールの欠如は、テンプレートメタプログラミングの広い使用を妨げている。

我々は、これまでの経験に基づいて、テンプレートメタプログラムのデバッガとプロファイラのプロトタイプツールセットを開発している。このツールセットの目的は、C++テンプレートの使用率が高い、大きなコードベースで作業している、開発者やメンテナのためのサポートを提供することだ。このツールセットは、C++テンプレートメタプログラムのバグやコンパイルボトルネックを調査するという、おもしろいことができる。

このツールセットは、LLVM/ClangオープンソースC++コンパイラインフラストラクチャ上に構築されている。テンプレートに関連するコンパイラアクションの最も重要なキャプチャは、プログラムの「インスタンス化スタック」を記録し、XML形式のトレースファイルを出力する。このファイル内の全てのエントリは、テンプレートインスタンス化の最初か最後を表す。エントリには、Clang仕様のイベントの型が含まれる。さらにくわしい情報は、テンプレートの名前へのインスタンス化、およびインスタンス化によるコードの位置(通常は、呼び出し元)である。プロファイルに関連する情報は、インスタンス化の時間(これは実行時間:wall time)と実際のメモリ使用量が含まれるタイムスタンプである。時間とリソース消費のメモリプロファイリングは、オフにすることができる。プロファイリングの歪み(distortion)を最小限に抑えるには、XMLトレースファイルの内部バッファと生成の遅延を行う。我々の計測では、時間の歪みは3%未満だった。

また、我々はトレースファイルに格納されている結果を資格する、Qtベースのフロントエンドも開発した。このフロントエンドは、実行時デバッガと同様、ユーザーがブレークポイントを設定でき、ステップバイステップでインスタンス化を再生できる、ソースコードビューを持っている。興味のないインスタンス化は、正規表現を使用して可視化から除外できる。他のビューとしては、インスタンス化にかかる時間と、オプショナルなメモリ使用量のプロファイル情報がある。最後に、インスタンス化の依存関係を表現し、インスタンス化手順のアニメーション化とグラフ化を行う。

キーノート： C++の創発的構造を最適化する

今日、C++ソフトウェアの複雑さはいや増している。この複雑さを管理し、大規模アプリケーションやシステムを構築するべく、C++は、シンプルなパターンを組み合わせて非常に複雑かつ強力なシステムをつくりだす創発的構造(自然界ではよく見られる、雪の結晶のような対象構造)をつくりだすべく努力している。このような構造により、各コンポーネントの複雑性を制限し、ソフトウェア開発する上で信頼できるスケーラビリティが得られる。

手持ちのディヴァイスからウェアハウス級データセンターまで、よりディヴァイスを小さくしようとしたりと電力消費を抑えようとして、C++を利用すると、効率と複雑さが相応しないシステムになってしまうことは疑いない。今日も最適化がすすむC++コンパイラはかつてないほどその重要性が高まっているが、現役プログラマにはほとんどそれが伝わっていない。これらのことを鑑みると、高度創発的構造はC++システムを拡大し、しばしば最適化に関する独創的で未解決の問題を提起することがある。

このセッションでは、今日の最適化されたコンパイラがC++コードをいかに高度にコンパイルするか、という概観から始める。次に、C++コードの創発的構造を単純かつエレガントに形成する鍵となる特殊な構造とパターンについて概説する。さらに、このような相互作用をいかに効率的にモデル化し解析できるかについて、効率的な完成プログラムを作るためのコンパイラを使って検証する。実際のケーススタディを例としてとりあげ、最新のC++コードベースで表現され、広く適用可能であることを示す。これらのパターンによる意味に気付いていただくために、最適化されたコンパイラとC++コード双方の相互作用を理解するためのフレームワークを示すことが目的である。最後に、特にそれぞれのコンポーネントが単純さを保持し、組み合わせによって力を発揮する、今日の最適化向けの方法を示すため、C++プログラムやライブラリの設計上、実装上の技術および原理について示す。

おいしい小さな機能たち： 波カッコ初期化、共用体、列挙型

  • Sweating the Small Stuff: Brace Initialization, Unions and Enums
  • スピーカー： Scott Schurr

C++11は多くの派手な新機能がある： ラムダ式、ムーブコンストラクタみたいな。このようなカッコイイ機能に比べてセクシーさでは劣るが、便利な変更がいくつか入った。このトークでは、初心者から中級レベルの専門家に向けて、C++11の波カッコ初期化(一様初期化とも呼ばれる)、共用体、列挙型について話す。

Agdaへの知識向上

  • The Intellectual Ascent to Agda
  • スピーカー： David Sankel

数学とコンピュータサイエンスについて考えていると、漸近解析と物理シミュレーションのビックリするようなアルゴリズムが思いつくことがある。これらはいつも見過ごされがちな表示的意味論であり、構文と意味論の数学である。

表示的設計(denotative design)、表示的意味論の実践は、シンプルで、合成可能で、信じられないほどパワフルなライブラリを作るトップダウン設計の方法論である。これは全く異なる文化のものだが、一般的に使用できる。そのパワフルなテンプレートエンジンは、C++に特に適している。

このセッションでは、純粋関数型で依存型言語であるAgdaの構文を使用して、ドメイン固有の数学的エンティティからC++プログラムに派生させる表示的設計を、以下にして適用するかを学ぶ。

HPX: 非同期並列と分散コンピューティングのためのC++標準準拠ランタイムシステム

  • HPX: A C++ Standards Compliant Runtime System For Asynchronous Parallel And Distributed Computing
  • スピーカー： Hartmut Kaiser, Vinay Amatya

マルチコアとマルチスレッディングは、新しい計算手法であり、科学分野か非科学分野かに関わらず、システムの継続的なスケーラビリティを得るためには、ノード内だけでなくノード間もスケールさせる必要がある。新しいアーキテクチャにおける計算量やサイズ増加といったものは、スタベーション、レイテンシー、オーバーヘッド、競合解決待ちと呼ばれ、これらはシングルコアマシンでも存在はしていたが、表面化しにくかった。Exaflopレベルにシステムを拡張すると、この大幅に少ないリソース使用率の面でコストが増加する。その間、スケーリングシステムであっても、特定クラスのアプリケーションは従来の計算モデルを使用してスケールすることはできない。

HPXは、新たな計算モデルに対する新たなランタイムシステムである(ParalleXは、上述した問題への挑戦である)。HPXはC++で実装され、最新のC++標準とBoostに準拠している。HPXは、新たな計算モデルに対する新たなランタイムシステムである(ParalleXは、上述した問題への挑戦である)。HPXは、様々な実績あるソフトウェア技術とアルゴリズムを、理解しやすくすることができます。HPX APIは、マルチコア・マルチスレッド化された混在アークテキチャとユーザーレベルソフトウェアアプリケーションのシームレスな統合のためのインタフェースを提供し、学ぶのを容易にする。

非同期と計算、通信、それらを組み合わせることは、新たなマルチコア混在アーキテクチャをサポートする、新たな計算モデル要件のひとつとして重要である。非同期タスク(アクションという形式でのローカル関数やリモート関数)は、HPXの主要設計機能のひとつである。HPXは最新のC++標準がサポートしているローカル非同期関数だけでなく、リモート非同期関数も実装している：Actionという。これに加えて、非同期をサポートするのに本質的な、タスク実行中にFutureやDataFlowとしてデータを構築することができる。

マルチコアドメインはシステムアーキテクチャ分野での巨大な飛躍にも関わらず、数十コアを超えたスケーラビリティ制限の課題がある。したがって、高パフォーマンスシステムでは、我々は複数ノードのBeowulfタイプのクラスターに依存している。通信の待ち時間が大幅に増加するようなシステムでは、非同期が大きな役割を果たしている。これに加えて、コアを数万を超えて拡張すると、新たなアドレッシングシステムが必要となり、アクティブアプリケーションのリモートスレッドオブジェクトを一時的に停止するのを許可するだけでなく、リソースの必要性(システム的な失敗やビジー状態)に従ってタスクを移動する必要がある。このアクティブなアドレッシングスキームは、HPXではActive Global Address Space(AGAS)として実装されている。このアドレッシングスキームは、HPXを、アプリケーションの必要性に応じた正しいリソース配置のためのリソースマネージャーをサポートすることを可能にする。

C++11でスケールさせる！

プロセッサのコア数が増加するにつれて、ソフトウェアはムーアの法則からの恩恵を受けるために、複数のタスクを実行できるようにする必要がでてきます。これは並列アルゴリズムを書くという問題だけではなく、スレッド間の依存関係を正しく減らす、アプリケーション設計の問題でもあります。これらの依存関係を見つけることは、シリアルプログラミングの数十年の結果から見ても、非常に難しいことです。したがって、真にスケーラブルなソフトウェアを書くことは、精神状態を適切に適応させることよりも小さな、技術的な専門知識の問題です。

このプレゼンテーションは、超スケーラブルなデータベースである「quasardb」を書いたチームによって使用されている、設計、手法、ツールについて話します。具体的なスケーラビリティの課題として、典型的なマルチスレッドプログラミングのアンチパターンと、それを避ける方法を紹介します。説明するトピックは、以下のものをカバーします：アトミック、マイクロロック、Lock-freeとwait-freeなコンテナ、メモリ管理戦略(copy on write、スマートポインタ、完全転送)、スレッドローカル記憶域、非同期I/I、その他いろいろ！

このプレゼンテーションは、システムプログラミングとC++11(ラムダと右辺値参照)の十分な知識を想定しています。

Charm++を使った並列プログラミング

Charm++は、20年の実績があり、シングルワークステーションから世界最大のスーパーコンピュータまでカヴァーするハイパフォーマンスなC++ベースの並列プログラミングフレームワークである。このフレームワークは共有メモリシステムと分散メモリシステムを、双方のシステムで共通な技術で横断できる並列実行機能を備える。

並列の単位としてオブジェクトを利用することで、Charm++は、関連するオブジェクトのコレクションによる並列アプリケーションロジックが表現できる。これにより、現存するハードウェアを十分効率的に利用する、結合可能な並列ソフトウェアが作成できる。実行中、Charm++のランタイムシステムはアプリケーションの挙動とシステムの状態を観測し、その結果に応じて、オブジェクトとプロセッサのマッピングを行なう。そうすることで、ランタイムシステムは効率よくロードバランスやエネルギー管理といったドメインに依存しない要求を自動化できる。それゆえ、アプリケーション開発者は、アプリケーションやユーザーからのそういった要求に取り組むことから解放される。

このプレゼンテーションではCharm++での並列アプリケーション開発の原理について示す。このパラダイムを使った並列アルゴリズムを記述する利点についても述べる。高速でスケーラブルなソフトウェアを作成するためにCharm++をどのように使うかという例もいくつか紹介する。Charm++を使って、自身の並列プログラムを構築するための並列ロジックをどう組みあげるかについて学習する。

C++の複数コンパイラ間バイナリ互換インタフェースを簡単に作る

  • Easy Binary Compatible C++ Interfaces Across Compilers
  • スピーカー： John Bandela

C++は他の生産性が高い言語から、使うのが難しいと認識されています。その理由のひとつに、バイナリコンポーネントの互換運用性の欠如があります。ライブラリを使用するとそのうち、ソースから構築したり、複数のバイナリを配布したりする必要が出てきます。たとえばWindowsでは、GCC Mingw、Visual C++ 2010(のリリース、デバッグ、静的と動的のCRT)、Visual C++ 2012などのバイナリを配布する必要があります。この問題を回避するための試みがいくつかある。たとえば、選択肢のひとつとしてextern Cを拡張してCOMやXPCOM、C++/CXといったものを追加することが考えられるが、このオプションにはコンパイラの拡張機能を必要とするとともに、現代のC++では低レベルであるように感じる。

C++11を実装している多くのコンパイラは、ラムダ式や可変引数テンプレートといった便利な機能を持っており、これらを使用して簡単に複数のコンパイラ間で動作するバイナリインタフェースを実装できます。

このプレゼンテーションでは、以下の恩恵を受けるための、ライブラリの設計と実装について議論します：

  • 外部ツールを必要としない
  • インタフェースを一度だけ定義し、その定義を実装とユーザーコードで使用する
  • インタフェースは、簡単に実装でき、一度だけ定義すればよい
  • そのインタフェースでstd::string、std::vector、std::pairを使用する
  • 現実的な戻り値で使用する(エラーコードではない)
  • 例外を使用する実装と使い方
  • COMとバイナリ互換性を持つ
  • インタフェースの継承をサポートする
  • 実装の継承をサポートする
  • 実装は、WindowsのVisual C++の実行ファイルとGCCの.dllでテストした
  • 実装は、LinuxのGCCの実行ファイルと、Clangの.soでテストした

このプレゼンテーションでは、上記の機能の実装について議論し、そのいくつかのトレードオフを見ていきます。私は、参加者との、異なるアプローチでこれよりうまく作る方法について議論するのを待ちわびている。

C++でのトランザクショナルメモリ

  • Transactional Memory in C++
  • スピーカー： Michael Wong

C++標準のSG5は、2種類のトランザクションに基いてV1.1 of the Draft Transactional Memory for C++を4年間取り組んでいる。

この提案は、2種類のトランザクションをサポートする：

分離トランザクション(isolated transaction)はいくつかの種類の安全性アノテーションを通じて、非トランザクションコード(と同様のトランザクション)と通常のトランザクションを通信できる。

我々はさらに、完全なコンパイル時チェックから動的チャックまで、様々なレベルの安全性アノテーションをサポートするための異なる手法を示し、プログラマの負担を軽減させる。

これがSG5の技術仕様としてのBrisol 2013の提案意図である。

現在あるいくつかのTMは、時期尚早だと考えているが、ハードウェアサポートが間もなく来るだろう、ということを言わせてほしい。Intelは最近Haswellを発表したし、IBMのBG/Q、それ以前にはSunのRockもある。ソフトウェアTMサポートとしては、IntelはSTMのDraft 1.0をかなり前からサポートしているし、直近ではGCC 4.7がほぼ完全なDraft 1.1をサポートしている。

それでもまだ早すぎると思う場合は、Hans Boehmの発見のひとつが、ロックはジェネリックプログラミングでは実用的ではない、ということだったと言わせてほしい。なぜなら、ロックの順序は一般的にインスタンス化されるまで見えないからだ。C++11で導入されたロック(とアトミック)では、この問題を回避するのが困難だ。トランザクショナルメモリは、この問題を解決するひとつの方法である。それは不規則なデータ構造や、読み取りを主に行うデータ構造(read-mostly structure)に対して細粒度ロックするのにも役立つ。

このトークでは、我々は使用経験やパフォーマンスデータを含む、標準C++への提案を紹介する。

トランザクショナルメモリが十分に速いことに、まだ疑問を持っている？多くのソフトウェアトランザクショナルメモリシステムは異なるパフォーマンス特性を持っているので、どれかはあなたのニーズを満たすと思う。

TMは様々な形(ハードウェア、ソフトウェア、ハイブリッドシステム、ロック省略)で到来している。すでに多くの言語がTMをサポートしているので、C++にこれを提案するのはいい時期だろう。

libcppa - C++11でのアクターセマンティックな設計

並列ハードウェアで効率的にプログラムを実行させるには、並行性は必須である。しかし、並行ソフトウェアを書くことは、挑戦的であり、エラーが起こりやすい。C++はマルチスレッドプログラミングの標準的な設備、acquire/relaseセマンティクスによるアトミック操作とRAIIのミューテックスロッキングを提供するが、これらのプリミティブはあまりにも低レベルである。それらを正しくかつ効率的に使用するには、まだ専門的な知識と手作りが必要だ。アクターモデルは、暗黙的な通信を、明示的なメッセージパッシングメカニズムによる共有で置き換える。これは分散的な並行性として適用でき、事前に次元が決定されたスレッドプール内の全てのアクターをスケジュールした軽量アクターモデルの実装は、スレッドベースアプリケーションと同等のパフォーマンスを出すことができる。しかしアクターモデルは、ネイティブプログラミング言語のベンダー固有のソリューションには入れない。オープンソースライブラリであるlibcppaで我々は、C++11のパフォーマンスとリソース効率を持つアクターモデルによって、信頼性の高い分散システムを構築する能力を統合したい。

ライブラリ開発者が知るべきバイナリ互換性について

  • Binary compatibility for library developers
  • スピーカー： Thiago Macieira

C標準のように、C++標準はコンパイラの重要なふるまいと、合法なプログラムを構成するものを規定している。しかし、ABIとバイナリ互換性に関する問題については、意図的にうまく避けられている。今でさえ、それぞれ独自に管理されるモジュールやダイナミックリンクに関する問題や経験について、あまり議論されていない。Cよりもはるかに複雑かつ強力なので、コンパイラはCよりもはるかにややこしいC++ABIを作る。(原文: Because it is much more complex and powerful than C, compilers implement a C++ ABI that is an order of magnitude more complex than C++. 訳註: Cのtypoか)また、Cとは異なり、単一のプラットフォーム(オペレーティングシステムとアーキテクチャ)であっても、C++のABIはコンパイラごとに異なる。

未だライブラリ開発者はしばしばCやC++標準に定義されていないこの種の問題について、理解したり解決したりする必要に迫られる。これは決して不可能なことではなく、リリース間のバイナリ互換性を保証するための信頼できる単純なガイドラインやチェックリスト、ツールや作業が存在する。これらを利用して、複数のリリースにわたって、大きなライブラリの長期間以前のヴァージョンとの互換性を維持することが可能である。

このプレゼンテーションでは、この種の現実にある問題と主にQtやKDEで使われた解法について述べる。特に、Qt4がどうやって7年間にわたり、9つの機能リリースと数十個のパッチリリースをしてなおリリースバイナリの互換性を維持したのかについて示す。また、間違いとその修正についても示す。その後、どのようにコンパイラがABIを作るのかについて詳細な議論をしたい。

さらなるパラダイムシフト? (並行のMeta4モデル)

特にC++の話として、C++の後ろに見え隠れする非常に先進的なアイデア/技術の兆候から、同型の多細胞生物の受精を例にとって、進化でも革新でもなく、単にmeta4layersの同期をとるだけというさらなるパラダイムシフトの提案に至るまでの言語のライフサイクルについて議論したい。

Inside Spirit X3: C++11で再設計されたBoost.Spirit

  • Inside Spirit X3: Redesigning Boost.Spirit for C++11
  • スピーカー： Joel de Guzman

BoostCon ’07、’08、’09、’10で行ったSpiritの使い方に関するチュートリアルは、大きな成功を収めた。この時間では、Spiritの設計と実装に焦点を当てたプレゼンテーションを行う。さらなる挑戦として、C++11の新機能のアドバンテージを活かして、Boost.Spiritを大きく再設計した。この実験的なバージョン(X3)の、ひとつの大きな目標は、C++の言語機能不足のために失われた「Classic」のエレガントなシンプルさを取り戻すことだ。この90分のプレゼンテーションでは、現代的なC++11コードで今汚いポイントに挑み、私の経験に基づくC++11の欠点を共有した上でC++1yの希望について話したい。

C++コンセプトのための弱い隠蔽: プログラミング言語の名前バインディングについて推論するフレームワーク

  • Weak Hiding for C++ Concepts: via a Framework for Reasoning about Name Binding in Programming Languages
  • スピーカー： Larisse Voufo

C++の名前探索とオーバーロード解決の規則は複雑で(伝統的なスコープ、ADL、テンプレート引数の推論とSFINAE、オーバーロード、それらの組み合わせ)、コンセプトを言語に追加すると、これらの規則がさらに複雑になります。コンセプト付きC++のために名前探索とオーバーロード解決の規則の最高の代替設計を行うことは、現在の規則が不透明であることから困難です。

現在のものと提案中のもの、両方の規則を解説するために、プログラミング言語の名前探索(名前バインディングとも言う)のための解説システムのための統合フレームワークを紹介します。このフレームワークは、現在の規則を説明できるだけでなく、名前探索(とオーバーロード解決)に対してコンセプトの提案がどのような影響を与えるのか理解するのを用意にするためにも使用できます。このモデルは、異なる言語の微妙な違いや潜在的な拡張機能、ADLの複雑さ、演算子を使用する際の標準的な規則の誤解といったものを表現します。さらに、Clangの拡張であるConceptClangなどの既存のコンパイラに対して、C++のコンセプトの実装を調査することも可能にします。

たとえば、C++にコンセプトが含まれていた最後のドラフト(N2914)での名前探索とオーバーロード解決の仕様では、制約テンプレートのところで、現在の規則の元で正しいコードを無効にしてしまいます。この問題が起きる原因は、制約名が、テンプレートの外で定義された名前と同じように扱われるからです。

我々が提案するフレームワークは、「弱い隠蔽(Weak Hiding)」という別な選択肢をとります。これは周囲のスコープ(と関連する名前空間)にある名前が、テンプレート制約の名前のみを使用してオーバーロード解決に成功した場合のみ隠す、という中間のアプローチです。名前バインディングのための我々の統合フレームワークでは、このモデルは、名前バインディング、バインディングなし、(ADLのために)開く、弱い隠蔽という、4つのスコープの関係で表現され、そして関連するその他のアイディアは、言語と設計抽象的な最小限の2つの概念です。このプレゼンテーションでは、名前バインディングインフラストラクチャと主要な調査結果の要約をし、制約テンプレートを定義するための、弱い隠蔽の導入に焦点を当てます。はじめに、初心者と専門家両方の視点から、問題に対する実用的な例として、弱い隠蔽の必要性を示します。その後、我々のConceptClangが行ったいくつかの設計上の決定を説明します。このセッションが終わったあと、参加者は、現在のものと拡張案、両方のC++の名前探索のルールについてより良い理解が得られるでしょう。

Qt5でC++11を使う： 課題と解法

  • C++11 use in Qt5: Challanges and Solutions
  • スピーカー： Thiago Macieira

Qt5は昨年12月にリリースされた、有名なQtフレームワークの最新メジャー版である。C++フレームワークであるので、Qtの開発はもちろんC++11に大きな影響を受け、C++11のおもしろい機能、特に高速なコードの作成や可読性を向上させるような機能を利用しようとした。コンパイラがC++11の機能を実装するほどには、Qtのようなフレームワークは早く実装できなかった。加えて、Qtは二つの問題に直面した。一つ目は、まだ利用しているユーザーがいるので昔のコンパイラとツールチェインをサポートする必要があったこと。二つ目は、Qt4と可能な限りソース互換性を維持するというのが、Qt5の目標ひとつだったことである。このような要求に応えるために、当面のあいだ、C++11の大規模な採用は見送ることなった。

それゆえ、Qt開発者はどのC++11機能を使うべきでないか、どの機能を使うべきか、C++98/03コンパイラ互換をどうやって維持するかについて考える必要性にせまられた。このセッションでは、結局どういう決定を下したのか、また、C++98/03とC++11モードそれぞれでさまざまなコンパイラをサポートする措置について話そうと思う。Qtで適用した解決法、およびC++11とC++03で利用可能である巨大なC++クラスライブラリ構築を試みる際の一般的な考えかたについて知見が得られるだろう。このプレゼンテーションでは、ようするに我々のように、C++03コンパイラ互換性を維持したまま、ライブラリやアプリケーションをC++11に移植する必要にせまられた、C++開発者向けの実践的ガイドラインを示すことが狙いである。

スレッドセーフでスレッド中立なbag

bagは多数のスレッドが処理を実行するために継続的かつ非同期にbagからデータを取り出すようなスレッドシステムで使う基本的なコンテナである。bagはキー操作(get)を持ち、概念上はシンプルであるが、スレッドセーフ(bagの状態は複数のスレッドからアクセスされても一貫性を保持する)かつスレッド中立(スレッド同士が競合しない)に実装しようとするととてつもなく難しくなる。

このセッションではスレッド環境下でのbagの実装について、さまざまな角度から、特に、多数のスレッドがbagに絶えまないアクセスや、作業の性質、マシンに積んでいるプロセッサの数とタイプ、高速な生産者/消費者関係などについて見ていく。ただ一種類のbagではあらゆる要求を満足できないのは明らかだ。この論文ではbagに関して、アプリケーションの性質に応じて引き出しと戸棚という二つの抽象化を紹介している。これらの新しい抽象化を、スレッドセーフでスレッド中立なbagを担保しうるC++11のマルチスレッドまわりの機能を利用して実装する。いずれの実装についても人工のベンチマークと実際のアプリケーションで利用し十分な吟味を行った。

実践C++11：ODBへのC++11サポート追加で学んだこと

  • Practical C++11: What I Learned Adding C++11 Support to ODB
  • スピーカー： Boris Kolpackov

C++ORMにC++11サポートを加えていく過程で、新しい言語機能や他のコンパイラのサポート状況といった実践的な経験が得られた。また、想像できるかもしれないが、これは大変な仕事だった。このセッションでは、新しい言語機能について利用できる経験則について議論したい。

このセッションでは、完全転送とオーヴァーロードはとても相性が悪い(また、その対処方法)、値渡しと参照渡し(また、左辺値参照か右辺値参照か)の使いわけ、範囲forループの内側について話すつもりである。また、C++98とC++11をサポートするクロスプラットフォームライブラリで、実際に遭遇した実装面での問題についても取りあげたい。

応用階層的再利用: Bloomberg基盤ライブラリの利用

  • Applied Hierarchical Reuse: Capitalizing on Bloomberg’s Foundation Libraries
  • スピーカー： John Lakos

ライブラリの設計は大変な仕事である。特に、相互運用性のある組み換え可能なライブラリセットの設計ともなるといっそう困難である。複数のライブラリを機能面で分割すれば、それ固有の課題がでてくる。すなわち、ライブラリの機能はわかりやすく、冗長性は排除しなければならず、コンポーネントとライブラリにまたがるインターフェースと契約関係は、高性能なIDEがなくても容易に理解できるようにしなければならない、ということだ。さらに、ライブラリ間の依存性にはよく気をつけなければならない - ライブラリは首尾一貫して機能し、よく精査された語彙を定義、利用しながら、クライアントが必要とする機能分だけのコンパイル時間やリンク時間、実行ファイルサイズで済むものでなければならない。

複数の相互運用可能なライブラリセット作成にも、それぞれのライブラリ作成と同様に多くの課題がある。そのライブラリセットは理解しやすく、利用しやすく、高性能で信頼性がなければならない。さらに、ライブラリ全体が共通の構造を取り、表現を根拠なく変えず、一貫した用語を使っていなければならない。ライブラリ全体でこのような高度な一貫性や性能、信頼性を達成することで、個々のライブラリにおける部分的な信頼性は非常に高くなる。さらに、単一のライブラリを作成する際にも、このような手法を採用すれば、かなりの恩恵にあずかれるだろう。

小-中規模プロジェクト向けのソフトウェア方法論は多くあるが、これらをごく単純には大規模な開発にスケールすることはできない。このセッションでは、大規模開発における問題点や、実績のあるコンポーネントベースの方法論ではどうにもならない問題に対処すべく見いだし、Bloombergの実用的なアプリケーション開発を通じて洗練された関連技術について述べる。これらの方法論 - 三階層集約、非循環依存性、名詞句結合、高粒度機能分解、クラスカテオゴリ、限定的契約、コンポーネントレヴェルテスティングなど - の現実的応用については、最近リリースされたばかりのオープンソースディストリビューションであるBloomberg基盤ライブラリを利用して紹介する。

Boost.Dispatch - 汎用タグディスパッチ基盤ライブラリ

型制約を自由に組み合わせる種の関数特殊化を規定するのは、C++ではめんどうな仕事である。というのも、そのような制約はすぐにどんどん増えるし、どんどんややこしくなるからだ。この問題を解決するために、SFINAEやタグディスパッチなど様々なイディオムが利用されてきた。

このセッションではBoost.Dispatchを紹介する。これは、タグやその関連性を定義するプロトコルを備え、任意のタグの組み合わせと関数実装とをマップし、自由で結合可能な方法で前述の特殊化リストを拡張できる、タグディスパッチの利用や管理を容易にする基盤ライブラリである。Boost.Dispatchの新しい利点は、関数の特性や型特性のより古典的な用法に加えてディスパッチを導くための構造上の情報を分類できる機能だ。

このセッションではまずSFINAEや、C++でのオーヴァーロードとタグディスパッチの意味と、その限界についてざっと説明する。単純なライブラリ設計から、自明でない構造に依存する情報に基づいて、関数の最適な実装を選択するためのライブラリを利用する、実際の高効率コンピューティングコードにわたるサンプルとともに、Boost.Dispatchを紹介していく。さらに、ライブラリの実装についての詳細を見ていただき、未解決の課題について概説したい。

計算科学向けViennaライブラリについて

  • A Discussion of Selected Vienna-Libraries for Computational Science
  • スピーカー： Karl Rupp

CUDA、OpenCL、OpenMPが利用可能な線型代数ライブラリであるViennaCL、メッシュデータ構造ライブラリであるViennaGrid、データ保存を受けもつViennaData、シンボリック計算カーネルであるViennaMathといった直交するライブラリ群を紹介することで、計算科学のとっつきにくさに取り組む。結びに、有限要素法パッケージであるViennaFEM内で、これら直交するライブラリ群がどのように相互作用しているか考察する。このセッションの主眼は様々なプログラミング技法の適用について、またC++がいかに計算科学向けの言語になりうるかについてである。

C++のアラインメント: 利用法、制限、および拡張法

  • Alignment in C++: Use, Limitations, and Extension
  • スピーカー： Michael Spencer

このプレゼンテーションではC++におけるアラインメントを調査する。まず最初に、C++11でのアラインメントまわりの変更について概説し、効果的な利用法について述べる。次にその制限について述べる。その次に、それら問題点に対処するために、アラインメントを型システムに載せることで解決する方法を提案する。最後に型安全性と実行時効率の恩恵について述べる。

C++コミュニティの発展

JensとJonは両名ともC++コミュニティの発展に意欲があり、C++カンファレンスに出席した経験がある。彼らはコミュニティの発展にはローカルグループこそがC++コミュニティ発展の鍵であると感じている。

Jensは、ヨーロッパのC++Nowとも言えるMeeting C++の主催者として、またデュッセルドルフとベルリンのC++ユーザーグループを立ちあげた経験について紹介する。

JonはシリコンバレーのACCU支部での経験や、シリコンバレーコードキャンプでのC++プログラミング経歴、C++Nowでの活動について紹介する。

その後、パネルディスカッションスタイルで、質問やコメントを受けつけたり、聴講者の経験についてうかがう。

ローカルでグループを立ちあげるコツや、個人的人脈やソーシャルメディアを通じてスピーカーや聴講者を募る方法、他のグループと連携する方法についても述べる。

動的なC++

外部ソースから取り込むべき様々な型のデータには、データ型変換がつきものです。C++プログラマの皆さんは、リレーショナル・データベースやXMLデータベースからJSON形式やHTMLへのデータ変換をC++の型チェックという障壁を越えて、正確かつ効率的に、どのように変換されていますか？答えは型消去というテクニックを使用する事にあります。この講義では、最も一般的な C++型消去の手法について、列挙探査と比較を行います。

上記の問題と同様に与えられた、歴史的なライブラリ（ANSI Cの共用体、void*、マイクロソフト COMのVariant型、boost::variant、boost::any、boost::lexical_cast)と最近のライブラリ(boost::type_erasure、Facebook folly::dynamic)といった、開発トレンド(保留中の boost::any というC++標準案を含む)、それは、C++言語の静的な型システムという性質を回避する手法が必要であることを示唆しています。この問題に関する解決法は複数存在します。この講義では、boost::variant、boost::any、boost::type_erasure、folly::dynamic、Poco::Dynamic、これらに焦点を当てて掘り下げます。設計デザインと機能だけでなく、各ライブラリの長所と短所についても検討します。パフォーマンスベンチマークの比較も同様に検討されます。

型安全はC++の重要な要素です。型消去は、現代のソフトウェア開発のために必要なテクニックです。この講義では、これら重要な型消去のライブラリの比較検討を行います。

＊ Type Erasure を型消去と訳してます

DeBruijn Bind: シンプルさを維持するより強力なbind

  • DeBruijn Bind: A more powerful bind that retains its simplicity
  • スピーカー： David Sankel

Boost.LambdaやBoost.Phoenixのような、より強力なライブラリがあるなかでも、Boost.Bindはその非常に単純な構文と、学習のハードルが低いという点でその立ち位置を守っている。その構文はBoost.MPLのなかでコンパイル時variantとして利用されている。

しかし、テンプレート実引数とともに使うため、または、boost::protectを使いはじめるために、boost::bindのネストに手を染めると、この単純さはboost::bindのセマンティクスとその限界については不鮮明になってしまう。

このセッションでは、解析を行ない、Boost.Bindのセマンティクスとは何かについて数学的に正しい理解に到達することを目的とする。ひととおりセマンティクスについて学べば、Boost.Bindがカヴァーしている要求を満たし、再帰可能であり、学習のハードルが低い単純な構文を維持する、説得力のある代替案の設計についての見識が得られるだろう。

C++11とBoostを利用したマルチスレッディング

  • Multi-Threading With C++11 and Boost
  • スピーカー： Rob Stewart

このチュートリアルでは、マルチスレッドコードを記述するためのC++11とBoostの機能を利用した多くの例をもとに、より深くその効用についいて段階的に学んでいく。

例としてスレッドセーフキューについても取りあげ、独立したスケジュール上で並列タスクを実行するためにスレッドを利用したり、長時間実行中の並列タスクに割り込みを掛けてみる。これらの例をもとにスレッドやミューテックス、条件変数などの利用法を示す。C++11とBoostの機能的相違点についても議論するつもりである。

軽量コンセプト: 述語による制約テンプレート

  • Concepts Lite: Constraining Templates with Predicates
  • スピーカー： Andrew Sutton

このトークでは、C++14に提案されている新言語機能である「テンプレート制約(またの名を軽量コンセプト)」について話します。制約は、テンプレートにおいてテンプレート引数が使えるかどうかを判定するための述語です。

制約を使用して要件を直接示すことによって、テンプレートの宣言を改善できます。もちろん、制約に基いて関数オーバーロードすることもできます。制約は、型のエラーを使用時にすぐ捕捉できるため、コンパイルエラーのスタックを短いスクロールで確認できるようになることを意味します。

言語機能としては、テンプレート制約は最小限で複雑でないものに抑え、テンプレート使用の正確さではなく、テンプレート定義の正確さを強化します。これは段階的かつ簡単に、既存のコードベースに採用できることを意味します。

このトークは一般的なデータ構造、メンバ関数とコンストラクタ、オーバーロード、クラステンプレートの特殊化、制約の定義といった例を通して、制約をどのように使用するかを説明します。また、私が普段のプログラミングで制約を使用してきた経験についても説明します。これは制約のいいアイデアと、それほどよくないアイデアの両方を含みます。

GCC 4.8ベースの実験的なコンパイラは、みなさんがすでに使えるよう公開してあります。

ママ見て “C++を使ってデータベース更新からHTML5が生成されたよ”, 自動化して!

  • Look ma, “update DB to HTML5 using C++”, no hands!
  • スピーカー： Alex Fabijanic

ウェブを取り巻く環境は急速に変化しています。AJAXや非同期JSONの登場により、ユーザ・インタフェイスの応答性は、大幅に改善されてきました。この流れの基礎となるデータ・トランスポートのメカニズムは、まだ、リクエスト/レスポンスによるポーリング（プル）・モデルに基づいています。WebSocket規格は、ネットの先のストレージから標準となるHTML5インタフェイスへ、イベント・ドリブンなプッシュ・モデルというシームレスな接続の最後の障壁を取り除きました。流れとして、データ転送はイベント・ドリブン・モデルを使用し、リクエスト/レスポンス・モデルで行われていたネットワークおよびウェブサーバのオーバーヘッドを下げ、パフォーマンスの改善を標準規格に準拠して行う事ができます。講義の最初に、POCOフレームワーク・ネット・ライブラリを使用して、WebSocket HTML5ページを生成するHTTPサーバを構築します。次に、POCOデータ・ライブラリを使用して、SQLデータベースと連帯する機能をHTTPサーバに追加し、コールバック・フックを確立します。そのフックは、透過的にデータベースのデータ更新からウェブ・ページ変更を引き起こすためにパスを開きます。このソリューション・電子ブロックの構成要素である、データ型消去のための Poco::Dynamicモジュール、動的フォーマット出力のためのPoco::Data::RowFormatterクラス、を詳細に説明します。

この講義は、いくつかの鋭い問題に現実的解決案を提示します - 効率的かつ独立して転送されたデータ型からエンドユーザにシームレスウェブにネットワーク経由でストレージからデータを提供します。

C++(11)のためのORマッパー：ODB

ODBは、C++によるオブジェクト・リレーショナル・マッピング(ORM)システムのライブラリで、クロス・プラットフォームかつクロス・データベースなオープンソースです。

このライブラリを使用すると、テーブル・カラム・SQLや、リレーショナル・マッピングのコードを手作業で書く事なく、C++のオブジェクトをリレーショナル・データベースに格納できます。

Boostカンファレンス2011より数ヶ月前に、私はODBを導入しました。今回は我々が過去2年間に行った成果をお見せしたいと思います。講義の最初では、ODBの助けを借りて、リレーショナルデータベースにC++のオブジェクトを格納することが、いかに簡単できるかを話します。次に多様な興味深いトピック、C++11サポート、BoostとQtプロファイル、ポリモーフィズム、楽観的な同時実行制御、およびマルチデータベースサポートについて話します。私は、これからも、データベース・スキーマ革命！という野心的な困難に取り組むつもりです。

Fusionで世界の謎を解く

  • Solving World Problems with Fusion
  • スピーカー： Michael Caisse

コンパイル時MPLと実行時タプルの融合。Boost.Fusionはメタプログラミング世界のSTLである。FusionはBoostライブラリの内部的な機構を提供し、私たち自身のソースの一般的な要素となっている。

この90分のセッションでは、Boost.Fusionライブラリの現実世界でのユースケースを探求する。具体的には、ライブラリインタフェースのシンプル化、宣言的なユーザーエクスペリエンス、効率的で非侵入的なハンドリングの例を見ていく。

参加者は、いくつかの実用的な使用パターンの理解を得てさらなる先に進んで行くでしょう。ぜひSpirit、Xpressive、Geometry、Accumulators、odeint、Proto、Phoenix、MSMを自分のソースに取り入れる方法を学んでみてほしい。

モダンなC++向けのデータ分散サーヴィス(DDS: Data Distribution Service)の標準化

  • Standardizing the Data Distribution Service (DDS) API for Modern C++
  • スピーカー： Sumant Tambe

C++復権は多くの工業分野で広まっている。アプリケーション移植性の視点からC++を対象にした国際的なコンピュータシステム標準は、迅速にモダンなC++を導入してきている。国際標準化機構のObject Management Group(OMG)では、DDS-PSM-CxxとIDL2C++11標準が時代の先を行っている。DDS-PSM-Cxxは、高性能な分散リアルタイムシステム開発向けの主要なデータ分散サーヴィス(DDS)標準の関連標準である。正式には"ISO/IEC C++ 2003 Language Platform Specific Mapping (PSM) for DDS"として知られるDDS-PSM-Cxx標準は、2012/12に策定完了した。DDS-PSM-Cxxはモダンで、自然で、STLと親和性があり、表現力が高く、安全で、効率的なDDSプログラミング向けに可搬性のあるC++APIを提供している。DDS-PSM-CxxはC++03をターゲットにしており、C++11環境移行を可能にすべく特別な準備をしている。このセッションではDDS-PSM-Cxx標準の"なぜ" "どうして"について述べる。OMG標準化作業部会の投票委員と主要な貢献者が登壇する予定である。

このプレゼンテーションはDDS - リアルタイム分散システム向けのデータ中心の出版-購読型アーキテクチャの基礎を説明するところから始める。DDSと組み合わせたモダンなC++で記述した"Hello World!"アプリケーションとともに、DDS-PSM-Cxx標準の動機や問題点、高次構造について示す。また、規格に合致しているベンダー実装の当分の代替のサポートやベンダー固有拡張のための文脈的手掛かりといった、標準の興味深い点について深く掘りさげていく。この標準はBoostを直接的に利用していないものの、いくつかのBoostライブラリからアイディアを拝借している。このプレゼンテーションでは、DDSアプリケーション向けのクリーンで安全かつ効率的なAPIを提供するための、種々のC++03イディオム(例えば、RAII、型消去、型安全列挙、メソッドチェイン)の利用についても詳しく説明していく。さらに、聴者の興味を引くであろう、APIを構築する上で重要な点である例外安全の考慮についても述べる。特に、例外安全なAPIを設計する上で、ムーヴセマンティクスが如何に有用かご覧いただけるだろう。最後に、C++03規格に合致しているアプリケーションが、C++11環境でも合法となるように、標準に加えた特別なルールについて議論する。

メンバーアクセス演算子のオーヴァーロード

  • Overloading the Member Access Operator
  • スピーカー： Sebastian Redl

直接メンバーアクセス演算子(operator.)のオーヴァーロードは通常またはメタプログラミングでおもしろいユースケースがある。この演算子のオーヴァーロードの古典的な利用法は、アロー演算子のオーヴァーロードと同じく、別のオブジェクトを参照させたい場合に利用することである。

このセッションでは、メタプログラミングを利用してプログラマが別の名前を利用できるようにする別の方法を紹介する。Clangコンパイラを利用したこの機能の実験的実装を紹介し、この実装のユースケースや、この機能の有用性、問題点、これを実装するにあたって得られた知見について述べる。

CERNでの対話的で内省的なC++

CERNは、世界最大の素粒子物理学研究所である。そのような科学的ブレイクスルーを作るために、約15PB/yearを処理している。ROOTフレームワークのユニークな能力は物理学者がデータ解析するのをより効率的で、計算的で、賢いストレージを可能にする。ROOTの最新バージョンのコアはClingである。これは対話的なC++インタプリタで、C++11もサポートしている。Clingは、以前まで使用していたROOTの伝統的なメインユーザーインタフェースを置き換える。Clingは、Clang/LLVMインフラストラクチャ上に構築される。このインタプリタはそれだけでなく、ROOTのシリアライズ、デシリアライズ、C++のオブジェクト指向データの操作にも使用され、それでいて初心者がC++をより早く学ぶのを支援してくれる。

C++のような静的言語のインタプリタを構築するのは、決して簡単ではない。私はClingの要件を説明し、その後コンパイラフレームワーク上にインタプリタを実装することに挑戦する。C++をより対話的な言語に変えるために、C++標準のいくつかの概念を説明する。インタプリタを使用して、型のイントロスペクション機構を簡単に説明する。C++の文脈解析で、ランタイムの力を改善する方法を提案する。

Haskellの力でMPLを強化しよう

  • Boosting MPL with Haskell elements
  • スピーカー： Abel Sinkovics

HaskellとC++テンプレートメタプログラミングの類似性が指摘されている[1,2]一方で、Haskellのほとんどの要素がテンプレートに導入されていない。これらをいくらかでも導入すれば、メタプログラミングはより使いやすくなり、テンプレートメタプログラミングツールセットであるBoost.MPLの強化につながるだろう。

Haskellを含む関数プログラミング言語で利用されている式を、コードを読みやすくするために、そして構築しやすくするために利用してみよう。これはC++テンプレートメタプログラミングに対しても同じ目的で適用できるはずである。

関数型プログラムを記述するとき、とりわけ、Haskellのdo notationとMonadの組み合わせは、書かなければならない鋳型コードの量を削減できる強力なツールである。コンパイル時計算にこの要素を導入すれば、これを利用したテンプレートメタプログラムの可読性の向上に寄与するだろう。

多くのプログラミング言語について、リスト内包表記はリスト変換の理解に寄与する。リスト内包表記を実装するためにHaskellのList monadとdo notationを利用が利用されるように、テンプレートメタプログラミングでも同様にこれらを使って実装できる。

エラーハンドリングはEither monadを利用すれば単純化できる。構文糖を混ぜることで、monadや例外ハンドリングがC++テンプレートメタプログラムで実装されていることを意識せずに、テンプレートメタプログラムにおいてもこのような例外ハンドリングが理解でき、利用可能である。

これらのツールはBoost.MPL ライブラリを基礎として構築され、その拡張として利用されるので、既にBoost.MPLを利用しているメタプログラムに容易に展開可能である。

このセッションで紹介するツールはMetamonadライブラリの構成要素である。Metamonadライブラリについては以下のリンクを参照すること:

このセッションは高度なので、Boost.MPLに精通していることが望ましい。

参考文献:

Boost.AsioとBoost.Serialization: オブジェクト受け渡しのデザインパターン

C++でネットワークプログラミングするには、他のネットワーク終端へ受けわたしできる、再構築可能なバイトシーケンスとして、C++オブジェクトを表現する方法が必要である。PODのような単純なオブジェクトなら、シリアライズするのが一般的だろう。

多態オブジェクトのような、より複雑なC++構造については、シリアライズする方法はより困難になる。このセッションでは、Boostにある二つの強力なライブラリであるAsioとSerializationについて、巨大な配列を扱えるC++ネットワークコードを構築するという観点から、その有用性について議論していく。

このセッションではBoost.MPIとHPX(分散/並列プログラミング用のC++ランタイムシステム)を使って、Boost.AsioとBoost.Serializationを利用したオブジェクト変換を行う方法についても議論する。また、ほんの少しだが、別の解法についても議論するつもりだ。

このセッションは、ネットワークプログラミングに従事している、もしくは興味がある(けれどもBoost.AsioやBoost.Serializationについてよく知らない)方を対象にしている。

C++Now 2014の準備

来年の会議にむけた計画委員会を早期に発足させる。もしご提案や、ご支援いただける方はぜひご参加ください。

このセッションにはスライドはない。

静的型付け言語における、動的で再帰的なヘテロ型

今日のソフトウェアはいろいろな言語で記述されている。すなわち Python、C++、Perl、Java、Javascript、Lua、Unicon、C言語などが、複雑なシステムの別個のコンポーネントを構成する環境のなかに混在している。このような言語の急激な拡散により、動的型づけ言語のコンセプトが静的型づけ言語に流入していく。

動的言語によく見られる要素として、動的で、再帰的な、ヘテロな辞書構造が挙げられる。たとえば、Pythonのdict、Perlのhash、Javascriptのobject、Luaのtable、JSONにおけるIcon/Unicon tableはこの種の抽象化の実現であるし、より低水準なものとしては、XMLは言語に依存しない動的辞書構造と言えるだろう。C++やJavaのような静的型づけ言語は、スジがいい動的辞書構造の設計と実装に苦労してきた。さて、このセッションでは、C++言語の静的型に特有の機能を 採用 し、動的構築を行なうためのシンプルで新規性のある解法で、いかにC++で辞書構造を表現するかについて考察する。その機能とは型推論、ユーザー定義の型変換、型選択、オーヴァーロードである。

これらのこと組みあわせて、動的言語における動的辞書の操作性に近づけるべく、逆説的だがこれらの静的な機能から、C++からの操作が非常に容易な動的辞書構造を構築する。

注意：これらのテクニックには特別なリフレクション機能やライブラリを必要としない。

Projucer: C++とLLVM JIT エンジンを利用したライブコーディング

  • The Projucer: Live coding with C++ and the LLVM JIT engine
  • スピーカー： Julian Storer

それぞれのクラスを連続的にリコンパイルし実行するために、Projucer IDE がいかにしてClangとLLVM JITエンジンを利用したC++コードのリファクタリングとリアルタイム実行を成しとげたのか、その裏側からごらんいただこう。

JUCE GUI toolkitライブラリを利用しているこのProjucerは、C++プロジェクトの編集やアセンブルを行なうためのIDEである。Projucerは、Clangを利用してコンパイルを行ない、ユーザーコードベースのAST(Abstract Syntax Tree: 抽象構文木)を走査することで、適切なGUIクラスを決定し、スタンドアロンの実体としてインスタンス化する。このインスタンスはそのコードが編集された際、即座に更新される。これらのGUIクラスを動的に生成されるコードにラップすることで、ドラッグやリサイズといった一般的なGUI操作は、元のコードを動的にリファクタリングすることによって機能しその上で実行される。

実際の動作についてのムービーはこちら。より詳細については私のサイトを参照のこと。

C++通向きに、もっと細かいことや、諸問題、このシステムを効率的にするために使った狡猾なトリック、そしてClangやLLVMの特徴について掘り下げてみるつもりである。

EigenとBoost Protoライブラリを用いた有限要素マトリックス式の組み立て

  • Building finite-element matrix expressions with Boost Proto and the Eigen library
  • スピーカー： Bart Janssens

このチュートリアルでは、我々がドメイン特化言語を開発するにあたり障害となった二つの問題、すなわちBoost.Proto内での外部Expression Template Library(ここではEigen)の利用と、ユーザー定義関数の導入についていかに解決したかを示す。

どちらの話についても、我々の有限要素マトリックスのコードとは関係のない、一般的な計算機様のプログラムで紹介するつもりである。これはステップバイステップ方式のBoost.Protoのチュートリアルになるだろう。最後にCoolfluid 3 codeにあるアプリケーションを例にとって、Protoのようなライブラリが、実際のコードにどのような利点をもたらすかを示す。

侵入的動的解析を使用したリソースデッドロック防止システム

  • A system for resource deadlock prevention using intrusive dynamic analysis
  • スピーカー： Louis Dionne

ミューテックス等を使用して共有データへ同期にアクセスするという旧来の方法は、2つ以上のスレッドがお互いに再帰的にブロックをしてしまう、リソースのデッドロックを可能にしてしまう。

このようなバグは特定の状況下でしか発生しないため、多くの場合、その摘発は困難なものとなる。

このトークでは、intrusive dynamic analysis(侵入的動的解析?)を使用して潜在的なリソースデッドロックを事前に発見するシンプルなフレームワークを、私達がどのように実装したかを説明する。

また、そのフレームワークを既存のコードとどのように統合するかも説明する。

そして最終的には、このプロジェクトをC++のより汎用的なdynamic analysisフレームワークにする可能性をもつ、プロジェクトの進化について議論しよう。

マルチスレッドあるいはdynamic analysisについて興味のあるプログラマ向け。

Boostの未来

BoostとC++ Now!のリーダー達が将来どうなるかについて話し、質問に答える。

このセッションにスライドはない。

翻訳

Akira Takahashi, Usagi Ito, hotwatermorning, Miyuki OKI, zak