Stephan T. Lavavej: Data Structure Visualizers in Visual Studio 2010
多くのSTLクラスが説明を複雑にしました。
デバッグをより簡単にするために、Visual Studio 2005と2008は、
人間が読めるようにSTLオブジェクトを表示する「Visualizer」を持っていました。
誰でも、Boostクラスのような他の型のためのVisualizerを書くことができます。
これはアンドキュメントで、サポートもされませんが、非常に有用になりえます。
この発表は、shared_ptr、functionおよびmapの表示を改善するために
Visualizerを書く方法について説明し、Visual Studio 2010の新しい特徴を利用する方法を紹介します。
Joachim Faulhaber: Boost.Alabaster: A Law Based Tester
これは、形式的に規定された法則あるいは公理に基づいて
自動テストを提供する、Boostライブラリのための提案です。
テストシステムは3部から成ります
法則のインスタンス化変数を表わす型の並び上の
クラステンプレートとして公理または法則を表現することを可能にする法則概念。
与えられた法則と与えられた型の並び用の法則インスタンス化を任意に生成する、
法則インスタンス用のジェネレーター。
法則違反を選択し、単純性順序によってそれらを格納するフィルタ。
Boost Interval Containerライブラリの開発のために、
Boost.Alabasterのプロトタイプは法則に基づいた開発(law based development)に使用されました。
手法とツールとしての法則に基づいたテスト(law based testing)は、
多くの面で有益であることが判明しました:
形式仕様の探究はより深く根付いた設計決定を生じさせ、より耐久性のある設計に結びつきます。
進化のプロセスでは、一般的なソフトウェアに関してあなたが即座に作った公理で
開発を始められなかったとしても、ソフトウェア開発(法則のテスト)では前部(仕様)が
抽象化と抽象推論を引っ張り出します。
法則に基づいた開発プロセスは、ソフトウェアだけでなく
そのソフトウェアに関して保証することができる形式上のプロパティももたらします。
それらのプロパティの検証はいつでも繰り返す(replicate)ことができます。
テストは、退屈で愛されなかった義務から
抽象と設計の品質を促進する非常にクリエイティブなプロセスへと変形されます。
法則に基づいたテストは、従来の単体テストが提示することができる利点をすべて持ち、それを超える方法です。
Douglas Gregor: C++ Tool-Builders Workshop
多くの専門家のように、プログラマは、生産性を改善する様々なツールを使用し、
プロジェクト特有のニーズに焦点を当てた自分のツールを作るでしょう。
不運にも、C++プログラマのために、よいC++ツールの構築は、
C++コードを解析する固有の複雑さによって非常に複雑になります。
C++の全てを解析することができるオープンソースライブラリの不足と結び付けられた
この複雑さは、C++ツールを他の言語でそれらに相当するものより劣らせていました。
Clang( http://clang.llvm.org )は、大きなC++開発ツールを構築することを
より簡単にすることによりこの不均衡に焦点を当てたサポートを意図した
新たなオープンソースC++コンパイラライブラリです。
このハンズオンワークショップでは、出席者は、新たなC++ツールを構築するために
Clangライブラリを使用する方法を学習するでしょう。
私たちはまず、C++プログラムを解析および識別する面白いプログラム構築から始めるでしょう。
そこから私たちは、その抽象構文ツリーによって
語彙の構造(トークン、マクロのインスタンス化など)から
意味的な構造(クラス、関数、式、テンプレートなど)まで
Clangがどのようにプログラムを表わすかを知るでしょう。
最後に、私たちは手を汚して、Clangを使用して、あるC++ツールを構築するでしょう。
私たちが構築する実際のツールは出席者によって決定されるでしょう。
しかし、可能性は以下のものを含んでいます:
プロジェクト絶対コーディング標準、
特定のオーバーロードが選ばれた理由の説明、
クラスを自動的に生成するシリアライズコード、
Boostライブラリから抽出するドキュメンテーション、
あるいは、対話的にテンプレートやプリプロセッサのメタプログラムをデバッグする
といったものを強化します。
プログラム委員会は以下のことに注意します:
私は、Clangに基づいた2つの異なるセッションを提案しています。
90分の発表(「Clang: An Open-Source C++ Compiler Library」)は、
Clangをコンパイラ、ライブラリおよびオープンソースプロジェクトと評するでしょう:
これはあまり深く話せないので、実際には概要です。
ワークショップは、去年のDaveによるハンズオンBoost++0xワークショップに
沿った単なる実験ではありません:
今年、私たちは、出席者にBoosterが使用するべきクールなツールを
構築させることができるかどうか確かめたい。
Michael Wong: C++0x Concurrency
この話では、私はBoostCon 09でのC++0x並列性の議論に引き続いて話していくつもりです。
とくに、C++のメモリモデル、新たなC++0xライブラリを通じて並列性がどのように扱われるか、
スレッド管理、スレッド間のデータ共有、同期並列操作に関して話します。
Tony Van Eerd: Lock-freeプログラミングの基礎
基礎から始め、共有データにアクセスするという問題を示し、ゆっくり問題を露出させていき、
問題へのLock-freeによる解決策を示します。
この話は以下を含みます：
・原始性についての説明
・CAS命令とCASループについての説明
・Double-Checked-Locking Pattern(DCLP)の危険性とそれを避ける方法(メモリバリア)の説明
・read-request queueとwrite-request queueのアイデアに基づき、
どのように複数のCPUが働くか理解できるモデルを提示しメモリバリアを説明する
・Lock free stackを提示する
・ABAと、それを回避する方法についての説明
・Lock-freeプログラミング(楽観的なrelaxed memory operation)におけるいくつかの最前線開発に触れる
・BoostとC++0xがどのようにLock-freeプログラミングに影響するかについて触れる
Justin Gottschlich: TBoost.STMエンジン: コミット時無効化を使用したSoftware Transactional Memoryの効率化
ここでは、具体的なTBoost.STMの内部エンジンの現状、トランザクションコンフリクトの検出、
トランザクションがコミットできるかどうかを決定するプロセスを調べます。
多くのtransactional memory(TM)は矛盾検知の最適化に専念しますが、
ほぼ全てのTMがトランザクションのコミット段階で同じ矛盾検知戦略を行います。
つまり、彼らはコミット時に検証を行います。
そこでは、トランザクションが、以前にコミットされたトランザクションによってコンフリクトチェックされます。
コミット時検証(commit-time validation)が限られた競合を示す作業量に対して効率的な間、
それは競合した作業量のために並列性をきびしく制限できます。
ここでは、TBoost.STMがこのモデルからどう逸れるかを説明し、
コミット時無効化(commit-time invalidation)を使用することで
コミットする前に飛行中(コミットされていない)トランザクションが
それらのコンフリクトを全て解決する戦略について話します。
コミット時無効化は競合マネージャ(CM:contention manager)にコミット時検証を
通じて利用不可能なデータを供給し、CMが決定にBoost Concurrencyを作ることを可能にします。
コミット時無効化はまた、メモリ集約的なトランザクションのために
コミット時検証より著しく少ない操作を必要とし、
動的に検出されたread-onlyトランザクションのための操作と保証、
どんなトランザクションでもO(N)時間で完全な不透明性を保証します。
(インクリメンタルな検証のO(N^2)より速い)
作業量競合の実験結果は、私たちの効率的なコミット時無効化されたSTMは、
TL2(最高水準のSTM)より3倍速かった。
しかし、コミット時無効化だけでは不十分です。
プログラマはそれらがこの競合検出戦略の利点を完全に利用するために
実行している作業量のための効率的な競合マネージャに書く方法を知らなければなりません。
私たちは、プログラマがどのように自身の競合マネージャに書くか、
そして正しい競合マネージャが実行される作業量に基づくTBoost.STMの性能を
根本的にどうしたら向上させることができるかを調べます。
Michael Caisse: Using Spirit V2: Qi and Karma
機械、センサー、機材、クライアント/サーバーコミュニケーション、ファイル形式でさえ...
コミュニケーションストリームの解析と生成はどこでも見るでしょう。
多くの場合、これらのタスクはその場限りの解決策を勧めるのに十分に単純であるか、あるいは小さい。
Spirit 2.1ライブラリは、それらの「quick hacks」に取り組むのに十分に単純で、
AST生成のために容易に拡張できる十分な機能のモデルを提供します。
このセッションは、Spiritライブラリのパーサーとジェネレーター(Qi/Karma)による
現実の経験を調査します。
様々な製品の中で使用された、様々な小型/中型のパーサー/ジェネレーターを見るとともに、
私たちは「rules-of-thumb」、およびQi/Karmaを持ったパーサー/ジェネレータードメインに
取り組むためのガイドラインを確立するでしょう。
このセッションは、使用可能なXMLパーサーと、単純化されたXPathのようなノード抽出器の実装で終えるでしょう。
このセッションは、いくつかのレクチャーと、多くのチュートリアルを含みます。
出席者は、知識と、Spirit Qi/Karmaで解析し生成することを始めるツールを持ち帰るでしょう。
5/12(水)に続く。
修正履歴：
2010/2/14 22:22 「Using Spirit V2: Qi and Karma」を訳し直し。(間違って他のセッションを訳してました)
