2009 年 7 月にフランクフルトで開催された C++0x 会議で、C++0x から概念を削除することが決定されました。個人的にはがっかりしていますが、C++0x がないよりは実装可能な C++0x の方がいいと思います。後日追加されるとのことでした。
この決定/問題についてどう思いますか? それはあなたにどのように影響しますか？
質問する
1065 次
9 に答える
8
個人的には、概念の目的は主にコンパイル時のエラー メッセージを改善することだったので、削除にそれほど不満はありません。概念提案の共著者の 1 人である Jeremy Siek は次のように書いています ( http://lambda-the-ultimate .org/node/3518#comment-50071 ):
Concepts の提案は完璧ではありませんでしたが (C++ の拡張は本当に完璧でしょうか?)、非常に使いやすく役立つ拡張機能を言語に提供し、テンプレート ライブラリの現在のユーザーが直面する悪名高いエラー メッセージを大幅に削減する拡張機能を提供できたはずです。に悩まされています。
もちろん、コンセプトには、コンパイラーがより短いエラー メッセージを表示できるようにする以上の目的がありました。
編集: Herb Sutter も彼のブログに書いています:
Q: これは C++0x の大きな特徴の 1 つではありませんか?
A: いいえ。概念は素晴らしいものですが、ほとんどのユーザーにとって、概念の有無は、エラー メッセージの品質を除いて、C++0x での経験に違いはありません。
Q: 主要な新しい表現力を言語に追加し、主要な新しい種類のプログラムまたはプログラミング スタイルを可能にするという概念ではありませんか?
A: そうではありません。概念は、ほぼ完全に、より良いエラー メッセージを取得することに関するものです。
于 2009-07-22T07:51:26.453 に答える
6
私は彼らを楽しみにしていました。主に、コンパイルが失敗したときのエラー報告を改善するためです。1000 文字の文字列を読んで自分の愚かな間違いを見つけるのに勝るものはありません。
于 2009-07-20T18:01:32.573 に答える
4
彼らがリストから外れるのを見るのは悲しい。
個人的には、プリミティブ、構造体、クラスなど、既知のインターフェイスに従うために使用する型が好きです。このようにして、型を使用する方法と、型を提供するために実装する必要があるものを知ることができます。
これはすべて、標準のオブジェクト指向プログラミングで簡単に実現できます。ただし、私の意見では、技術的にジェネリック プログラミングは強く型付けされていますが、型付けが OO を提供するというインターフェイスの概念が失われています。実際、ジェネリック プログラミングは動的型付けに似ていますが、インターフェイスの観点からはコンパイル時に解決されます。
たとえば、いくつかの演算子を提供する必要があるアルゴリズムに反復子を渡しますが、それらの演算子が何をすべきか、またはそれらのコントラクトが何であるかを指定するインターフェイスはありません (ドキュメントのみ)。あなたが持っていてoperator++()、operator*()それはコンパイルされますが、インターフェースがOOであなたに与えるのと同じ型保証をあなたに与えません。
私にとって、概念はジェネリック プログラミングに型をもたらし、確実なインターフェイスは OO にもたらします。より良いコンパイルは単なるおまけです。
私たちは皆 C++ プログラマーであり、非常に賢く、ドキュメントを読み、演算子のオーバーロードとジェネリック プログラミングの機微を理解しています。しかし、私が信頼できる保証を提供する言語と、コンパイラーがテストできる場合、私は解決するために支払われる問題を解決するために、より多くの頭脳を費やすことができます。
于 2009-07-22T11:34:30.777 に答える
2
私はまだコンセプトにあまり関わっていませんでした。しかし、私が気付いたのは、それらは一般的にかなり冗長であるということでした。STLライブラリには入れたくないと思います。ライブラリはすでに知っているので、コンパイル時のエラーを簡単に解析できます。コンセプトは必要ありません。ただし、概念は私自身のクラスを説明するのに適しているので、同僚はそれらをより早く学習し、誤用を避けることができます。それぞれの概念は、私が理解している限り、型の使用を制限する制約です。他の誰かが学ばなければならない新しいインターフェースを作成するとき、それは素晴らしいでしょう。
于 2009-07-21T20:30:32.640 に答える
1
悲しいです。
私はConceptGCCをチェックアウトしましたが、素晴らしいです! 私はすでにこれを使用していくつかの単純なライブラリを作成していますが、より多くのコードを作成したり、概念の抽象化の力を考えるのに苦労したりするなど、いくつかの欠点が見られます。std の概念ライブラリは本当に問題を起こすので、そのようなものを標準に含めることは単なる誤解です。今後の標準は、概念の文法を標準化し、それを使用する方法のヒントを提供するだけでよいと思います。
于 2009-07-29T21:42:43.613 に答える
1
彼らは正しい決断をしたと思います。言語に概念の高品質な実装が追加されるのを楽しみにしていますが、仕様は間違った方向に向かっており、ユーザーに概念マップを明示的に指定する負担がかかりすぎていました。Stroustrup の論文はこれに対するいくつかの修正を提案していましたが、それはプロセスのかなり遅い段階でかなり急進的な変更になると思います。そして、それをテストするコンパイラがありません。
要約すると、最後に指定された概念は、大きな後退であり、ジェネリック プログラミングを妨げ、C++ コミュニティを分裂させる可能性があり、多くのプログラマーが C++03 に固執していました。
Stroustrup によって「修正された」と提案された概念は、私が見る限りでは問題ありませんでしたが、これらの変更をすぐに採用するのは危険です。（そして、それがさらに遅れを引き起こさなかったとは確信していません。）
正直なところ、彼らが安全にプレイし、今のところそれらを削除したことを嬉しく思います. 今までコンセプトなしで生きてきたけど、あと5年はコンセプトなしで生きていける。
于 2009-07-24T19:04:18.257 に答える
1
それは非常に悲しいです。概念を C++ に持ち込むと、その型システムは Haskell の型クラスとほぼ同じレベルのパワーになります。これは素晴らしいことでした。速度を最適化して、やりたいことを何でもできる言語でありながら、エスケープ ベントを使用しない限り厳密にタイプセーフな言語です。 （まだ速いままです！）。また、C++03 テンプレートの「コンパイル時のダック タイピング」の性質が緩いため、STL と Boost (および一般的なテンプレート ライブラリ) が使いにくいという長年の問題と、それに伴うコンパイラの問題を修正することも想定されていました。エラー報告。
于 2009-07-24T19:24:59.743 に答える
1
私もこれは悪いC++0x判断であり、それは削除にとってさらに悪いことだと思っていましたが、Stroustrup のSimplifying the use of Conceptsを読み終えたばかりで考えが変わりました。概念の提案がそれほど複雑だとは思いもしませんでした。言語に追加する前によく考えられるのは良いことだと思います。Stroustrup は概念を維持するように説教していますが、彼の記事は、現在の状況では、概念は良いことよりも害を及ぼすものであると私に確信させました。
于 2009-07-29T11:30:12.027 に答える
1
私はコンセプトがとても好きです！非常に異なる型を外部定義 (概念マッピング) によって同じように動作させる可能性は、非常に強力で便利な機能です (特に、コンパイル時に発生するため、実行時のパフォーマンスには影響しません)。
すべての便利な機能を型に直接実装し、.NET のようにインターフェイス経由でそれらにアクセスするよりも、さらに強力で優れていると思います。これは後で拡張性を許可しません (わかりました、.NET は 3.0 (または 3.5、確かではありません) 以降の拡張メソッドを認識していますが、同じではありません)。
エラー メッセージの改善は、コンセプトがもたらすもう 1 つの (そして元の) 大きな改善です。
しかし、概念について読んだときの私の最初の考えの 1 つは、GCC と MSVC がサポートするまでに非常に長い時間がかかるということでした。
したがって、今後の標準から削除することは理にかなっていると思います。しかし、私が望むのは、概念を含むC++ 0x標準以降の機能の固定協定です。これにより、コンパイラ ベンダーは C++2x 標準への準備をより適切に行うことができます。
ですから、そう遠くない将来にコンセプトが登場することを心から願っています。
于 2009-07-22T19:57:31.977 に答える