3. C++Now! 2012

最終更新日時:
が更新

履歴 編集

C++Now! 2012

セッション資料

C++オンライン読書会 にて有志が一部の資料を読んでいるので、そちらも資料を読むお供にどうぞ。

ビデオ

参加レポート

セッションリスト

180分でめぐるBoost Library 50個の旅

このセッションでは、50個のBoost Libraryを180分かけて紹介する。多くのBoost Libraryについて、幅広く俯瞰する。あまりboostに詳しくない方、または、いくつかのライブラリしか知らない方は、今後、boostが提供すべきすぐれたアイデアを得ることができるだろう。このセッションは、後程どのライブラリについて学びたいか、いまのプロジェクトで使えるか、さらには貢献できそうか判断する指針となるだろう。 このセッションは、プレゼンターの著書である「The Boost C++ Libraries」(英語版 2011/6刊行)と「Die Boost C++ Bibliotheken」(ドイツ語版 2012/1刊行)に基づいている。これらの書籍ではすぐに習得できる一般的なライブラリを紹介している。このセッションでは、これらの本から例を引用するつもりである。

おなじ時間でより効果的な計算を： C++で組み込みリアルタイムコード

C++は非常に広い問題領域に適用可能なマルチパラダイム言語である。このセッションでは限られたメモリリソース、かつ、200KHz(5マイクロ秒)サーボインタラプト割合のリアルタイム組み込みシステムにC++を利用した際の最適化と拡張について紹介する。二年以上かけて、このシステムのデータ処理帯域幅は、ハードウェアの強化をすることなく大きく改善した。この改善を達成するために、様々なアプローチとテクニックについて議論した。その結果、ほとんどのよく知られているC++イディオムは組み込みのリアルタイムシステム環境にはよく合わないことが分かった。しかし、C++はCよりもメンテナンスの面でもコード実行速度の面でも優位な性能を見せた。

このプレゼンテーションは、組み込み向け、汎用機向けという区分なく、特定のC++コードの実行速度の高速化に興味がある方には有意だろう。

このプレゼンテーションで、特定の組み込み環境について、何が正しく動き、何が正しく動かないのか、そしてその理由はなにかについて説明する。主なテーマはパフォーマンスモニタリング、特定領域のコードデザイン、コンパイラに高速なコードを生成させる方法、スレッドセーフオプションである。

駆け足でC++11の概要

このC++11の簡潔なイントロダクションでは、プレゼンターであるLeor Zolmanが言語への主要な機能追加について調査する。また以下の項目についても述べる：

  • コード可読性の向上について(ラムダ, 統一初期化, auto)
  • パフォーマンスの向上について(右辺値参照とムーブコンストラクタ)
  • マルチスレッドについて(並行性とアトミック型)

また、他の多岐に渡る便利な機能や、標準ライブラリのコンポーネント(スマートポインタと新しいSTLコンテナ)についても触れる。

このプレゼンテーションはC++11の簡潔な概要を知りたい方向けである。そのため、詳細をカヴァーしきれない言語機能、ライブラリが多々あることをご了承いただきたい。

odeint - C++で常微分方程式を解く

常微分方程式(ODE: Ordinary differential equation)は自然科学、応用分野の諸領域で重要な役割を果たしている。
例示すると、古典的ニュートン物理学、化学反応式、量子系から神経系にわたる、個体群動態における反応速度式などである。
さらに、常微分方程式は偏微分方程式(PDE: partial differential equation)の離散化をする際頻出する。

このプレゼンテーションでは、odeint(odeint.com) -常微分方程式の数値解法を探索するためだけのC++ライブラリ- を紹介する。このライブラリはBoost入りを目指している。

odeintは非常にジェネリックに実装されており、高速に相互運用することができる。

odeintはODEソルバのためのC++コンセプトを導入しており、標準的なメソッドを数多く実装している。例えば、古典的Runge-Kuttaスキーム、ステップサイズコントロールと稠密出力のメソッド、非明示なメソッドとシンプレティック解法などである。； odeintはコンテナ非依存であることを強調しておきたい。つまり、使用者はstd::vectorのような特定の型を使うことを強いられない。 それゆえ、ネットワーク、ラティス上のODEを解くこともできる。 さらに、多倍精度か区間演算を利用できる。 ジェネリックな設計を取っているので、odeintは容易に並列化してCUDA GPUで実行できる。 それにもかかわず、odeintはわかりやすいインターフェースを備えているので、簡単に、容易に使うことができる。

このプレゼンテーションではodeintの主要な機能ならびにそのソフトウェアデザインについて述べる。

新仕様できたてほやほや!

C++11では様々な方法で言語を拡張する興味深い新機能が導入された。

このセッションではそれらを完全に無視して、別のテーマに焦点を当てる。すなわち、C++11でよりシンプルに、クリーンに、エレガントに記述する方法について述べる。このセッションはソフトウェアデザインの最先端についてあまりよく知らないけれど、クリーンかつシンプルかつ効率的なコードを書くことに関心がある方に最適である。話のなかでデザインについて知見が得られれば幸いである。

ハイパフォーマンスを求めるためだけではなく、高次の並列化のためのOpenMP

OpenMPは高次の言語を用いたインクリメンタル並列化をサポートする、C,C++,FORTRAN向けの分散メモリ並列化の仕様である。

OpenMPはハイパフォーマンスコンピューティング、スーパーコンピューティングのためのもの、と思っている方がいるかもしれないが、実際は他にほぼ類をみない分散メモリ並列化 - これは3つの汎用言語で実装されている - に適しており、それ自体高次言語である。OpenMPはグラフィクスや可視化の分野や、組み込みやリアルタイムアプリケーション分野、コミュニケーションとネットワーク分野、自動化とロボディクス分野、財務や通商分野、医療と生命工学分野、石油・ガス業界、シミュレーション、データベースとミドルウェア、音声・オーディオ処理、汎用データ解析などの分野でも有効であることが知られている。

HPX: C++11並列実行システム

計算科学のアプリケーションは、しばしば基になる実行モデルから受けついだ選択の影響を受ける。並列計算アプリケーションにおいては、MPIが注目をあつめている。しかし、電源や、プロセッサコアの複雑性、マルチコアソケット、GPUの異種混在という問題が深刻になってきたため、並列アプリケーションはスケーリング不全の危機に陥っている。

HPX実行時システムはモジュラーであり、完全実装であり、SMPノードとコモディティ・クラスターのような従来型の並列計算アーキテクチャを対象としたParalleX実行モデルのパフォーマンス指向の表現である。MPIの代替として、HPXは軽量ユーザースレッドを管理するためのルーチンに加えて、アクティヴグローバルアドレス空間(AGAS: Active Global Address Space)を提供している。HPXはC++11で実装され、20のBoostライブラリ/Boostライブラリ候補を利用している。

このプレゼンテーションでは、実行時システムアーキテクチャに焦点を当てるとともに、HPXでどのようにBoost C++ライブラリやC++11機能を利用しているかについて議論する。HPXの概要についてプレゼンテーションし、さらに、競合するランタイムシステムおよび科学計算コミュニティ向けアプリケーションとの比較とベンチマークを紹介する。HPXに興味、関心をもたれて、実際に試用していただければ幸いである。ダウンロードはこちらから： http://stellar.cct.lsu.edu/

ラムダ関数

無名関数は多くの言語で有用なツールとして成功を収めている。その局所性と明瞭な構文により、高い表現力と、バグの少ないコードを記述できる。Boost.LambdaやBoost.Phoenix、そしてFC++といったライブラリによって、C++にラムダ式がもたらされたが、今日、C++11には言語機能としてラムダ関数がある。ラムダ関数は無名関数オブジェクトとよく似ている。というのは、ラムダのスコープ外でキャプチャ/識別子の状態の変更が可能だからだ。

この90分のチュートリアルセッションで、この新しい言語機能の構文と利用方法を概観する。上達を図るために練習問題や例を多数用意している。ラムダが利用可能なコンパイラを持参し、ぜひラムダ関数を使うとコードがどれほどよくなるか体験していただきたい。

来るC++1xへの提案

C++11が公開された今、C++1xに搭載される次の機能は何だろうか？ このプレゼンテーションでは2月のコナ会議で提案されたものを紹介していく。Evolution Working Groupでレヴュー済みのペーパーと、ConcurrencyおよびLibrary Working Groupの活動についても焦点を当てる。 おまけ： 主要なコンパイラについて、最新のC++11実装状態についてもお伝えしたい。

2012年2月のコナ会議を経て、標準委員会は次のC++標準を暫定的に2017年に、その次を2022年に、おおよそ五年毎に公開するように決定した。また、いくつか主要なものを例にあげると、モジュールや高度な並列抽象化、リフレクションといった次の標準にむけての提案についても精査した。このプレゼンテーションではこれらの機能について焦点をあて、C++11にどのような影響を与えるかについて議論する。

カナダ、IBMのC++標準委員会代表や、BoostConでトランザクショナル・メモリからC++11の並行について多様なトピックを長きにわたってプレゼンターを務めた者として、標準委員会でC++の将来搭載されるべき機能についての議論にはできるだけ参加するつもりである。

モナドを使って可変長テンプレートメタプログラミング

C++11 の新機能である可変引数テンプレートは，パワフルだが気の触れた制限がついている．なんと template parameter pack が一級市民ではないので，一部のよくある(メタ)プログラミングの定石で使いにくいのだ．うれしいことに偶然，関数型プログラミング，正確に言うと Haskell では，おもしろい方法でこの問題を解決している．というわけで我々は，可変個継続，継続モナド，カリー化，その他C++メタプログラミングで使うためのエキゾチックな構成を使った方法について話す．

Ustring - 現代的なstd::stringの代替

C++プログラミングで推奨される文字列表現はstd::stringである。しかし、実際には、あるプログラムには三つ以上の文字列型(例えば、std::string、MFCのCString、char*)が混在していることがほとんどである。われらがstd::stringは長年よくやってくれているが、いろいろな制限やときどき見せる奇行に悩まされることもままある。そして、他の文字列クラスが備えている便利な機能、特に言うならUnicodeサポートが欠けている。C++11が公開されたことと、std::stringが実装されてから数十年来の知見を集めて、よりよいツールを創ってみた。

このプレゼンテーションの前半は、将来、強力かつ競争力のあるツールとなるよう、std::stringの制限や問題を解決することをめざした新しいクラスの設計について述べる。多くの知見を集積して、C++11にふさわしい、簡便で、表現力豊かで、強力な文字列処理を創りだすことが目標である。そのために、後半は理論や秘話、懸案事項やアイデアなどをいただきたく、聴講されている皆様とブレインストーミングするセッションにするつもりである。このライブラリは開発の初期段階にあるので、変更の余地はあるし、どんなアイデアでも歓迎する。

C++11: 高次のスレッディング

C++11は並行処理の新しい機構を備えている。慎重に設計されたシステムのプログラミング言語であるならば当然のことだが、言語機能は厳格な理論的基礎(メモリモデル)に基いて構築され、低レヴェルプリミティヴ(atomic)へのアクセスを提供している。幸運にも、C++11ではスレッドを効果的に使う際に、こうした難解な詳細について理解する必要はない。(もし低レヴェルの事柄について詳細を知りたければ、Tony Van Eerdのプレゼンテーションを見るべし)

その基礎の上に、プログラマが日々のコンカレントなコードを記述する際、実際に使うべきAPIが用意されている。すなわち、大量のロックやミューテクスや条件変数、そして、より高いレヴェルのfuture, promise, packaged_taskなどだ。また、スレッドセーフなプログラミングの中核的問題についても述べ、これら問題を解決するためのコンポーネントの使いかたについても述べる。

メモ： このプレゼンテーションに興味を持たれたかたは、"Other C++11 Gems"のプレゼンテーションにも食指が動くかもしれない。そちらのプレゼンテーションでは、時刻や時間、タイムアウトでのロック、スリープといった優れたデザインの新機能について取りあげるそうだ。

標準委員を質問攻めにしよう!

  • Grill the Committee
  • スピーカー：Jon Kalb

C++標準のなれそめについて知りたくないか？ このパネルディスカッションではC++標準委員会のメンバーに登壇いただき、聴衆の皆様に気になっていることを質問していただく趣旨である。

キーノート： C++11で前進せよ!

右辺値参照はC++に二つの新しい相乗的に機能するプログラミングイディオムをもたらす。すなわちムーブセマンティクスと完全転送である。このプレゼンテーションでは右辺値参照とは何か、ムーブセマンティクスとは何か、完全転送とは何か、といった基礎からはいる。また、このプレゼンテーションではこれらが導入された動機や利用法、コンパイラがこれらを自動生成する条件についても述べる。さらに、クラスを設計した後でも、条件に合致すれば自動的に、ムーブセマンティクスが最適化の役目を果たすことができるけれども、ムーブセマンティクスの知識は直接的にクラス設計に影響を与えることを示す。

Metaparse – テンプレートメタプログラミングによるコンパイル時構文解析

Metaparseは、C++のコンパイル時文字列を解析する、パーサー生成のためのC++テンプレートメタプログラミングライブラリである。Boostはすでに2つのパーサージェネレータライブラリを持っている：Boost.SpiritとBoost.Proto。MetaparseとBoost.Spiritの主な違いは、Metaparseによって生成されたパーサーはコンパイル時に実行され、Boost.Spiritによって生成されたパーサーは実行時に実行されるということである。Boost.ProtoパーサーはC++の有効な式をコンパイル時に処理し、Metaparseは自由形式の文字列を入力としてパーサーを構築する。

コンパイル時の任意なテキストを解析することは、多くの状況で有用である。我々はより複雑なユースケースを比較的に簡単にする方法を提供する。一般的な構文は、以下の正規表現のコンパイル時検証を有効にすることでBoost.Xpressiveのラッパーを作成できる。より複雑な例として、printfの書式指定文字列を解析し、コンパイル時に引数の型を検査する。コンパイル時パーサーの別な手段は、組み込みDSLスクリプトをC++のネイティブな関数への変換をコンパイル時に行い、実行時にそれを実行することである。最も複雑な例では、テンプレートメタ関数を定義するために、組み込みDSLをどのようにして実装するかを示す。Metaparseはパーサー生成のDSLをメタ関数に変換する能力を持つ。

Metaparseの内部構造と、それをどのようにして拡張するかを説明する。ライブラリの正確なエラー報告の機能を紹介する。モナドの概念の入門と、それを使用することでパーサーの構築を容易にすることを示す。新たなC++標準のconstexprは、コンパイル時にアルゴリズムを実行するための構造を提供する。メタプログラミングとconstexprの間を繋ぎ、パーサーによって処理される入力の構文的なオーバーヘッドを最小限にしてそれを利用する方法を提供する。

Metaparseと、その元となるライブラリは、以下から利用可能である：

これはユーザーと開発者にとって高度な話である。Boost.MPLに精通していることを前提とする。

Ladon - 分散状態マシンフレームワーク

階層的な状態マシンは、多くのドメインにエレガントな解決策を提供する。それらの厳格な要件は、高い信頼性のシステムのための規律を一段階強化する。状態マシンはシステムの反応的な振る舞い(reactive behavior)について記述するのに役立つ。ポート束縛、メッセージ配信、およびプロトコル変換を提供する一方で、コミュニケーションポートや包含コンセプト(containment concepts)のようないくつかの(ROOMのような)構造的コンポーネントを加える。そうすれば、分散状態マシンフレームワークが生まれる。よく定義されたインタフェースを持ったより小さな分散マシンに分割することは、大きな反応的システムのための強力なツールである。

このセッションでは、Ladon分散状態マシンフレームワーク(C++Now 2012でデビューするciere consultingのオープンソースプロジェクト)を導入する。Ladonは、反応的なシステムのためのリッチな分散ソリューションを作成するために、Boost.MSM、Boost.AsioおよびBoost.Spiritを融合させる。フレームワークの設計と基本的な使用法についての議論に加え、我々はあなたのシステムで使用できるおもしろいパターンと解決策のいくつかを紹介する。我々が言及するライブラリは、以下のものを含む：MSM、Spirit、Asio、Fusion、Signals2、そしてPhoenix。

この90分間のセッションは、初心者と中級レベルの出席者に、いくつかのBoostライブラリと現代的なC++手法の概観を提供する。

語源 - Ladon(Λάδων)は、ヘスペリデスの庭のトマトを守護する、ギリシャの100の頭を持つヘビのようなドラゴンである。頭がそれぞれ異なる言語を話したという噂がある。

黒魔術につき取扱注意 - C++11で低レヴェルスレッディング

今日のC++は"メモリモデル"がある。しかしこれはどんな意味で、どうして導入されたのか、また、以前のC++に必要なかったのは何故か？ これを使って何ができるか？ そしてこれらの新しい原子操作にはなにやら相関があるようだ… むむむ…

C++で例外安全なコーディング

皆様のコードは100%例外安全を達成していると言えるだろうか？

例外を安全に利用するのはなまはんかな問題ではない。この業界では20年来この問題に奮闘してきた。もし皆様が恐怖や不透明感、例外安全に疑いをもっていたり、純粋にC++で例外のベストプラクティスを知りたいと思っているならば、ぜひこのプレゼンテーションを聞いていただきたい。まず始めに、"何を解決しようとしているか"から入り、代案について議論し、例外の利用に関する問題を確認し、例外安全について曲解されやすい試みについて述べる。また、安全な例外の利用法についての基本的なガイドラインと過去の例外安全ではないコードベースから移行するための鉄板の実装テクについても述べる。

このプレゼンテーションの目的は、皆様に、簡単に記述できて、理解しやすく、高速に動作し、例外が発生しても100%の堅牢性を誇るコードをどうやったら書けるようになるかお伝えすることである。

BoostをGitに移行しよう

Gitヴァージョン管理システムはSubversionに比べてBoostの開発者、利用者双方に利益がある。このセッションではBoostからみたGitについて紹介し、徐々に高度な議題について述べていく：

  • なぜGitなのか？ - 成層圏から俯瞰してみよう
  • 皆様にGitの基礎を知っていただくために、駆け足のGitのチュートリアル
  • Subversionに対するGitの優位性 - Boost開発者の視点から
  • Subversionに対するGitの優位性 - Boost利用者の視点から
  • Boostのモジュール化への試み - 課題、アプローチ、トレードオフについて
  • Boost開発者にあわせたワークフロー構築の試み
  • BoostをGitに移行してみるワークショップ - 実行計画の開発

この"BoostをGitに移行しよう の前準備"と題したドキュメントとファイルをC++Now!の二週間前くらいまでに用意するつもりである。

C++11標準ライブラリの策定を通じて学んだこと

C++11の標準化作業はおおよそ8年かかり、標準ライブラリのサイズは少なくともページ数上では倍増した。標準化作業は標準ライブラリの設計を再確認し、おおよそ十年間で蓄積したBoostライブラリで得られた知見や開発技術をもって仕様をクリーンアップし、右辺値参照やコンセプト、並行処理のサポートといった、言語に導入が考えられた新しいアイデアについて学び、最後に新しい機能でライブラリを拡張した。この経験は有意だったか、それとも無意だったか？ 次の機会によりうまくやるために、いったい何を学んだのか？ 次のライブラリ TR を策定するにあたり、このレッスンをどう生かせばいいのか？

科学的ソフトウェア開発における現代的プログラミングテクニックとBoostライブラリの適用

現代的プログラミングテクニックとライブラリを利用することで、ソフトウェア開発者は膨大な機能と柔軟性を手にいれることができる。しかし、ジェネリックプログラミング、関数型プログラミング、メタプログラミングのような関連技術を利用するには、高度なプログラミングスキルが要求されるので、マニアかコンピュータサイエンティストでなければ使い熟し得ない。

このプレゼンテーションでは、Boostライブラリのような現代的プログラミング技術を利用する科学的コンピューティングの範疇に含まれる3つの仕事について報告する。まず、主にBoost GraphライブラリとBoost Phoenixライブラリを利用した順次および並列タスクグラフ実行のための拡張可能なプラグインスケジューラを紹介する。次に、Boost MetaprogrammingライブラリとBoost Fusionライブラリを利用した、コンパイルタイムに任意のプロパティに基づいてコンポーネントのサブセットを選択するというメタプロパティの選択方法について紹介する。最後に、ジェネリックパラダイムのもと幾何学的アルゴリズムを一般化するためのアプローチについて示す。

これらアプローチの紹介を通じて、現代的プログラミングテクニックとBoostライブラリの適用により、非常に汎用的で、維持可能で、コンパクトで、拡張可能なコードを生み出せることを示す。以上から、長期的には高度なC++スキルを習得するために費した時間はペイすると結論する。

C++開発者むけVisual Studio IDEの最新情報

きたるVisual Studio 11のリリースには、IDEとのやりとりやチーム内の他のC++開発者と共同作業するといった、日々のコーディング作業でC++開発をより効率的にするような新しい機能や革新が数多く詰まっている。

本プレゼンテーションではデモをごらんいただきながら、構文の色分け、参照のハイライト、進化したインテリセンス、コード解析、プロファイリングといった機能に焦点を当てて紹介する。また、ドキュメントとの連携、検索やナビゲーションといった普段の作業を非常に簡易化するIDEの改善点についてもひととおりごらんいただく。このプレゼンテーションではコードレヴューやテスト、コードカヴァレッジといった統合機能についても概説する。Visual Studio 11はC++開発者チーム全体に有益である。

キーノート： C++におけるモジュール

C++の幕開け以来、プリプロセッサはC++ライブラリインターフェースとやりとりするための手段としての役割を果たしてきた。しかし、長年にわたり、プリプロセッサであるがゆえに生じる制約によって、不愉快なビルド時間は増加の一途をたどっている。今日、プリプロセッサはよりよいC++開発ツールをつくるにあたり唯一最大の阻害要因になっている。

このプレゼンテーションでは、C++に"モジュール"の概念を導入するための選択肢を紹介し、それらがもたらす課題と恩恵について議論する。次のC++標準仕様に向けて、C++標準委員会はこれらの選択肢について活発に検討している段階である。

C++でのジェネリックプログラミング： 実例を交えて

この90分のセッションでは、Boost MLでいただいたリクエストに答えようと思う。

なぜBoostにはhex／unhex関数がないのか？ とても有用だと思うけど。

また、Boost.Algorithmライブラリにマッチしたこれらのアルゴリズムのデザインと実装についても概説する。

この関数は単純であるけれども、非常に多くの興味深い設計決定が実装中になされている。これについてもこのプレゼンテーションで述べるつもりだ。

カヴァーする議題は以下の通り：

  • ジェネリックプログラミングデザイン
  • イテレータの取り扱い(出力イテレータの問題についても述べる)
  • テンプレートメタプログラミング(enable_ifの用法についても述べる)
  • Boost.Exception
  • コードの最適化

Boost.Protoを用いた最低次変分法のドメイン特化固有言語の実装

このペーパーでは、FreeFEM様のドメイン特化言語を用いて線型離散と双線型離散の定義を対象とする拡散問題を解くための最低次変分法族の原実装を示す。Boost Protoフレームワークの利用によって、この言語のバックエンドとフロントエンドをどう実装したかについて議論する。種々の学術的問題の実装を行なうことで、このDSEL設計を検証する。この言語のオーヴァーヘッドは従来の実装と比較することで評価する。

C++11コンテナの最新情報

C++11でピカピカのコンテナがいくつか導入された。すなわち、単方向リスト、ハッシュコンテナ、固定長同型コンテナ、そして異形コンテナである。しかしこれだけではない。前仕様C++98/03のコンテナも新しいメンバ関数の追加、ムーブのサポート、"移動のみ"のコンテナをつくれるように、value_typeに課されていた制限の緩和といった手直しがなされている。さあC++11のコンテナを有効利用する方法についてみていこう。

ConceptClang： C++ Conceptの実装モデル

Conceptはテンプレートに安全性を付与することを意図として、制約ベースのポリモルフィズムを行うために提案されたC++の拡張である。本プレゼンテーションではConceptClangを紹介する。これは、C族言語のLLVMフロントエンドであるClangをベースとする、Conceptデザインの検証を行うための基盤の実装例である。このプレゼンテーションでは、Conceptの提案された主要な機能(コンセプトに基づく探索、テンプレートのオーヴァーロード、テンプレートの拘束など)をどう実装したかについて述べるとともに、種々のConcept設計を深めていくために、ConceptClang基盤をいかに利用すればいいかについても示す。

現代的C++テクニック入門

ポリシー、SFINAE、タグディスパッチ… ktkr! 現代的C++にノって弾みをつける準備はOK? Ciere C++ ニンジャシリーズから、このセッションでは基本的なことから、ジェネリックプログラミングで使われているテクニックやストラテジーを紹介する。このセッションで話すトピックは以下のとおり：

  • Concept
  • Trait
  • ポリシークラス
  • CRTP (Curiously Recurring Template Pattern)
  • SFINAE (Substitution Failure is not an Error)
  • タグディスパッチ

この3時間のハンズオンチュートリアルは例がびっしりの参加型セッションである。ノートPCを持参されたし! 日々のコーディングで現代的C++の技法を使いたい開発者には、きっと得るものがあるだろう。

C++11のスマートポインタとアルゴリズム

C++03で言うところのスマートポインタとはauto_ptrだった。auto_ptrは最良の型であり最悪の型である。このプレゼンテーションではauto_ptrがどのようにunique_ptrを触発したか、その違いはなにかについて説明する。unique_ptrを比較対象として、shared_ptrについても概説する。これらを使うべきときはいつか？ どちらのスマートポインタを使うべきか？

加えて、このプレゼンテーションではC++11に新しく追加されたアルリズムについて、また、unique_ptrのようなムーブのみ可能な型で動作するよう修正された多数の新旧アルゴリズムについても述べる。

Boost.Polygon.Voronoiライブラリを例に、堅牢かつ効率的多倍精度アルゴリズムの設計について

複雑な数値計算アルゴリズムの設計と実装はユーザビリティ、拡張性、効率性、堅牢性という4つの要素を満たさねばならない。

ユーザビリティとは、その分野に精通していないユーザーにとっての、公開されているアルゴリズムインターフェースのわかりやすさである。同時に、精通しているユーザーにとっての、アルゴリズムを構成できる幅のことでもある。

拡張性とは、アルゴリズムそれ自身、依存するデータ構造、計算カーネル、数値型といった部分を再構成または置換する際、アルゴリズムに汎用性と柔軟性を持たせることである。

効率性はまずアルゴリズムの複雑度とデータ構造の分析に始まり、メモリやパフォーマンスプロファイルを行い、システム/コンパイラ特異的な最適化に終わる。これには、数値型の操作および現実装と他のよく知られたアプローチとの比較も含まれる。

堅牢性は数値アルゴリズムの最も重要な研究分野であろう。もし内部データ構造が実行時に破壊されたらどうなるか、という問いに対する答を用意しておくことである。アルゴリズムの出力と、出力がどの範囲で正常かつ信頼できるかを定義することでもある。言い変えれば、受けとった出力とランダムデータとの違いは何か、ということである。

このプレゼンテーションでは、アルゴリズムの動機となった実世界の問題を見ていきながらアルゴリズムを紹介する。Boost.Polygon.Voronoiライブラリで用いているアルゴリズム設計テクニックと実装をもとに、上記で言及した要素全てについて示す。

C++11: クラスやライブラリ実装者のための新しいツール

この新しい標準はクラスやライブラリ実装者のために、可変引数テンプレートやstatic_assert、constexpr、明示的な変換関数、およびdecltypeといった多数のツールが用意されている。

CMake、モジュール化と Ryppl 開発者向けプレヴュー

  • CMake, Modularization and Ryppl Developer Preview
  • スピーカー：Dave Abrahams

Rypplは、C++の開発や、構築、テストならびにBoostとそのユーザーの要求、すなわちC++コミュニティに合わせて設計された配信のための基盤フレームワークである。巨大化、複雑化、また潜在的にモジュール化がすすむBoostは、Rypplの完全なテストケースになりえる。このため我々は一年間、このコンセプトを証明するために必要なシステムと変更に取りくんできた。

このプレゼンテーションでは、CMakeを使ってビルドおよびテストできるように、なにもインストールせずに配置できるように、またBuildBotを用いてリモートでビルド、テストできるようにするための、Boostのモジュール化にむけた作業の進捗について示す。BoostCon(訳註：C++Now2012のことか)が始まった時点で、Boost開発者に利用いただける、コミュニティ全体で予備的なレヴュー可能なシステムの機能を完全に揃えている予定である。

キーノート： さて、これからどうしよう？ 3つの視点から

C++は効率性が要求されるところでは復権を果たした。しかし、C++へ移行してきた者に対して、いまだ多くの者が歓迎していない。これはJavaやJavaScript、Pythonからきたプログラマにとって移行の脅威になりえる。C++コミュニティとして、美しく、効率的なコードを書くための、C++11で提供されるツールを梃入れする必要がある。

  • パート2： 真実

今日のハードウェア上では、単一スレッドで実行されるC++コードではマシン性能のたった0.25%ほどしか引き出せない。C++11ではほんのちょっとだけスレッドサポートが解禁された。未来を見据える言語、ライブラリに課せられた最大の試練は、いかにマシン性能の残り99.75%を引き出すか、ということに尽きるだろう。

  • パート3： 美点

過剰なネットワークディヴァイスはソフトウェアの展望を変えつつある。インターネットの基盤は次第に裏方にまわり、増えつづける顧客はディヴァイス上にある情報を簡便に取得できるよう要求している。そのようなシステムが我々のソフトウェア設計と記述にどんな影響を与えるだろうか？この新しい世界におけるC++の果たす役割とは何だろうか。

コンパイル時 '再パース'

C++コンパイラは今コードをパースしているとする。さて、その一部を再度パースしたいとしたらどうだろう？

数年前から、ドメイン固有特化言語のためのメタプログラミングライブラリ群が提案され、ユーザーや特殊なライブラリアンはC++内に独自の言語を構築できるようになった。このようなユーザーやライブラリアンは皆、実行時表現のEric Niebler氏によるBoost.Protoに精通する必要がある。しかし、Ábel Sinkovic氏による、コンパイル時文字列パースのためのMetaparseや、<>表記をパースするための、プレゼンターが作成した"とんがった(原：Angly)"パーサもある。

このプレゼンテーションではこれら三つのライブラリを研究し、計算的に等価であることを(一方で、ドメインや表現力の違いについても)示す。コンピュータサイエンスの視点からは、これらライブラリは全てプッシュダウン・オートマトンである。ではなぜインターフェースがこうも違っているのだろう？対象ドメインの違いから生れるものなのか？それともライブラリ著者のバックグラウンドによるものなのか？

また、コードをごらんいただきながら、これらのライブラリが実際にどのように動作するかごらんいただきたいと思う。このプレゼンテーションの大きな目的は、これらライブラリでどんなテクニックが一般的になっているか見ていくことと、共通のパターンがあるかどうか見ること、そして聴衆の皆様にメタプログラミングテクニックについて習熟していただくことである。

型から文字列への変換と、その逆

このプレゼンテーションでは、型から文字列への変換、またその逆に変換する際の、さまざまな選択肢について研究していく。古くはatoiやstrtolから、真新しくはstd::stoiや、boost::lexical_castのようなBoostで提供されているものまで見る。これら選択肢のエラーハンドリングやフォールバック機構、localeサポートといった観点からみた利点と欠点についても研究する。

利点と欠点を見ていただいた後は、それら利点と欠点をもとにGoogle Summer of Codeで作成したboost::coerceについて、現在の選択肢をどう補間するか紹介したい。このライブラリは速度や拡張性の面で優れている。このプレゼンテーションでは設計について概説し、またどう達成したかについて、使用法の豊富な例とともに紹介する。

時間が許すなら、カスタマイズポイントやSpiritとの関連を見ていきたい。

C++11にある珠玉の品々

非常に重要だが、それ単品では1セッションに満たないようなトピックについてとりあげる。GarlandとHinnantは<chrono>と<ratio>から。またstateful allocatorとregexへのサポートについてもとりあげる。

Boost Protoで線型計画法を簡単に

オペレーションリサーチや金融、チップデザインに渡る分野の問題は、線型計画にモデル化できる。決定問題のための高度に汎用的で効率的なアルゴリズムがあるメソッドとして、線型計画法は有効なツールである。

GLPKのような、線型計画を解くための強力なソフトウェアライブラリが存在するが、低レヴェルAPIが非常に使いにくいので、問題を一旦人が読みづらい形式に変換する必要がある。AMPLのようなモデリング言語を使えば、問題を容易に叙述的に表現できるが、汎用プログラミング言語としての力量と親和性が足りない。

このプレゼンテーションでは線型計画法を表現し解くための、Boost.Protoを用いたDSELであるCVX++を紹介する。Protoはどちらの世界、すなわちC++に組み込まれた叙述的プログラミングスタイルとして最高の役割を果たしてくれる。CVX++はGLPKをバックエンドソルバとして備え、Protoを用いて目的関数と制約をより機械が読みとりやすい表現に変換する。

SolidFireではC++11への移行をいかにして成しとげたか

このプレゼンテーションでは、SolidFireのコードベースをC++03からC++11に移行する過程について、まず作業チームがワクワクするところから順に見ていく。正確性の検証やパフォーマンステストをどう行なったか、またそれとともに、C++03とC++11のどちらでも動作するコードをどう書いたらいいか紹介していくつもりだ(また、どうやって障害を迅速に乗り越えたかについても)。

C++03/C++11開発で最初の月を越したころ、我々はよりよいコードを書くためにC++03コードベースのサポートを放棄した。このプレゼンテーションの第二部は、新しい標準によってもたらされる新しいコーディングスタイルについて述べる。また、それなしでは実装できなかったとんでもなくトリッキーなクラスや、可読性を上げるためにややトリッキーなことをしているクラスについても紹介する。

ClangでC++のリファクタリング

十年来、C++開発者はJavaなどの言語が持っているツールをうらやましく思っていた。Clangでとうとう、我々は安全な自動変換を構築することができるほど簡便にC++コードの推論ができるようになる。このプレゼンテーションでは特殊なC++パターンの自動認識と変換をサポートする、Clang上に組まれた基盤について紹介する。また、古いAPIから新しい別のAPIへ更新するための、実際のソースコード変換ツールを実装するために必要な知識・技術についても示す。

ライブラリの利用者が自身のコードを新しいAPIに置換するためのユーザー向けのスタンドアロンツールを組みあげることは、Boostのような広く利用されているライブラリでは非常に重要だが、C++11においては、新しい言語機能の利益を教授するために大量のインターフェースが更新されることになる。これらのインターフェースの採用を自動化することは、広く利用されているライブラリでは、長期にわたってサポートしなければならない非推奨APIの増加を抑える意味でも、急速な進歩をする上でも極めて重大なことである。

Boost.Coroutineを用いてステートマシンを解決する

このセッションはイヴェント駆動型プログラムにおけるスタートアップのケーススタディである。このプログラムは外部サーバーへの一連のリクエストを生成し、それぞれ結果が返ってくるまで次のリクエストの生成を待機している。

もともと、これはグローバルなint状態変数を使って、巨大なswitch文として実装されていた。内在する関数はすべてのフレームで呼び出され、現在のステートロジックにジャンプし、結果を受けて状態を更新する。

共同研究者がこれをBoost.Statechartを使って、ロジックをクラスのコレクションとして表現することで再実装した。

どちらのケースでもロジックの構造は明確だった。実際の制御フローを解明するために、全てのコンポーネントの念入りな研究が必要だった。

我々は同じロジックを、外部サーバーへのリクエストを結果が返ってくるまで待機する関数呼び出しとして表現するコルーチンとして再実装した。このような関数呼び出しはコルーチンだけを阻害する。すなわち、メインスタックの通常のフレーム毎の処理が継続する。実際のスタートアップ制御フローは、C++に精通していれば誰でも読める三重ループとして表現できる。さらに、メンテナンス(例えば、新しいリクエストを挿入するとか)は非常に容易である - これは前の実装ではとても言えなかったことであるが。

このようなユースケースにおけるスレッドとコルーチンの対比を行う。

coroutine オブジェクトの操作法について示す。

Boost.Coroutineライブラリの微調整についても触れる。

Boost.Contextがマージされたら、CoroutineをContextで再実装するつもりである。これこそまさにContextがサポートしようとしている種類のライブラリである。

C++11でのメタプログラミング

C++11で導入された新機能で、メタプログラマの世界は変化した。このプレゼンテーションでは、C++11メタプログラムをどう記述するかについての研究結果と、特にこの新しい言語にあわせたBoost.MPLの設計について述べる。

メタプログラミングの数学的問題への適用

ルンゲ=クッタ法と呼ばれるメソッドの高速かつ汎用的な実装をつくるために、現代的テンプレートメタプログラミングの手法をつかう。ルンゲ=クッタ法は常微分方程式(ODE: Ordinary Differential Equation)の初期値問題の近似解を探索する数値アルゴリズムである。常微分方程式を解くのは化学者、物理学者、生物学者にとっては日常のことである…

今日、異なる一連のパラメータ値をとり、近似解の精度が違う、様々なルンゲ=クッタ法が存在する。そこで、これらのルンゲ=クッタ法を汎用的に実装し、テンプレートメタプログラミングを利用することで、非常に汎用的な実装であるにもかかわらず、非常に高いパフォーマンスを達成した。これは数値計算アルゴリズムの領域においてもテンプレートメタプログラミングの力を印象づける事例である。

TR2に向けたBoostライブラリ

C++標準委員会のLibrary Working Group(LWG)は新しいライブラリの技術報告、TR2に向けたライブラリ提案を待っている。開発者以外の方でも、BoostライブラリをTR2に提案できる。

このセッションはまず、TR2にBoost ライブラリをうまく提案し、委員会を通して提案を導いていく方法についてのチュートリアルから入る。話す予定のトピックは以下の通り：

  • どうしてわざわざこんなことを - 経験から得られるもの
  • 標準化プロセスの概略
  • 提案募集
  • 委員会ウェブサイトの案内
  • システム - 提案はどのようなものか、 いつどこで提出するのか
  • 初期の提案 - 何を詳細に見て、何を詳細に見るべきではないかについて - 演習つき
  • 提案の用語と標準の記述
  • ドラフトとレヴューを手伝ってもらう
  • 提案提出 - のるかそるか
  • 委員会からのフィードバックへの対応

セッションの後ろ半分はTR2にむけて実際にBoostライブラリの提案を一緒にやるワークショップを開く。まず提案のテンプレートの空欄を埋めていくところから始める。このワークショップにはLWGメンバが何人かいらっしゃるので、彼らに助言をもらったり、意見を聞いたりするといいだろう。

どうしてそう書くの？なんで？

Boost委員会の方々(まだ未定。だが以前のBoostConで参加していただける旨をうかがった方の暫定リストはある)に、日々のコーディングで従っている原則について、なぜこの原則を適用していうのか、どのあたりに価値があると思っているかについて説明していただこうと思う。

(例えば、私は、なぜ自分の好きなコミットワードが'otherwise'なのか、以前聞いたり読んだりされているかもしれないが、これに関連するどのようなアドヴァイスがあるか、この天啓に至った事件は何かを説明するつもりだ) このプレゼンテーションの目的は、現実世界の話を時として書籍や講義で語られる高尚な理念に引き上げることである。

C++Now! 2013に向けた準備

来年の会合の準備委員会は早期に動きだす。提案があったり、支援していただける方はぜひご参加いただきたい。

WinRTにむけたC++コンポーネント拡張

C++は他のプログラミング言語やテクノロジー(例えば、 iOSのObjective-C、AndroidのJava、Windowsの.NETなど)を適用するプラットフォームにおいても活用されている。異種プログラミングプロジェクトがもたらす課題の一つに、C++の外部オブジェクトモデルとの結合という要求がある。CORBAやCOMといった既存の方法は一定の成功を収めているが、開発者は複雑性の増大というツケを払う羽目になる。

このプレゼンテーションでは、この問題に対処するために、Microsoftが取った二つのアプローチの詳細について述べる。最初のアプローチは、同じアプリケーションの中に、C++と非C++コンポーネント(外部オブジェクトモデル)が 混在するという複雑性に対処するためにC++抽象化レイヤを採用するというものである。この抽象化レイヤ(例えば Boostユーザーや開発者の方々にはおなじみの今日的C++テクニックをがっつり使ったWRLライブラリとか)はCOMコンポーネントの実装を単純化したが、このソリューションにある一般概念は他のいかなる異種混在環境においても拡張可能である。二つ目のアプローチは、異種言語で記述されたピア(訳註： 同格のコンポーネント)とやりとりするコンポーネントの宣言と定義ができるように、その構文にいくつかの拡張を追加して、C++自身の境界を押し上げることである。

このプレゼンテーションではこれら二つのアプローチについて、長所と短所、利点と注意事項についてそれぞれ説明していく。最後に、これらの設計が、C++の進化にとって潜在的にどのような影響を与えるかについてお話しする。

値のセマンティクスとConceptベースの多態

プレゼンターであるSeanは先のキーノートの "Now What? A vignette in 3 parts." で話した値のセマンティクスとConceptベースの多態コンセプトについて、更に深めていくつもりである。

Boostの将来

BoostとC++Now!の発起人であるお三方が将来について語り、どう考えているのかお答えする。

翻訳

Akira Takahashi、zak、DigitalGhost