多倍長整数のためのライブラリであるBoost.XIntが、長い議論の末、今回は採択されないことが決定しました。作者であるChad Nelsonは、レビューで指摘された点を夏までには修正すると言っているので、そう遠くないうちに再度レビューのために提出されるでしょう。
以下、レビュー結果です。
集計ミスがあったようなので、票数に関してはここでは記載しません。
ハイレベルな問題
==
- このライブラリが「速い(fast)」という主張は正しくない。Philはアセンブラレベルでのチェックを行った。
- 設計が、特殊化によって固定サイズ整数のパフォーマンスを改善することを可能にするかどうかが明確ではない(Philのコメントを参照)。
- COWについての懸念があった。もしCOWが使われるのであれば、マルチスレッドでも正しく動作しなければならない。
- Expression Templateの使用が提案された。
- 何人かは、アルゴリズムとデータ表現のより良い分離について提案した。
仕様上の問題
==
- "a + b + c"が大量の一時オブジェクトを生成することが指摘された。これはETを使うことなく改善できる。
- Joachimのレビューは、多くの有効な点を挙げた。(中略) 通常、我々は特定のコーディングスタイルを強制はしないが、このコードが誰かに読まれることを期待しているのであれば、受け入れられない。
- Secureフラグはおそらく、そんなに多くはないだろう。
将来の方向性
==
PhilとJoachimのレビューが、Boost.XIntの方向性を決める上で最も重要であると私は考える。
Chadは、彼の計画についてのコメントを作成した：
結論
==
私は、このドメインが重要であることと、Chadがこのライブラリに多くをつぎ込んだことは疑いないと考える。Boostの周辺に多くの多倍長整数ライブラリがあることは、長い間指摘されてきたことだったので、このようなライブラリのレビューができたことは重大な成果だ。そして、このレビューの中で、誰もが多くのことを学ぶことができた。
レビューは、外部インタフェースとライブラリのスコープを中心に行うべきだが、今回のレビューの中では、いくつかのメタなポイントが議論された。
何人かのレビュアーは、外部インタフェースだけが重要だと主張した。しかし、私はレビューマネージャとして、内部の設計に対する懸念は有効で、即座にリジェクトはできないように思う。つまるところ、整数ライブラリの外部インタフェースは数学によって多少定義されるが、内部の設計はライブラリの進化において重要な役割を持つのだ。
また、固定幅整数特有のサポートに関して、ライブラリのスコープの熱い議論があった。
私は、このライブラリが固定幅整数をsecond classと見なすことが、抽象化的に良いのではないかと思う。しかし、このライブラリの意図するスコープを決定するのは困難だった。
もし私が暗号化を行うとすれば、本に載っている暗号アルゴリズムを、私は本当にBoost.XIntを使って実装したい。既存の実装の(しばしばOSに含まれる)バグを修正するだけで導入できるだろう。そして、そうすることに本当に熱心であれば、私はSSE 2011やCUDA、その他の最先端テクノロジーを用いた最適化されたバックエンドのプラグインを導入する方法を含む、生のパフォーマンスが欲しいだろう。
たしかに、レビュー中にスコープを改善／改良し、そのスコープ全てのために最適化し、提案に対応した優れたBoostライブラリを作ることは可能だ。しかし、多くの提案と再設計の計画と変更があり、我々はこのライブラリを二度見る必要がある。さらに、変更のグローバルな性質のため、改善されてからミニレビューを通らなければならない具体的なサブセットを特定するのは困難だ。こういった理由から、以下の結果に帰着した：
Boost.XIntは、この時点では採択しない。
次のバージョンの準備ができたときに再び完全なレビューができれば幸いだ。
ライブラリを提出してくれたChad、そしてレビューに参加した全ての方に感謝する！
