Skip to content

Latest commit

 

History

History
662 lines (408 loc) · 80.4 KB

2014.md

File metadata and controls

662 lines (408 loc) · 80.4 KB
Raw

C++Now! 2014

https://cppnow2014.sched.com

セッションリスト

セッション資料

キーノート： 公理的プログラミング： ユークリッド推論からC++テンプレート、その先へ

  • Keynote: Axiomatic Programming: From Euclidean Deductions to C++ Templates and Beyond
  • スピーカー： Gabriel Dos Reis

公理的プログラミング(Axiomatic Programming)は構造的ジェネリックプログラミングとして一般に定義されている。ユークリッド幾何学はそれとは違い、シンプルで建設的な論理システムに依存する。これは、STLや多くの成功しているジェネリックライブラリの基盤でもある。このトークではツールのサポートに焦点を当て、C++テンプレートによる開発に現在および未来で可能な自動推論や証明の方式について話す。

鏡の国のC++14

  • C++14: Through the Looking Glass
  • スピーカー： Michael Wong

ISO曰く、「さぁいろんなことを話しあうときがついにやってきたのだ。ムーヴキャプチャやリテラルだの、lambdaを上手に歌わせるには、あるいは型推論がどうしてアツいのか、はたまた数値にハネ(')が生えたらどうなるか。」

次期C++標準について聞いたことがありますか？
いやいや、C++11のことではありません。C++11が批准されてからそう時間が経っていませんが、来年にはC++11はC++14に刷新されることで しょう。今や、私達はC++11について十分な知見を得て、C++11に欠けている、細かな、しかし重要な機能を知るに至りました。すなわち、

  • ラムダ式にムーヴキャプチャがないのはなぜか？
  • 標準ユーザー定義リテラルがあってもいいんじゃ？
  • 多態ラムダがないはどうして？
  • ラムダ式の戻り型が推論できるのに、普通の関数でできないのはなぜ？
  • 数値リテラルに桁区切り文字が欲しいんだけど？

C++14はバグフィックスリリース以上のもので、C++11をさらに機能強化したものが含まれています。これによって、C++11で知られていたいくつかの厄介な問題が解決されるでしょう。しかし、より重要なことは、C++14で言語やライブラリ、重要なイディオムがどのように変わるかではないでしょうか？

Coroutines, Fibers, and Threads, Oh My

スピーカー： Nat Goodspeed

前世紀では、オペレーティングシステムが一つのマシンで複数のプロセスを並行に走らせられるようになったのが大きなニュースだった。だがそれは必要十分ではなかった。この業界で数十年前から知られている問題を、C++11標準も公式に認めている：生産プロセスは、I/Oや他の時間のかかる作業を通常、ブロックできない。標準は2番目のレベルの並行性を与える：プロセス内で複数スレッドを使用する、ライブラリの機能を使用して同期とデータの受け渡しを管理する。

新たなBoost.Fiberライブラリは、同様に細かい粒度の並行性を我々に与える：各スレッドで複数ファイバーを使用する、ライブラリの機能を使用して同期とデータの受け渡しを管理する。どのようなときに、スレッドの代わりにその機能を選択するだろうか？コルーチンとはどんなもので、どのようにこれら全体に適合するのか。

C++標準に考えられているいくつかの並行機能についても触れる。

規範的なクラス

これまでは簡単だった。どの大学の学生も、週末にC++を学ぶ人も、クラスを定義する際にはコピーしたときと代入したときの振る舞いだけを自信を持って書くことができた。そこにはチェックリストがあった。チェックリストを埋め、ドメイン特化の振る舞いを追加し、回帰テストを行い、それで終わりだった。

C++11になり、deleteキーワードの新たな使い道、演算子のexplicit指定、右辺値参照、完全転送など、魅力的な機能がいろいろ入った。いまあなたは、「シンプルな」クラスをどのように書くだろうか？swapを含めた方がいいだろうか？ムーブ可能であるとは何だっただろうか、それに期待するセマンティクスとは何だろうか？noexcept指定子を使用するのはどんなときか？

この90分のセッションでは、C++11での定型コードを探求する。このセッションでは、クラスや構造体を定義する際に適用する、右辺値参照、ムーブセマンティクス、完全転送、explicit、noexcept、初期化子リスト、その他多くのセマンティクスに触れる。

ジェネリック空間のジェネリックプログラミング： C++11を使用したコンパイル時幾何学的代数

  • Generic Programming of Generic Spaces: Compile-Time Geometric Algebra with C++11
  • スピーカー： Pablo Colapinto

このグラフィクスハンズオンでは、組み合わせ生成計算量のためのテンプレートメタプログラミングの強力さを事例として、Versorと呼ばれるC++11の軽量なライブラリを使用してコンパイル時にN次元ジオメトリと空間を合成することを探求する。 ジオメトリを構築するテンプレート(アフィン、投影、等角、または実験)は、可変引数テンプレートと定数式を器用に使用することによって表現した。具体的には、コンパイル時に独自の最適化戦略として、リスト操作、並べ替え、幾何学的代数(geometric algebra)の評価をコンパイル時に行う新技術を提案する。

この議論では、これら技術の開発を補助するために使用したC++11の基本的な機能と幾何学的代数の論理を解説する。対話(interactive)と視覚(visual)の両方で、ジェネリックプログラミング技法とジェネリック空間コンピューティング(generic spatial computing)の融合が、次元的流動性の式(a dimensional fluidity of expression)を可能にすることを調査する。2次元を介して4次元あるいはその上で、群論、ベクトル、行列、テンソル、リー代数(lie algebra)の効率的な実装をC++11のイディオムに結びつけることができる。これら関数は、物質科学(material science)から量子計算(quantum computation)まで、幅広い分野の多様なアプリケーション集合に適用できる。このアプローチで作成したビデオは http://vimeo.com/wolftype で見ることができる。Versorの詳細については、 http://versor.mat.ucsb.edu/ を参照。

ConceptClang：完全なC++コンセプトによる理論的な前進

  • ConceptClang: Theoretical Advances with Full C++ Concepts
  • スピーカー： Larisse Voufo

コンセプトはジェネリックプログラミングに不可欠な機能であり、C++の言語拡張として10年以上前から期待されてきた。これまでにいくつかの異なる設計のコンセプトが提案されてきたが、標準化への合意がとれなかった。2010年に私たちは、コンセプト機能の理解を補助することを主な目的として、コンセプトの異なる設計をConceptClangを実装した。それによって浮上した問題のひとつに、名前のバインディング、すなわち使用する名前と参照する宣言を一致させるプロセスがあった。これは、あらゆるコンセプトの設計をフルサポートするには、「弱い隠蔽(weak hiding)」と呼ばれる名前バインディングの新たなスコープルールが有用だということを意味する。弱い隠蔽は、合法に見えるプログラムを維持するために、制約のないテンプレートを制約付きテンプレートに遷移させることを可能にする。弱い隠蔽を実装するために、私たちは2ステージの名前バインディング(Bindx2)を導入した。これは既存の名前バインディングを弱い隠蔽でいかに拡張するかを定義する。Bindx2は、単純な関数呼び出しを、関連メンバ(associated members, 特殊メンバを含む)、演算子、型の要件といった名前の使用へと一般化する。驚くべき結果として、オープン／拡張可能なクラス／構造体は、完全なC++コンセプトのためにこれをコストなしに提供できた。

このトークは主に、ConceptClangを使用する練習や、ハイライティング、Bindx2や「構造オープニング(structure opening)」アーキタイプなどの実装構造の動機を与える主要コンポーネントに焦点を当てる。参加者はコンセプトをいかに実装するかというだけでなく、C++コンセプトの設計を学ぶことを期待できるが、それだけでなく、コンセプトの必要性が高まる他言語にも影響する。

Boost.TestとTurtle Mockによるテスト駆動開発

  • Test-Driven Development With Boost.Test and Turtle Mock
  • スピーカー： Richard Thomson

テスト駆動開発に含まれる3つの簡単なルールは、以下のようになっている：

  • 失敗するユニットテストのパスを作らない限り、プロダクトコードを書くことは許可しない。
  • 失敗している間は、それ以上のユニットテストを書くことは許可しない。コンパイルの失敗も失敗である。
  • 一つでもユニットテストが失敗してる間は、プロダクトコードを書くことは許可しない。一言で言えば、テスト駆動開発では、ユニットテストの失敗への応答としてプロダクトコードを書いていく。 このチュートリアルでは、単体テストフレームワークであるBoost.Testを使用して、C++でテスト駆動開発のアイディアを適用する方法を示す。Boost.Testの主要な機能は、アサーションからテストケースの設計、その管理までをカバーする。我々は、Boost.TestのためのモックオブジェクトであるTurtle Mockを通じて、状態ベーステストと振る舞いベーステストの違いまでをカバーする。

はじめに、テスト駆動開発のメカニクスを示すために、いくつかの演習をやっていく。その次に、機能を実装していくにあたって設計活動としてテスト駆動開発を適用していく考え方を学んでいく。このチュートリアルでは、小さく、凝集度が高く、関心の分離をしているクラスを設計するために、テスト駆動開発が強力な設計ツールになることを示す。

整数演算から未定義動作を排除する、bounded::integerライブラリ

  • Removing undefined behavior from integer operations: the bounded::integer library
  • スピーカー： David Stone

Cから派生した言語では、整数の算術演算が悪名高く危険です。符号付き整数では、オーバーフローすると未定義動作になってしまい、符号なしではエラーも起こらず静かに値が一周します。符号ありと符号なしの整数を比較すると、暗黙に符号なしと見なされるため、符号ありの-1は符号ありの12よりも大きくなります。intに保証されたサイズは、人々が期待し、必要とするよりも小さいです。この状況を改善する多くの試みは、すべての整数演算に、実行時にオーバーヘッドを追加するというものでした。

このトークでは、bounded::integerライブラリを紹介する( https://bitbucket.org/davidstone/bounded_integer )。

C++14で書かれたこのライブラリは、以下を目標とする：

  • コンパイル時チェックが可能な場合には、決して実行時チェックを行わない。
  • 確実によくない変換は許可しない。
  • よくない可能性のある変換については、明示的な変換のみを許可する。
  • より大きい整数型への暗黙変換を許可する。
  • 空間的および時間的なオーバーヘッドを持たず、インライン化のようなコンパイラの基本的な最適化を仮定し、bounded::integerを非常に大きなデータセットやリアルタイム要件なシステムで使用できるようにする。

bounded::integerは、整数型に対して静的な境界要件による保証を提供します。典型的な宣言としては、 bounded::integer<1, 10> x(5); のように書くと、xは1から10の範囲を生成します。算術式は、算術結果を自動的に範囲内に範囲内に維持し、境界を調整します。つまり、 x + x と書くと、結果の型は bounded::integer<2, 20> となります。autoとテンプレートの型推論のおかげで、ユーザーは(コンパイル時に)保証されるすべての中間結果が正しいことを、型のみで規定できます。さらに、コンパイラはすべての整数の正確な境界を知っているので、このライブラリは「intを使用する場合は、どこでも危険を避けること」という戦略よりも、空間的／時間的最適化が高速になります。

このトークは、このライブラリを使用する際のイディオムである、boost::constrained_value、Adaの整数型、無限範囲の整数モデル、それと制限と設計に関するトレードオフといった従来の研究も含むつもりです。

Boostのピアレビューに向けてのC++11ライブラリAFIOの準備

  • Preparing the C++11 Library AFIO for Boost Peer Review
  • スピーカー： Paul Kirth

Boost C++ Librariesは、その卓越さのために当然ながらよい評価がされており、それは彼らに貢献する抗い難い魅力です。

このトークでは、AFIOの経験を元に、既存のライブラリをBoostに移植するプロセスを、実例を通して解説します。このライブラリは、Boostのピアレビューに提出するために、Google Summer of Code 2013の期間中にC++11のみで書きました。なぜなら、示すコード例は開発者が直面する問題を強調すべきで、かつ問題に対するひとつのソリューションセットを提供すべきだからです。このトークは、Boostのビルドシステムによるコンパイラの内部エラーへの対処、プロセスの明確化、その他私が遭遇した困難な問題への解決策を示します。

値セマンティクスと範囲アルゴリズム - 合成と効率

  • Value Semantics and Range Algorithms - Composability and Efficiency
  • スピーカー： Chandler Carruth

特定の条件を満たすシーケンス内の先頭N要素を計算するコードを、1行で書きたい。そして、適切な場所(in-place)でそれができるかどうかに関わらず、同じ行でコードを書きたい：

x = std::slice(std::sort(std::filter(y, predicate)), 0, 10);

このトークでは、範囲アルゴリズムの設計に値のセマンティクスを与え、その合成を通じて設計上重要な表現力を提供する方法を紹介する。最後に、この設計の効率的な問題と、それを解決する多くの合理的な詳細を提供する。

キーノート：C++に気をつけろ

C++11(やC++14)によって、C++は別な言語になっている。アプリケーションプログラマは、宣言、初期化、イテレート、ムーブといったことが、以前よりもはるかに簡単にできるようになった。しかしながら、そこには理想的な「基礎ライブラリ開発者」だけが支払わなければならないコストが存在する。それは本当だろうか？平均的なアプリケーションプログラマは、C++11で効果的なプログラムを書くためのトリッキーな詳細についてどのくらい知る必要があるだろうか？物事の変化にともなって、我々の基本的なプログラミングパターンや方向性はどのように／どれくらい変化する必要があるだろうか。たとえば、C++11で、我々はテンプレートパラメータをどのように宣言し、explicitをいつ使うべきだろうか？

しかし、C++標準化委員会のライブラリワーキンググループは、これらの質問に明確な答えを持っていない。私のこのプレゼンテーションでは、平均的なアプリケーションプログラマのために、C++11標準ライブラリにおけるいくつかの問題点(detects)についての議論に基いて、洞察の組み合わせによって問題を解決する方法を紹介する。

実用的なType Erasure： boost::anyベースの構成フレームワーク

  • Practical Type Erasure: A boost::any Based Configuration Framework
  • スピーカー： Cheinan Marks

構成(コンフィグレーション)フレームワークは、古典的なINIファイルからBoost.PropertyTree、その他とても多くのものが長い間存在してきた。しかしC++による実装での一つの問題として、健全なインタフェースを保ちながら異なる型を保持したり返したりするには、どうすればいいかというものがある。

このトークで紹介する構成フレームワークは、文字列キーに基いて、コピー可能なあらゆるC++オブジェクトを返すことを可能にするフロントエンドの機能を持っている。バックエンドは、フロントエンドが意識することなくデータをメモリ、ファイル、データベース、その他任意のストレージに保持する仕組みを持っている。グルーレイヤー(glue layer : レイヤー間を繋ぐレイヤー)はフロントエンドとバックエンドを繋ぎ、渡されるデータの性質を気にしなくていいようにする。このマジックは、boost::anyとオブジェクトの組み合わせで、C++03の範囲で全て完結できます。このプレゼンテーションでは、このフレームワークの目標、設計、使用方法、boost::anyとtype erasureを使用することによる実用例を紹介する。時間があれば、簡単なバックエンドのストレージオブジェクトを開発する。

このフレームワークのオリジナルは、アメリカ政府のプロジェクトで開発され、アメリカ納税者の好意によってパブリックドメインとなっている。

Mach7： C++のためのパターンマッチングライブラリの設計と進化

  • Mach7: The Design and Evolution of a Pattern Matching Library for C++
  • スピーカー： Yuriy Solodkyy

パターンマッチングは、ソースコードを大幅にシンプルにする抽象メカニズムです。とくに、型の検査を行うビジターパターンを、より使いやすく、より高速にする代替手段となります。C++で実装されたMach7という、関数型スタイルのパターンマッチングのライブラリを紹介します。その解決策は非侵入的で、かつ新たなパターンマッチングの導入とクラスの拡張性、両方に対してオープンになっています。このプレゼンテーションは、いくつかの設計選択、実装詳細、初期ユーザーからのフィードバック、およびその他の要因を主に話します。このプレゼンテーションは、より多くの開発者にパターンマッチングに興味を持ってもらうこと、そしてそれがC++のようなオブジェクト指向言語にとりいれることができることを知ってもらうことを、目的とします。

C++11/14入門 パート1

  • A Tutorial Introduction to C++11/14 Part I
  • スピーカー： Leor Zolman

これは、C++11とC++14の機能を紹介する2つのプレゼンテーションのひとつめです。言語の小さな側面(aspect)のほとんどをカバーしています：

  • C++のタイムライン
  • C++11/14の目標
  • よりシンプルなコア言語の新機能
  • auto, decltype, 末尾の戻り値型
  • 非メンバ関数版のbegin/end
  • nullptr
  • 範囲for文
  • テンプレートに特化した>>
  • static_assert
  • extern template
  • noexcept
  • 可変引数テンプレート
  • constexpr関数とデータ
  • テンプレートによる別名付け
  • 新たな文字リテラル型
  • 生文字列リテラル
  • リテラル文字列とconst

その他、スコープ付きのenum、long long、alignas/alignof、属性、インライン名前空間、汎用union／POD、ガベージコレクションABI、ユーザー定義リテラルも紹介します。

C++11/14入門 パート2

  • A Tutorial Introduction to C++11/14 Part II
  • スピーカー： Leor Zolman

これは、C++11とC++14の機能を紹介する2つのプレゼンテーションのふたつめです。言語に追加された、大きめな機能をカバーしています：

  • クラス設計のための機能：生成される関数へのdefault／delete指定、移譲／継承コンストラクタ、柔軟性のある新たなクラス内初期化、明示的な型変換演算子、
  • 初期化： initializer list、一様初期化, 精度を損なうことの防止
  • ラムダ式
  • 右辺値参照：左辺値と右辺値 (その現代的な見方)、ムーブセマンティクス、普遍的な参照(universal references)、完全転送(perfect forwarding)

宇宙プラズマモデル開発でのC++11

  • C++11 in Space Plasma Model Development
  • スピーカー： Ilja Honkonen

最新のC++標準規格の利点として、超並列計算(宇宙プラズマ)モデルの開発に関する議論ができるようになったというのがある。とくに可変引数テンプレートは、直列でも並列でもどちらに対しても、パフォーマンスを損なうことなく、読みやすく、非常に拡張性の高い計算モデルの開発を可能にする。このプレゼンテーションでは、可変引数テンプレートの基礎を理解しておくことは必要だが、宇宙プラズマの知識は必要ない。

C++11ライブラリ設計

君がもしいま再利用可能なコードを書いていて、C++11の新機能をフル活用できないなら、ちょっと立ち止まってみてほしい！そのようなことをするためのルールは、下から(パラメータの渡し方とか)上まで(ライブラリのバージョニングとか)変わっている。C++11によって書かれたコードは、これまで以上に簡単に、より強力に、より安全に使えて、モジュール性が高く組み合わせもしやすくなり、ボイラープレートも少なくなる。つまり、妥協のないライブラリ設計ができるということだ。

このトークでは、いくつかの関数、クラス、「モジュール」を、効率的に、再利用性が高く、組み合わせがしやすく、バージョニングもできるよう設計する、C++11をフル活用したベストプラクティスについて説明する。これは全体的に、作者が今日の現代的なコンパイラで数年間、再利用可能なコードについて学んだことだ。

Octopus: CFDシミュレーションのためのポリシー駆動フレームワーク

Octopusは、HPX C++ランタイムシステム上に実装した、科学アプリケーション向けの解適合格子(Adaptive Mesh Refinement、AMR法)ライブラリである。Octopusは、ドメイン科学者が、AMR法として知られている技術を利用し、空間分解能の異なるスケールを持つ直交格子(Cartesian Mesh)の階層に対して計算流体力学(CFD : computational fluid dynamics)の問題を解くことを可能にする。ルイジアナ州立大学の天体物理学者は、連星合体(binary star mergers)のような重要な現象のシミュレートをするために、Octopusを使用している。

Octopusはポリシー駆動のフレームワークである。ドメイン科学者はポリシーを選択し、カスタマイゼーションポイントとして知られているインタフェースを、コンパイル時または実行時に決定する。これらのポリシーは、アプリケーション機能を実装するために基礎フレームワークで使用される。Octopusの多くの側面は、時間の離散化(time discretization)、補完(interpolation)や空間分解(spatial decomposition)を、ポリシーによって完全にコントロールできる。

このトークでは、効率的で、拡張性が高く、アクセスしやすいライブラリを、ポリシーを使用していかに構築するのかについて説明する。我々は、この強力なジェネリックプログラミング手法が、複雑なネットワークや同期コードを抽象化によって科学者から引き離せることを示す。

このトークの対象者は、科学計算、ライブラリ設計やジェネリックプログラミングといった分野に関心のある開発者である。参加者は、背景となる数学や天体物理学といった専門知識を持っている必要はない。

よりよいコードへの道しるべ：完全な型を実装する

  • Goals for Better Code: Implement Complete Types
  • スピーカー： Sean Parent

GoingNative 2013の「C++ Seasoning」という発表では、よりよいコードのために3つの道しるべを説明した。その発表では、C++における基本的な要素である型、参照と、それらの基礎的な動作について話した。今回は、一般的なすべての型について、その型を定義すること（と、その物理的な本質）によって導かれる結果、そしてなぜ完全な型を実装することが賢いゴールなのかを見ていく。

マルチプラットフォームでのC++

このセッションは、クロスプラットフォームなソフトウェアを開発するに際によくある疑問を解決するためにある。「各環境によって提供される様々なツールチェインを使ってWindowsやLinuxでビルドするにはどうすればよいか？」「LinuxとFreeBSDのような違いにはどう対処すべきか？」「各環境を横断するツールはどのように使うべきか？」「急激に増えるメンテナンスコストをいかに抑えるか？」 さらにこのセッションでは、マルチプラットフォーム開発における隠れた恩恵なども紹介する。

Boost Library Incubator

スピーカー： Robert Ramey

Boostはこれまでとんでもない成功を収めてきたが、同時に自身がその成功の餌食となってきている。泥沼なのである：

  • 各ライブラリのレビューにはずいぶん時間がかかる
  • レビューマネージャを探すのが大変
  • 満足にレビューされていない
  • ライブラリの中にはメンテナがいないために放っておかれているものがある
  • ライブラリのドキュメントは十分とはいいがたい
  • ライブラリサイズはどんどん大きくなり、そして管理とデプロイがどんどん大変になっている
  • いくつかのライブラリは時代遅れだが、それを廃止する方法もないしかし、今まで以上に、C++はさらなるよりよいライブラリを必要としている!!!

私は、上記のような問題に対する自分のアイディア考え、ウェブサイトに落とし込んだ。それがBoost Library Incubatorだ (http://rrsd.com/blincubator.com/)。私は、このウェブサイトを通して上記のような問題を提言していくつもりである。これが、これからのBoostのさらなる発展と革命に役立てばと思っている。ここにいるたくさんの熱意ある参加者達に期待しているよ!

Boost.Asioベースのネットワーク・サーバ最適化

  • The Optimization of a Boost.Asio-Based Networking Server
  • スピーカー： Nikita Chumakov

Yandexはロシア最大のインターネット企業の一つです．Yandexは，ウェブ検索や，e-mail, 地図，写真，ホスティングなどの双方向なネットワークサービスを提供しています．私達のチームでは，600万人のアクティブユーザが発する一日あたり5000万以上のメッセージを送信，処理，受診するためのe-mailバックエンドシステムを開発しています．

本講演では，これらのタスクに対して，Boost-basedなソリューションを検討し，そのパフォーマンスに対する効果を議論します．まず初めに，シンプルなAsio+Spiritベースの実装についてその問題点と限界について議論し，その後，ワークアラウンドと最適化手法を提案します．特に，私達はどのようにリアクターパターンがパフォーマンスに影響を与えるか，どのようにコルーチンと私達が特別に改造したスマートstreambufsがメモリ/CPUリソースを削減するかについて示します．

(最後に，我々は，本講演に参加こそされていませんが，本発表で用いているコードの作成に尽力して頂いたAlexander Drachevskiyの努力に感謝を表明します．)

C++の未定義動作； それは何か、そしてなぜ気にしなければいけないか

  • Undefined Behavior in C++; what is it, and why should I care
  • スピーカー： Marshall Clow

CやC++の未定義動作(UB : Undefined Behavior)は、先人たちによって次々と明らかにされてきた。これらはいくつかの大学では研究の題材としても注目されているが、コード生成器では最適化の際にごく普通にUBの情報を利用している。

このセッションでは、まず初めにUBの例について示す。次に、コード生成時にオプティマイザはどのようにUBを処理しているかを示す。さらに、あなたのコードにUBが入り込まないようにするための戦略について述べる（これはBoostを題材にする）。そして最後に、既存コードからUBを発見するための最新の（＋将来の）ツールを紹介する。

MPL11: C++11の新たなメタプログラミングライブラリ

  • MPL11: A New Metaprogramming Library for C++11
  • スピーカー： Louis Dionne

このトークには、2つの異なる、だが関連のある目標があります。はじめに、C++03からのピンポイントな改善として、C++11でのテンプレートメタプログラミングのベンチマークと事例研究を示します。これは、Boost.MPLの将来を客観的に議論できるようにするための基礎を提供します。ふたつめは、Boostに提案するBoost.MPLの後継となるC++11テンプレートメタプログラミングライブラリ( https://github.com/ldionne/mpl11 )の、一般的な目的を示します。ライブラリの中核となるコンセプトを導入し、いくつかの設計選択を説明し、現在のBoost.MPLと客観的な比較を行います。

このトークは、テンプレートメタプログラミングと関数型プログラミングをよく知っている人向けです。TMPを多用し、FPに興味を持っている人は、最も恩恵を受けるでしょう。

libcppa: C++での型安全なメッセージングシステム

アクターモデル(actor model)というメッセージ指向のプログラミングパラダイムでは、並行および分散のアプリケーションを標準C++の機能を使うよりも、エラーを少なくし、簡潔に記述でき、理解しやすく、デバッグしやすくします。このトークでは、C++で複雑な分散アプリケーションを構築するために、libcppaによって提供されるコンセプトとサポートを調査します。

前半は、Dominik CharoussetがC++Now! 2013以前から開発している、C++による新たなアクタープログラミングを導入する。具体的には、分散をアプリケーションで強い型付けのメッセージングを可能にする、アクターの型安全インタフェースという新機能を紹介する。

後半は、Matthias Vallentinが、libcppaを使用して分散データベースを構築する、"巨大な"スケーラビリティについての事例研究をカバーします。このシステムは、アクターのみならずクラスターベースのデプロイでのネットワーク透明性機能を使用するが、データ取得やクエリ処理などといった、クリティカルパスへのきめ細やかな並列処理によってタスクをスピードアップする。また、プロファイラの結果分析を通じて並列パイプライン処理でのボトルネックコンポーネントを並列化する方法を紹介します。さらに、libcppaのアクターモデルが分散索引システム(distributed indexing system)の設計にどのように役立つかを示します。

このトークのVallentinの部分は、録画されません。

C++でのUnicode

一部のプログラミング言語では、テキスト処理は簡単です。残念ながら、C++はその「一部」には含まれない言語です。C++の状況は改善されはじめてはいますが、Unicodeの組み込みサポートが欠如しています。

このセッションは、テキストエンコーディングの概要、Unicodeの入門と、さまざまなUnicodeのエンコーディングから始めます。C++98の悲惨なUnicodeサポートを確認し、C++11で行われた改善と、標準化委員会に最近提案されているその他の改善を見てみましょう。最後に、C++で広く使われているUnicodeを操作しやすくするよう設計されたオープンソースライブラリ、International Components for Unicode (ICU)について説明します。

Clangベースのインタラクティブなメタプログラミングシェル

  • Interactive Metaprogramming Shell Based on Clang
  • スピーカー： Ábel Sinkovics

メタプログラミングの開発はしんどい。Templight ( http://plc.inf.elte.hu/templight/ )はテンプレートメタプログラムの開発とデバッグをサポートしているが、コードの小さな変更のたびに再コンパイルが必要だし、結果に関する有用な情報を得るためにトリックを必要とする。

多くの言語(Python, Haskell, Erlangなど)は、コードを試すとすぐに結果を表示する、インタラクティブなシェルを提供している。たとえばPythonのシェルで、簡単なリストへの要素追加は、以下のように結果表示される：

> l = [2, 3, 4]
> l.insert(0, 1)
> l
[1, 2, 3, 4]

このシェルはすぐに結果を表示できる。開発者は、自分のコードをコンパイルし、式の結果を確認するデバッガを起動する必要はない。

このトークでは、テンプレートメタプログラミングのためのインタラクティブなシェルである、Metashellを紹介する。これはPythonのシェルのように使いやすい、テンプレート メタプログラミングのためのテストと開発の環境を提供する。たとえば以下のように操作できる：

> #include <boost/mpl/vector.hpp>
> #include <boost/mpl/push_front.hpp>
> #include <metashell/formatter.hpp>
> using namespace boost::mpl;

> push_front<vector<int, char>, double>::type
boost_::mpl::vector<double, int, char>

このシェルは結果として、テンプレートメタプログラムを表示する。

MetashellはlibClangライブラリをベースとしている。

C++ AMPを用いたアクセラレータプログラミング

今日，ヘテロジニアスプログラミングはC++が用いられる多くの領域で利用されています．データセンタでは大量のデータを処理するためにGPGPUを用い，スーパコンピューティングの分野では計算能力の大部分を提供するためにアクセラレータの利用が進み，モバイルデバイスでは，"計算能力(capability)"の高いCPU群と"計算容量(capacity)"の高いGPUを組み合わせることで，高効率な計算能力を提供しています．

一般的には，アクセラレータはプログラムの一部の部分を実行することに適しています．アクセラレータは，プログラム全体の実行方針の決定やメインメモリへのアクセス，周辺ハードウェアへのアクセスのためにCPUに依存しています．この，CPUとアクセラレータ，その他システムコンポーネント間の頻繁なインタラクションは，ヘテロジニアスシステムを複雑にしています．

さらに，アクセラレータはオフチップに実装されていたり，自身のプライベートメモリをもっていたり，大きな通信レイテンシを持っていたりします．ヘテロジニアスシステムは複数のベンダ固有のプロセッサインタコネクトで通信する複数のCPUを持っていることもあります．システムは，ストレージやネットワークを多用するアプリケーションによってさらに複雑になることがあります．

多くのC++プログラマにとって，ヘテロジニアスプログラミングはもはや贅沢品ではなく，必要なものです．C++14は，ヘテロジニアスプログラミングに関する仕組みを提供していません．C++プログラマがアクセラレータの能力を利用するためには，ソフトウェアライブラリに頼る必要があります．アクセラレータを利用するための高品質なフレームワークは多くありますが，それらは特定のアクセラレータのみで利用可能であるか，純粋な同期オフローディングモデルを重要視したものです．

マイクロソフトによって公開されたC++ AMPの仕様では，モダンなC++からアクセラレータを利用するためのハードウェアに依存しないインタフェースを提供しています．C++ AMPは，言語拡張と，STLライクなライブラリコンポーネントで構成され，同期，非同期両方のオフローディングモデルを提供します．C++ AMPによって，ユーザはヘテロジニアスなハードウェアについての詳細な知識なしに，アクセラレータを活用したアプリケーションを記述することが出きます．

Visual Studioによる成熟したC++ AMP実装に加え，C++ AMPの実装は複数のプラットフォーム上に存在します．いくつか例を挙げると，インテルのShevlin Parkと呼ばれるものや，HSA Foundationが開発しているClang-based C++ AMP実装などが挙げられます．

このチュートリアルでは，C++ AMPの概要について，ソフトウェア中心の視点から，以下のトピックスについて紹介します．

  • アクセラレータに対するデータの準備
  • アークセラレータとの間のデータ転送
  • アクセラレータへのコードのオフロード（例. restring(amp), parallels_for_each)
  • アクセラレータの並列性のコントロール(例. tilling, barrires)

本講演では，書き込み待ちなし(write wait-free offloading)のコードオフローディングを行うためにC++ AMPが提供する非同期インタフェースについて，特に強調します．

対象とする聴衆は，アクセラレータを用いている/用いる予定のあるC++デベロッパです．本講演では，特定のアクセラレータや特定のC++ AMP実装に限った話が含まれます．本プレゼンテーションは，全てのプラットフォーム開発者に関係があり，windowsに限ったものではありません．

CppComponents: C++11のモダン,ポータブルなコンポーネントシステム

優れたコンポーネントシステムを持っていないことは，C++の大きな問題点の一つである．他の言語は、プレビルドされたライブラリを簡単にあなたのプロジェクトに組み入れる能力を持っている。一方，C++では、異なるコンパイラ、同じコンパイラの異なるバージョン、デバッグ/リリースビルドの違い、どの場合においてもABI互換性がないため、頻繁にコードのリビルドを行うことになる．良いコンポーネントシステムは、パッケージングや、ライブラリの利用を簡単にする．本講演では、あなたにCppComponetsを紹介する。CppComponetsは、あなたに別のプロジェクトでコンパイルされたバイナリや、スタンダードライブラリなどを簡単に利用する手段を与える。あなたはstring,vector,tuple,chronoなど標準ライブラリを関数パラメータや返り値，例外などに利用し続けたままCppComponentsを使用することが出来る．加えて，CppComponetはクロスABI互換関数，futures, promises, executors, 及びchannelsを提供する．これら全てはヘッダオンリライブラリであり，C++11標準ライブラリのみに依存する．

本講演ではまず，CppComponetsを支える技術について紹介し，CppComponetsを使い，複数のコンパイラから利用可能なバイナリコンポーネントを簡単に作成する例を提供し，そのコンポーネントがマルチスレッドプログラムやネットワークプログラムをシンプルにする例をお見せする．その後，簡単な依存性注入や，動的な名前ベース呼び出しなどのいくつかの高度なテクニックを見ていく． 本講演のまとめとして，CppComponetsがどのようにC++PyPIや，C++を簡単に多くのドメインで利用可能にするためのC++ components renaissanceを可能とするかなどのCppComponetsの将来的な方向性についてまとめる．

本講演の対象者は，中級，上級のC++プログラマであるが，初級のC++プログラマにとっても，有用な情報が含まれる．

UI、美学、C++

そそられる感覚
作用と応答、原因と結果
これらのシンボルは何だろう？

このセッションはたぶんUIについてであり、もしかしたら美学についてであるが、もちろんC++についてである。願わくは新人プログラマにも熟練プログラマにもかかわる話になればよいのだが。少々哲学的かもしれないが、日々のコーディングに役立つかもしれない。

ロックフリープログラミングについてではもちろんないので、どうぞ気分転換にでも。:-)

最新C++を使ったXML API設計

C++向けのXMLパース/シリアライズライブラリが氾濫しているが、もともと他の言語向けに開発され、イディオムを最低限考証した程度のC++対応になっているものがほとんどであるようだ。万人が満足しうるXML APIを設計するのは極めて難しい。事実、Boostコミュニティで度々試みられたにもかかわらず、C++標準はもちろん、BoostにさえもXMLライブラリがないことがその証左となるだろう。実際、ストリーミング(SAX)対インメモリ(DOM)の議論から先にすすむことは滅多にない。

このセッションでは、別のアプローチを試み、C++アプリケーションで一般的なXMLの利用パターンについてまず考えてみる。次に、このことから導出される、パースおよびシリアライズ可能なXML API設計と実装について示す。利用パターンは低レヴェルXML加工(ドキュメント中心アプリケーション)から、単にデータ保持媒体としてXMLを閲覧する(データ中心アプリケーション)まで幅があるので、提示するAPIは低レヴェルアクセスから始め、それをもとにより高度な抽象化を組みあげていく。

完全を期すため、XML1.0パーサ適合であるとはどういうことか(ヒント：週末におもしろ半分で作ったようなものは多分適合していない)、既存のC++向けのXMLライブラリ/ツールと、その利点と欠点について、そしてXML Schema、XPath、XQueryのようなXML関連技術と、それらが全体図のどこに嵌まるのかについて、といったトピックにも触れることにする。

聴講者が実際に直面しているユースケースを、このXML APIで満足できるかどうかについてのフィードバックも歓迎する。

&&を理解しよう

C++11では右辺値参照、&&が導入された。この単なる二つの&はムーヴセマンティクスを与える魔力を持っている。しかし、&&は実のところ、さらに強力だ。std::moveとstd::forwardに隠された力もやはり&&だ。加えて、聞いたことがあるかもしれないがUniversal Referencesも&&を基礎にしている。

このような力をもつので、&&はややトリッキーであることがわかる。このプレゼンテーションでは&&のさまざまな使いかたを説明する。読んだり書いたりするコードにでてくる&&の持つさまざまな意味をどう区別するかについても触れる。さらに、コード中で&&を利用するベストプラクティスについても述べる。このプレゼンテーションは、いったいぜんたい&&ってどういう事か知りたいC++初心者から、&&を使おうとして思った通りに動かなかった中級者向けである。

並行アセンブリとしての最新のC++

  • Modern C++ as Concurrent Assembly
  • スピーカー： Diego Perini

C++ — あらたに採用された、高速に進化する開発サイクルの助けを持つ — は、現世代のアセンブリ言語となった。C++には、それ自体で、並行性をサポートする、真新しい、ドメインに依存しない言語を開発する基礎が揃っている。

Dopplは効率的なキャッシュ、高度な並行性、データ指向デザイン、言語の構成としてノンブロッキングロジックをもつプログラミング言語である。この言語はC++11と最新の安定標準ライブラリ実装の上に実装されている。

このセッションでは、Dopplの機能を実現するにあたり利用した、<thread>由来のツールや関数型プログラミング由来の材料、CそしてC++11で導入された機能について焦点をあてる。Dopplのサンプルソースコードはその高次構造を聴衆に紹介するために、参考としてのみご覧いただくつもりである。

値のセマンティクス：シンタックスについてじゃないよ!

  • Value Semantics: It ain’t about the syntax!
  • スピーカー： John Lakos

値のセマンティクスを持つような型について議論するとき、値で関数に渡せる(もしくは返せる)、ということに着目しているだろう。このような型を設計するために、C++はその型についてコピーコンストラクタを要求するので、プログラマは「この型のオブジェクトはそもそもコピー可能であるべきか？」という疑問にフタをして、日常的に自分のクラスにコピーコンストラクタを実装している。もしそうなら、コピーの真実とはなんだろう？元のオブジェクトと完全に同じ状態を持つべきなのか？オブジェクトをコピーするとはなんなんだ？!

値型については、型は(値の)セットを特に表現するものと捉える人が多い。しかし、値のセマンティック型については、数値と同様の操作を提供する抽象数値型(例えば整数、文字セット、複素数の配列)と捉えている。値のセマンティック型のオブジェクトをコピーしたとき、適切な値のセマンティック型の新しいオブジェクトは、元のオブジェクトと同じ値を持っているにもかかわらず、コピー先のオブジェクトは元のオブジェクトと同じ状態を保持していない可能性、さらには同じふるまいをしない可能性がある。

このセッションでは、たとえば値の顕著な属性の識別、および 自然に値を表現するオブジェクトとそうでないものとを比較することで、値の意味について直感的な感覚を得ることから始める。一般的な値型のシンタックス上特徴を概説した後、値のセマンティクスにかかわるより深い問題について考えていく。特に、値セマンティックオブジェクトにおいて、あらゆる顕著な変化を伴う操作に適用される、微妙な「値の基本的性質」について探求し、より興味深い(値セマンティクスの)クラスを正しく設計するために、この特性を有効利用してみる。

イテレータはまだ生き残る

コンテナとアルゴリズムを繋ぐ便利なインタフェースへの探究は、標準ライブラリのイテレータでも止められなかった。Boost.Rangeは、たくさんあるインタフェース候補の1つにすぎない。近年、異なるアプローチがあれこれ現れ、C++標準化委員会のRangesグループもこの探究に参加し始めた。

このセッションでは、これらの様々なアプローチを比較し、それぞれの利点と欠点を述べる。聴講者には、標準のアルゴリズム/コンテナライブラリに関する知識・経験を有していること、ジェネリックプログラミングに関する要点を理解していることが求められる。

Clangを使ったリファクタリングツールの自作

  • Create Your Own Refactoring Tool with Clang
  • スピーカー： Richard Thomson

C++のリファクタリングツールは他の言語よりも遅れている。だれしもC++でパースと推論するのが非常に難しいからだという言いわけを聞いたことがあるだろう。それじゃ、Clangを使ったツール基盤を見てメロメロになってもらおうか。実に簡単にリファクタリングツールが書けるようになる。

このセッションでは、段階的にClangを使って、関数の仮引数リストが「(void)」になっているのを空のリスト「()」に変換するリファクタリングツールを作っていく。この過程で、Clang由来のツールライブラリをどう使えばよいか、すなわち、パース済みの抽象構文木(AST: abstract syntax tree)の探査法、ASTの要素に合致するコードの記述、ツールライブラリを利用した、ソースコード変換を行なうための合致するノードの操作法といったことついて十分な知見が得られるだろう。

時間があれば、リファクタリングツールの別の例についてもごらんいただき、その動作について議論したい。

C++を用いた複雑な組み合わせ最適化アルゴリズムの設計と実装

  • How to Design C++ Implementations of Complex Combinatorial Algorithms
  • スピーカー： Piotr Wygocki

本講演では、最適化フレームワークの設計についての具体的な一つの方法に焦点を当てます。最適化アルゴリズムを設計する際には、汎用的かつ簡単に拡張可能であることだけでなく、ユーザフレンドリーなインタフェースを提供するという問題に直面するでしょう。私達は、C++11で導入された新しい機能を含む、テンプレートを主に用います。

一つの例として、ローカルメタヒューリスティックサーチ問題を例にあげましょう。ローカルサーチは非常に有名な最適化手法の一つです。この手法は非常に自然な手法である一方、実際の問題に対して非常によい結果をもたらします。多くのシミュレーテッドアニーリングなどのヒューリスティック最適化アルゴリズムの非常に良い一般化であるローカルサーチに言及することには、大きな価値があります。

本講演では、複雑なアルゴリズムをテンプレートメタプログラミングを用いて設計することに興味を持っている人に向けたものです。講演を理解するためには、一部C++11のスキルが必要となります．

C++における関数型プログラミング入門

  • Intro to Functional Programming in C++
  • スピーカー： David Sankel

関数プログラミングの核心とはなんだろう？ Haskellをやる必要はないのか？ 関数プログラミングはオールオアナッシングなものか？ C++を「より関数型に」するメリットは？ もしメリットがあるなら、どうやって関数型にしていけばいいの？

オブジェクト生存期間の管理

C++の強力な機能として、決定性の、スコープベースのオブジェクト生存期間が挙げられる。適切に利用すれば、リソースリークのない、例外安全なコードが記述できる。このセッションでは例を示し、コードを単純に、読みやすく、もちろん正しく書くための技法について議論する。

まずは構築/破棄の基礎からはじめ、RAIIとスマートポインタについて触れ、例外安全について議論し、最後にパラメータを渡すさいの所有権について議論する。

話の途中で、このスタイルのプログラミングがより容易になるC++11とC++14の変更についても議論する。

0xBADC0DE

自身のフリーランサーやコーチとしての経験が、このセッションを行う動機になっている。いろいろなところで、いいコードも悪いコードもたくさん見てきた。

このセッションでは悪いコードの例をみていくだけではなく、そもそも何故それが存在しているのか解析し、どのように対処ならびに修正していけばよいか述べる。話のなかでアンチパターンについて触れるけれども、このセッションはアンチパターンについてではなく、あくまで問題のなかの一つの例として取りあげる。

グローバル、スレッドローカル、および静的データの生存期間と利用法

  • Lifetime and Usage of Global, Thread-local, and Static Data
  • スピーカー： Daniel Dilts

Cはプログラム全体でデータを初期化、未初期化の如何にかかわらず宣言する機能がある。C++はグローバル、スレッドローカルなオブジェクトを生成するためにこの機能を拡張している。全てのオブジェクトと同じく、グローバルおよびスレッドローカルオブジェクトは生存期間の開始とともに構築され、終了とともに破棄される。

このセッションでは、グローバル、スタティックそしてスレッドローカルオブジェクトの生存期間について、C++11標準が保証していることについて述べる。よって、コンパイラが実際にどうしているかについても話すつもりだ。複雑な初期化のために、どうグローバルデータを使ったらよいかについて議論する。

グローバルデータの利用パターンや、グローバルデータの縮小についても議論したい。

Expected — 例外フレンドリーなエラーモナド

Expectedライブラリは、2012年にAndrei Alexandrescuによって紹介されたものをベースにしている。これはC++における新たなエラーハンドリングの方法であり、古典的なエラーコードを返す方法と例外の中間に位置する。Expectedは例外を送出するコードと完全な互換を持ち、例外フリーなインタフェースを設計することを補助する。クリーンなコードを維持しながらエラーハンドリングを強制するこの新技術は、Haskellのような関数型言語のモナドから拝借してきたものだ。しかし、モナドの事前知識は必要ない。

このトークでは、既存のエラーハンドリング技法の紹介から始める。エラーコードの返却と例外システムを比較し、Expectedを導入する。std::futureクラスとstd::experimental::optionalクラスが、類似のユーティリティクラスと概念的にどう異なるのかについても話す。

Expectedライブラリのコアとなる、様々な機能とセマンティクスを、次の例を使用して紹介する。ユーザー定義のエラー型を使用した例外フリーなインタフェース定義を、expectedクラスではどのように使用するのかを議論する。

monad errorのメソッドであるnextとrecoverを、いくつかの例を通じて紹介する。これらのプログラミング技法によって、エラーハンドリングのレイヤーと通常のコードフローを明確に見分けられるようになる。さらに、プログラマがエラーハンドリングを非侵入的に行うことも補助する。それと、関数型言語のモナドについて簡単な解説を行い、expectedがなぜモナドと見なせるのかについても話す。

残りの時間では、潜在的なモナドクラスであるstd::experimental::optionalとstd::futureについて議論する。

Haskellのモナドは、いくつかのシンタックスシュガーによって、コードをより読みやすくする。N3858 Resumable functionsのawait式と同様に、我々の新たなexpect式が例外送出のコードを読みやすくすることを示す。

注： このライブラリは、C++標準にはまだ提案されていないが、カンファレンスのあとに提案するつもりだ。

Boost.MetaStateMachineと次世代非同期ライブラリを利用した非同期プログラミング

  • Asynchronous Programming Using Boost.MetaStateMachine and the Upcoming Asynchronous Library
  • スピーカー： Christophe Henry

現実を直視しよう。巨大なアプリケーションではfutureが帰ってくるまで待っていては使いものにならないので、std::asyncは成功したとは言えない。N3558、N3650でもまだ問題は解決していない。

ASIO様のコールバックベースの解法ならよりよさそうではないか？

まずはBoost Meta State Machineや次世代非同期ライブラリの非同期の部分を使った関数のふるまいについてQtアプリケーション(CDプレーヤー)を調査する。

次に、非同期ライブラリのアクティヴオブジェクト、スレッドプール、アルゴリズムやその他の話題について焦点をあてる。

C++での関数型データ構造

正しく効率的な並行、並列プログラムを書くには並行データ構造が必要である。vectorの頭にmutexをぽんと置くのが最適な解になるのは非常に稀である。関数プログラマ達は偉大なる技法を編み出した - すなわち本質的にスレッドセーフになる不変データ構造を使ったのである。だが、もしデータを変更できないとして、どうやってプログラムを書いたらいいのだろうか？また、単にconst vectorを使うだけではなぜダメなのだろうか？

つまり、効率的な関数型データ構造を設計するための研究分野があることがあることが分かる。

舞台裏にはデータの変形や共有、そしてトリッキーな同期問題がある。例えば、(まぁ言ってみれば)単方向リストを定数時間で反転できる遅延評価をもちいてデータのコピーを引き伸ばすための技法がある。

このセッションでは、関数型プログラミング、特にChris Okasakiの名著、『Purely Functional Data Structures』から得られた知識に基づいて、C++で効率的なスレッドセーフデータ構造の実装について紹介する。

C++におけるメモリの所有権

  • Ownership of Memory in C++
  • スピーカー： David Stone

このセッションでは、("スタックベース"の)自動変数、生ポインタ、そしてスマートポインタといった、オブジェクトの所有権を定義する一般的な方法について検討する。また、C++標準ライブラリにあるスマートポインタの集合に対して細かな改良点を提案する。

C++の所有権に関する議論では(たとえあったとしても)ほとんどが軽くパフォーマンスについて言及するのみで、それを使うべき(もしくは使わないべき)かについての切言が主になっている。このセッションでは、正しさを維持したままパフォーマンスとメモリ効率を効果的に最適化するにはどうするべきかについてのみ扱う時間を設けるつもりである。

このセッションの主題はメモリに関連した所有権についてである。RAIIのような重要な指針についても概説するが、メモリ管理の文脈に限るものとし、一般的なリソース管理については対象外とする。

曖昧性解決における黒魔術

  • Disambiguation: The Black Technology
  • スピーカー： Zhihao Yuan

C++の関数呼び出しはCのそれよりも、オーヴァーロードにより高い柔軟性を備えている。だがオーヴァーロードはあいまいさの原因ともなるので、SFINAEやMPLのintegral_constant、タグディスパッチといった、一般的なツールを利用する。ところが、このようなツールの利用は関数名をただ変えるのに比べるとより"黒魔術"に近い。このセッションでは、関数のオーヴァーロードセットを管理するために、どのようにこれらのツールをつかえばよいかについて学ぶ。また、これらのツールで関数呼び出しのあいまいさを解決しなけらばならない時、すべき時、すべきでない時、できない時について理解できるだろう。

ライブラリの提案、libc++、libstdc++、Boostなどの実装から例示する。MPLの経験は必要ではない。

関数リアクティヴプログラミング - 滑かに抽象化された双方向性

  • Functional Reactive Programming - Cleanly Abstracted Interactivity
  • スピーカー： David Sankel

1997年にConal ElliotとPaul Hudakにより、関数リアクティヴプログラミング(FRP:functional reactive programming)と呼ばれる、双方向性の新しい数学モデルの発見が公開された。時間-関数に基づくモデルは根本的に典型的なイヴェントとコールバックパラダイムから出発し、対話型プログラムを書く上で、より自然かつ簡潔な方法 - タイムステップやフレーム、接続、またその他検討事項は完全に抽象化されている - をゴールとしている。

このセッションではFRP方法論を紹介し、'sfrp'という、ロボット工学やコンピュータアニメーション、UIといったドメインで容易に利用可能な、新規の業務用途に耐える関数リアクティヴプログラミングフレームワークを紹介する。 'sfrp'と他のC++やHaskellのFRP実装との比較についてや、商用アプリケーションで'sfrp'を利用した経験についても紹介するつもりだ。このセッションに参加した各位がFRPパラダイムをいつつかうか、また'sfrp'をつかってどのようにアプリケーションに適用するか知っていただければ幸いである。

本セッションの対象聴講者は、より強力かつ簡潔な対話型プログラムを作成することに興味がある、すべてのスキルレヴェルのC++開発者である。関数リアクティヴプログラミングや関数プログラミングの経験は不要である。

将来のC++におけるアクセラレータプログラミング

The Future of Accelerator Programming in C++ スピーカー： Sebastian Schaetz

OpenCL、CUDA、C++AMP、OpenACC、RenderScript、Thrust、Bolt、VexCL、Boost.Compute、ViennaCL、MTL4、NT2、Arrayfire — このようにアクセラレータプログラミングのためのツールや環境、フレームワークやライブラリはいろいろある。 このセッションではこれらのツールについて概説し、アクセラレータ利用の異なるケースとひもづけていく。 開発者の生産性や、汎用性、性能といった観点でどのように比較したらよいだろうか？

これらのツールを自由に使ってしまうと、アクセラレータプログラミングの問題は解決からほど遠くなってしまう。C++でデータ並列と並行を表現するよりよい方法があるはずだ。関数プログラミングコミュニティが我々の助けになるだろうか？または、Bret Victorが適切に述べたように、よりよい解を探すために単に「コンピュータについて考え、理解したことを全て忘れ、コンピュータが存在することを忘れ」るべきか。聴衆からのコメントはこのセッションの第二部で歓迎する。

C++におけるRipple Managementによる巨大なコードベース変更についての私見

  • My Thoughts on Large Code Base Change Ripple Management in C++
  • スピーカー： Niall Douglas

他の言語に比べて、C++98/03は非常に複雑だと言われつづけて久しい。C++11/14で追加された多数の機能は、次世代のC++コードベースがより一層複雑化することを示唆している。おそらく、計画中のC++17では、現時点で予測できない方向で事態はさらに悪化するだろう。

ソフトウェアの複雑化に対し、2020年ごろまで見つもられている指数関数的成長からはずれたコンピュータハードウェアの性能向上では対抗できない。つまり全てのコンピューターソフトウェアについて予測することがより困難になるだろう。

WG21 C++17の研究グループであるSG2 (モジュール)、SG7 (リフレクション)、SG8 (コンセプト)および、これらほどではないにせよ、SG10 (機能テスト) や、SG12 (未定義動作)は、C++17における複雑性管理を大幅に進化させる基礎であるが、C++の複雑性管理を進化させるこれらの研究についてまだあまり明確に言及されていない。

本プレゼンテーションでは、全てのC++ユーザーにとって、将来のC++コードベースを大幅に扱いやすく理解しやすくするために、SG2とSG7をSG3 (ファイルシステム)で組み合わせることで、このような複雑性がスケールする問題に対するあたらしい実装方法、すなわち、C++ランタイムの根幹にBoost.ASIOやBoost.AFIO、そしてBoost.Graphを基礎とする標準化された非常に軽量なトランザクショナルグラフデータベースを提案する。

翻訳

Akira Takahashi, zak, eagle_raptor, chichimotsu