11

clear()今日ハッキングをしていて、 std::priority_queue にメンバー関数がないことがわかりました。標準化委員会がこれを除外した理由について、技術的な理由はありますか?

明確にするために、割り当てを使用してこれを簡単に回避できることを認識しています。

oldPQ = std::priority_queue<int>{};

このソリューションは、次の理由であまり望ましくありません。

  1. タイプを繰り返す必要があります - これはメンテナンス中は機能しません。以下で @chris が指摘したように、デフォルトのコンストラクターを使用している場合はこれを単純化できますが、カスタム コンパレーターを使用している場合、これは不可能な場合があります。
  2. std::priority_queueclear()メンバー関数を期待するテンプレート化された関数では使用できません。
  3. 一般に、他のコンテナが提供する共通のインターフェースを満たさないことは望ましくありません。特に から までのすべてstd::forward_listにstd::unordered_mapがstd::stringありclear()ます。私が注目している他の唯一の例外は、セマンティクスが意味をなさない std::array と、std::stack余分な労力なしで動作するstd::queue場合、セマンティクスがより疑わしい とです。std::deque

問題のように見えますが、実際にはそうである必要はありません: に使用される内部コンテナーstd::priority_queueはテンプレート化されておりclear()、独自のメンバー関数を持たない可能性があるため、興味深い問題が発生します。特に、下位互換性の問題が発生します。 . 次の理由により、これは問題ではありません。

  1. を提供しない内部コンテナの場合clear()、だれも を呼び出そうとしない限りstd::priority_queue::clear()、コードはコンパイルを続けます。
  2. SFINAE では、clear()利用可能な場合は内部コンテナーを呼び出し、利用できない場合は繰り返しポップすることで、新しいインターフェイス (クリア メンバー) を提供することがまだ可能です。

これは C++ 標準の欠陥であるというのが私の意見です。技術的な議論が、なぜこの方法が省略されているかについての強い根拠を提供しないと仮定すると、私は標準案の作成を追求するつもりです.

編集：

これは委員会で処理されているようです (最後の投稿に注意してください): https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-discussion/clear/std-discussion/_mYobAFBOrM /ty-2347w1T4J

http://wg21.cmeerw.net/lwg/issue2194

4

1 に答える 1

6

コンテナ アダプタの仕様は、過度に衒学的であることが知られています。対応するデータ構造の「抽象」仕様 (抽象アルゴリズムとデータ構造に関する本から) には、正規の優先度キューまたはスタックのクリア操作が含まれていないため、提供されていません。アダプターで。これにより、これらのアダプターを実際に使用することが非常に不便になることがよくあります。

ただし、良いニュースは、内側のコンテナー メンバーが、アダプター内で という名前のアダプターの保護されcたメンバーとして宣言されていることです。これはおそらく、標準アダプターから継承し、clear.

これらのアダプターのインターフェースを標準のコンテナー インターフェースと比較することに関しては、有効な比較ではないと思います。これらのアダプターは、インターフェースに関してコンテナーとの互換性を意図したものではありません。まったく逆に、これらのアダプターの目的は主に、データ構造のパブリック インターフェイスを制限し、標準的な抽象定義によって許可されている狭い範囲に強制することでした。

たとえば、標準スタックを反復処理することはできません。定義上、スタックは「反復可能」ではありません。スタック アダプターが反復インターフェイスを無効にするという事実は、良いことです。しかし、clear標準的なインターフェイスの大きな違反のように見えずに実用的な価値があるため、の欠如は確かにあまりにも衒学的に感じます.

于 2013-10-03T18:47:45.290 に答える