BoostCon 2010 : 5/9〜5/10

http://www.boostcon.com/program


2010/5/9〜5/14に行われるBoost Con 2010のプログラムが公開されました。
概要を訳してますが(適度に端折ってます)、翻訳が全然追いつかないので小出しします。



5/9(日)

Conference registration and Sign-In '10

Informal Gathering at Meadows Bar '10 - Travelling companions welcome.

Boosterの知り合いを増やしましょう。



5/10(月)

General Conference Welcome

Douglas Gregor: Clang: オープンソースのC++コンパイラライブラリ

ClangはC系言語(C, C++, Objective-C)のオープンソースコンパイラフロントエンドだが、
再利用可能なC++ライブラリとして開発ツールを作るためのプラットフォームとしても使用できる。



Jeremy Siek: Generic ProgrammingとBoost Graph Library

グラフのアルゴリズムとデータ構造は、インターネットパケットルーティング、分子生物学
科学的なコンピューティング、電話ネットワーク設計などの多様な領域の問題を解決するが
伝統的なグラフライブラリ設計は、十分な柔軟性を提供することに失敗していた。
Boost Graph Library(BGL)はSTLをグラフドメインに適用し、
グラフ問題を解決するための非常に柔軟で効率的なライブラリとなった。


ただ、BGLは使うのが難しいので、このチュートリアルでは
プログラミングの基本原則を学び、それらがBGLでどう適用されるのかを学んでいきます。



Barend Gehrels, Bruno Lalande, Mateusz Loskot: Generic Programming for Geometry

Boost.Geometryの設計について(タグディスパッチ、TMP、特徴、コンセプトチェック)



Matt Calabrese, Zachary Laine: Instantiations Must Go!

BoostCon 2009では、メタ関数を簡単に書くための取り組みで変なことをしていたが、
あとで多くの専門家と話してそれが不可能であることがわかった。
一方、彼らは時々ゾッとするようなTMPのコードをより通常の関数プログラミングのようなコードで書き、
大部分のメタ関数のテンプレート定義(宣言ではない)をインスタンス化する必要性を
取り除くおもしろい手法を発見した。



Michael Wong: C++0x update

BoostCon 2009に引き続き、C++0xの新機能、最新ニュース、コンパイラの実装状況について



Ken Joyner: C++での例外使用に関するガイドラインの再考

例外安全なコードを書くことが挑戦的であることは有名です。
これは、多くの開発者に、例外の使用が避けられるべきであると結論させます。
しかし、この結論に関する問題は、開発者が例外を使わずにエラー安全な
コードを書くことがより簡単であると仮定しているということです。
私は、この仮定が間違っていると考えています。
その代わりに、私は実際には、多くの開発者がエラー安全なコードを
書くというわけではないと考えています。
そして、例外は発生するエラーを無視することは、より挑戦的になります。
(あなたのプログラムが未処理例外で終わるので処理しなければなりません)


エラー安全なコードを書くのは例外の使用のあるなしにかかわらずやりがいがあります。
そして、エラー安全なコードを書かないのは予測できない、不安定なコードをもたらします。


この論文は、(いくつかの修正をした)例外安全性のレベルを再文書化した例外安全推奨を提供します。
これは、会社や開発者が必要とする、安全性のレベルを達成するために従うべき
実質的なガイドラインの包括的なマニュアルとなります。
特定の推奨とともに例外を使用することで、エラー安全なコードを書くことを、
例外を使用することへの付加的な利益を加えるとともに、挑戦的なことをしないで済む
アシスタントライブラリを提供します。



Hartmut Kaiser, Joel de Guzman: RAD Spirit

従来のパーサージェネレータと比較したBoost Spiritパーサーの魅力は、
それがC++に埋め込まれることです。
ライブラリのユーザーは、C++コードにおいてExpression Templateを使ってパーサー文法を直接指定します。
このアプローチには利点もありますが、同時に問題もあります。


最も目に付く問題点は、
1.コンパイル時間が長い
2.エラーメッセージを理解するのが難しい
3.パーサーのデバッグとテストが難しい
という点です。


小さな構文解析については、これらは許容できます。
しかし、アクティブな開発の8年後、より複雑な構文解析の中で使用されるポイントに来ました。
2と3はどうにか、Protoを使用することで軽減できます。
しかしそれは、ライブラリがもはや役に立たない点にコンパイル時間を増大させます。


EBNF/PEG式を受け入れて、すぐに実行可能であるパーサーかC++ Boost Spiritコードを
出力するツールを持つことはおもしろいです。
RADツールは、パーサーを記述することをできるだけ容易にします。


私たちは、そのようなツールの設計と開発を示したい。
明らかに、この「動的なSpirit」ツールは「静止なSpirit」を使用して書かれるでしょう。
これはSpiritを使用した、本当に実用的な例になるでしょう。



Robert Ramey: Is Boost Broken?

Boostのいいところ
1.形式的なレビュープロセスによるライブラリ品質と完全性の「証明」
2.形式的なテスト、リリースプロセスの実施による信頼できる実装の「証明」


Boostは拡張性が高くない
1.テスト時間が長く、より長くなる・・・
2.有名でないコンパイラをテストすることは難しい
3.現在のテストはコンパイラ設定(RTTIのON/OFF、デバッグ/リリース、STLライブラリなど)の
 すべての可能な組み合わせを扱うことができるというわけではない
4.より多くのライブラリが追加されるとき、インストールが面倒で、壊れやすくなる
5.したがって、新規ユーザーがひとつのライブラリだけを使い始める場合でも、
 Boostを使うための「コスト」と「オーバーヘッド」は時間とともに増加する。
 しかし、ひとつのライブラリをテスト/使用するための方法がない。


Boostのアイデンティティの危機
1.コアユーティリティの唯一のライブラリ?
  i)ツールがテスト、リリース、配置を行う
  ii)ライブラリのサブセットのテスト、リリース、配置が必要であると考えられる
 iii)全てのライブラリのためのひとつのバージョンを振る

2.あるいは、独立、分離されたライブラリのグループ(現在大きい)?
 i)多く、あるいはほとんどのライブラリが他のBoostライブラリのサブセットにだけ依存する


私の議論は、Boostが前者として始まり、後者へ向かって進化していきそうだということです。


Boostにとってすばらしい10年でしたが、成功し続けるためには進化しなければならないでしょう。
この発表では、私が、Boostがどのように変わらなければならないと思うかを説明します。





5/11(火)に続く。