Boost.Moveが採択されました。

Boost.Move Review Results


以下、レビューレポートです。


Ion GaztanagasのBoost.Moveライブラリは2010/05/10から2010/05/24の間にレビューが行われた。
オリジナルのレビューマネージャーは、その後行方不明になったOvermindDL1であった。
11人の個人(Eleven individuals...訳注:個別の11人に掛けてるのかなぁ)が作者と議論を交えた。
以下の6つのレビューが提出された:

  • 5 reviews ACCEPT(採択)
  • 1 review CONDITIONALLY ACCEPT(条件付き採択)

Ionは、コミュニティ投票の「条件付きの必要条件」を容易に満たせるということを示した:

Boost.Move library ACCEPTED



【概要】

Boost.Moveライブラリは、boostコレクションに強く期待された拡張である。主要な動機は、「C++0xC++03のコンパイラ間の汎用的な構文」に使用可能なムーブセマンティクスを導入することである。しかし、Vicente Botetが明言するように、「ほとんどの人々は、これがエミュレーションライブラリであると考えるが、これは多くのC++0xムーブセマンティクスクラスおよび関数の最高の実装以上である。」


レビュアーコメント:

  • 「このライブラリはだいぶ待たされた!」 Terry Golubiewski
  • 「チュートリアルがよく書かれている。」 Vicente Botet
  • Adobeベースのムーブの実装と比較して、私はこちらのほうが優れていると思う。」 Daniel James
  • 「ムーブエミュレーション作用を作る際には多くの創意があり、また、Ionはそれをを非常にアクセスしやすくしC++03とC++0x間の差をマクロとフリー関数の背後に消し去った。」 Jeff Hellrung


以下の活発な議論があった:

  • boost::rvを公開すること
  • 完全にboost::rvの要件を定義するという長所
  • MPLとType Traitsで見つかった重複する機能
  • 2つのエミュレーションモードの必要性
  • マクロの長所
  • Boost.Moveライブラリ作者による用途
  • 例外を投げないムーブコンストラクタ
  • 潜在的に有用な、様々なType Traits
  • 他のムーブ実装


タイムリーにレビュー結果が公表されなかったのは不運だが、それはライブラリの実際のユーザーに対して、レビュー中に投げかけられた関心事のいくつかについて議論する機会を提供した。


ひとつの関心事は、「2つのエミュレーションモード」だった。議論のポイントは、「安全(Safe) vs 速度(Fast)」として分類された。先入観で言えば優先されるのは「安全」だろうが、実際のユーザーのより進んだ調査と研究では、「速い」バージョンがデフォルトとして完全に受け入れられることを示した。さらに「安全」は、他のものより安全ではないという点で、誤った名称である。各モードの利点は、ドキュメンテーションとレビューのレスポンスでIonが全て行うのは限界があった。過去6ヶ月の使用により、Ionが好んでいた「速い」バージョンをデフォルトにすることが実際上良い決定であることがわかった。


すばらしい提起をおこなってくれたIonに感謝する。


さらなるBoostのために時間とエネルギーを費やしてくれたレビュアーに感謝する。提出されたライブラリのレビューに献身してくれる人々なしでは、全課程やBoost自身がばらばらになっていただろう。


コミュニティーは、あなたがた各自がこのライブラリに注ぐ労力から利益を得るだろう。


Best regards -
Michael Caisse


【変更まとめ】

レビューによる議論に基づいて、以下の変更が予定されている:


条件付き採択

  • 「2つのエミュレーションモード(Tow Emulation Mode)」ドキュメントの誤字が解決されなければならない。説明、要件および制限は、エンドユーザーにとって完全に明確である必要がある。


他の問題

  • クラスrvはpublicかつドキュメント化されるべきである。
  • is_movableはリネームされるべきであり、ドキュメントを明確にするべきである。これは単にC++03でenableになるだけである。has_move_emulation_enabledのような代替名が可能である。
  • レビュアーはほぼみな、Moveライブラリが、MPLとType Traitsの既存の機能を使うべきだと言った。一方で、これはMoveと他のライブラリの間の依存を作っているが、それは採択され、よくテストされたライブラリの再利用という結論に至った。非結合オプションも提供する場合、それはデフォルトであるべきではない。
  • 追加のtraitsに関して議論された。結論:実用的なユースケースが見つかったものをType Traitsライブラリに加える。
  • boost/move/move.hppをインクルードするboost/move.hppを提供する。
  • 2つのエミュレーションモードの相互作用をドキュメント化する。
  • コンテナをムーブ可能(movable)にするための例を含める。
  • 2つのエミュレーションモード - Ionは、レビュアーが単一のモードに帰着する一定の見解を持つだろうと期待していた。ドキュメント中のIonによって識別されたトレードオフは、全てのレビュアーに明白だった。しかし異なる結論が引き出され、合意は得られなかった。コントロールの細分性はほぼ全てのレビュアーとの共通の問題だった。したがって、両方のエミュレーションモードを維持し、デフォルトおよびコントロールの細分性として、マクロが提供するより多くのローカルレベル(クラスレベル)によって最適化できるようにする。
  • emulation_limitations.html: s/overaloading/overloading/
  • enable_ifは完全修飾する ::boost::enable_if
  • forwardの最適化されたバージョンはidentityを使用するべきである。そのため、それはTを推論しないだろう。
  • 必要なヘッダがチュートリアルで言及されていることを確認すること。
  • is_movableでis_classを使用する:
template<  class T>
struct is_movable
    : mpl::and_< is_class<T>,
                 mpl::not_< is_rvalue_reference<T> >,
                 is_convertible< T, rv<T>& > >
     {};

もしくは、参照に関するis_movable問題の別の解決策。

  • ムーブコンストラクタでの例外に関する標準の振る舞いに、Ionは追従しなければならない。これはパフォーマンス最適化であることから、初期のリリースに再訪することができる。