c++ - C++0X の概念はなくなりました。他にどの機能を追加する必要がありますか?

Question

聞いたことがあるかもしれませんが、C++ 標準委員会の前回の会議では、次の C++ 標準から概念を削除することが投票されました。もちろん、これは他の機能に影響を与え、標準が再び大きく開かれるように思われます。その場合、他にどの機能を削除 (または追加) する必要があると思いますか? また、その理由は何ですか?

リンク:

概念の削除-- Danny Kalev (概念を削除する決定について)

Simplifying the use of Concepts -- Bjarne Stroustrup (現在の概念の問題について)

The Long Pole Gets Longer -- Martin Tasker (概念を修正する必要がある場合の C++0x のスケジュールへの影響について)

C++0x の "Remove Concepts" 決定- Dobbs 博士の問題に関する Stroustrup

旅行レポート: コンセプトの終了、約 18 か月で最終的な ISO C++ ドラフト- Herb Sutter

コンセプトは C++0x アイランドから投票される - 現在のコンセプト仕様を擁護するジェレミー・シーク

フランクフルトで何が起きた？- C++Next の Doug Gregor (コンセプトの歴史と削除について)。

score 27 · Accepted Answer

もちろん、これは他の機能に影響を与え、標準が再び大きく開かれるように思われます。

しそうにない。彼らはまだ標準をすぐにまとめたいと考えており、これが概念を削除する主な理由の 1 つです。無関係な変更に対して「広くオープン」にすることは、概念を捨てることによって得たすべてを捨てるだけです。

とにかく....残りの C++0x の追加のうち、他に削除したいものは思い浮かびません。ただし、コンセプトに関する彼らの決定には同意します。Stroustrup の論文は実際にいくつかの深刻な問題を概説しています。概念の現在の仕様は、テンプレートエラーメッセージを単純化することは認められていますが、ジェネリックプログラミングの有用性を劇的に低下させることになります。

私が最初にその論文を読んだとき、仕様に重大な変更を加えるには遅すぎると思ったので、私は怖くなりました。そうではなかったことが判明し、委員会は劇的な行動をとることをいとわなかった.

しかし、それを除けば、C++0x は良い状態だと思います。残りの新機能はすべて一見の価値があります。

もちろん、削除したい既存の機能はたくさんあります。主にvector<bool>専攻。うまくいかなかった機能の一般的な例は他にもありますが (export キーワード、例外仕様)、無視できないのはベクトルの特殊化だけです。テンプレートをエクスポートしようとしない限り、キーワードが存在する (そしてコンパイラによって実装されていない) ことは問題ではなく、例外仕様の使用を控えることができますが、ブール値のベクトルが必要になるたびに、現在の標準に滑り込んだ愚かな時期尚早の最適化に悩まされています。

残念ながら、彼らはそれを取り除くことをあきらめたようです. （最後に確認したところ、廃止されていませんでした）。

もちろん、多くの古い C クラフトも捨てられる可能性がありますが、最近、私が本当に見たい変更の 1 つは、Iostreams ライブラリを捨てることであることがわかりました。それを捨てて、ジェネリックプログラミングに基づいて新しいSTLスタイルのI / Oライブラリを構築してください。

現在の OOP スタイルの Iostream ライブラリは、醜く、遅く、複雑すぎて、柔軟性に欠けています。新しいストリームの定義に関わるブードゥー教が多すぎ、含まれる標準ストリームタイプが少なすぎ、柔軟性が少なすぎます (ライブラリがいかに制限されているかを認識させた問題は、文字列から float を抽出する必要があることでした。stringstream で簡単に実行できます。、しかし、頻繁に行う必要がある場合は、入力文字列を毎回コピーする必要はありません (stringstream のように) -- 既存のイテレータ範囲で動作するストリームはどこですか? または生の配列ですか? )

IOstream を捨てて、最新の代替品を開発すれば、C++ は大幅に改善されます。

そしておそらく、文字列クラスについても何かをするでしょう。これは今のところ問題なく動作しますが、実際のところ、膨大な数のメンバー関数はどうなっているのでしょうか? それらのほとんどは、フリー関数としてより適切に機能し、より一般的になります。標準ライブラリの多くは、文字列クラスに特に依存していますが、原則として、任意のコンテナー、またはイテレーター ( std::getline、私はあなたを見ています) でさえも機能します。

score 10 · Accepted Answer

個人的には、C++ が最終的に C から離れることを望んでいます。プリプロセッサもヘッダーファイルも必要ありません。私は基本的に D が欲しいのですが、STL を使用して、D が追加するすべてのものは必要ありません。

score 5 · Accepted Answer

C++0x に追加する必要があると思われることが 2 つあります。私はこれらの両方を自分で考えましたが、他の人が以前にそれらを提案していることに気付きましたが、実現するようには見えません。

1. Move コンストラクターと Move 代入演算子のデフォルト設定

移動コンストラクターの作成は手動でエラーが発生しやすい作業です。メンバーを追加する場合は、移動コンストラクターと代入演算子に追加する必要があり、std::move宗教的に使用する必要があります。そういうわけで、これらの関数は defaultable であるべきだと思います。

movable(movable&&) = default;
movable& operator=(movable&&) = default;

編集 (2009-10-01):結局、これが起こるように見えます。

2. 式テンプレートの型推論をオーバーライドする

式テンプレートは、直接使用してはならない型を定義することがよくあります。適切なケースはの戻り値ですstd::vector<bool> operator[](size_type n)auto。またはがこの種のオブジェクトで使用されている場合、decltype予期しない動作が発生する可能性があります。したがって、タイプは、それがどのタイプであると推定されるべきかを言うことができる必要があります(または構文を使用して推定を防ぎ= deleteます)。

ベクトル加算の例。

// lazy evaluation of vector addition
template<typename T, class V1, class V2>
class vector_add {
     V1& lhs_;
     V2& rhs_;
public:
     T operator[](size_t n) const
     { return lhs_[n] + rhs_[n]; }
     // If used by auto or decltype perform eager creation of vector 
     std::vector<T> operator auto() const 
     {
         if (lhs_.size() != rhs_.size()) 
             throw std::exception("Vectors aren't same size");
         std::vector<T> vec;
         vec.reserve(lhs_.size());
         for (int i = 0; i < lhs_.size(); ++i)
            vec.push_back(lhs_[i] + rhs_[i]);
         return vec;
     }

score 5 · Accepted Answer

ドラフトの残りの部分は素晴らしかったと思います。独立して正しく実装できる非常に小さな部分が多数あり、ベンダーが完全なサポートに向けて進化し、ユーザーが「ショッピングリスト」アプローチを取ることができます。

コントラクトはまったく新しい並列型システムのようなものであり、Web ブラウザーの CSS と非常によく似た、独自の後方互換性の問題で終わるさまざまなコンパイラーにつながる可能性が非常に高かったため、コントラクトの状況はまったく異なります。

score 3 · Accepted Answer

私にとって問題は、他のどの機能を削除する必要があるかではなく、概念が削除された後に他の機能がどれほど複雑になるかです。それと、残りの機能を概念なしで言い換えるには、どれくらいの時間がかかりますか.

多くの機能は、概念が言語に受け入れられることを想定しており、言葉遣いは概念の観点から表現されています。(提案された機能が概念に依存するかどうかは疑問です)。

また、他のライブラリがどのように進化し (boost::type_traits を考えてください)、概念によって残されたニッチを獲得するのかも気になります。提供される概念の一部は、型引数に適用される特性に関して (より面倒な方法であっても) 実装できます。

私にとって、概念が言語に追加した最も重要なことは、コンパイルエラーの表現力豊かな定式化でした。これは、今日 C++ が最も批判される場所の 1 つです。

RIP の概念。

score 2 · Accepted Answer

コンセプトについては好きなようにできますが、スレッドとアトミックは保持しておいてください。それらは絶対に必要です。おそらく、スレッドグループを追加し、協調スレッド (ファイバー) のサポートを追加します。IMO は、誰もがスレッドを使用している/すぐに使用するため、概念よりもはるかに重要です。

score 1 · Accepted Answer

テンプレートコードのエラーメッセージのページを取り除きます！

IIRCの概念は、C++コーダーの大きな問題であるSTLの人間が読める形式のエラーメッセージを解決する必要があります。この問題が解決されていないという悪いニュース。

score 1 · Accepted Answer

削除したい=deleteです。

同じ効果を達成するための一般的で受け入れられているイディオムが既にあります (問題の関数をプライベートとして宣言します)。=deleteこの機能により、「以前は派生クラスから基底クラス関数を削除していましたが、基底クラスポインターを使用して呼び出すことができます」という質問が多数生成されると思います。

deleteキーワードの (現在の) 2 つの意味の間で人々を混乱させることは言うまでもありません。

score 0 · Accepted Answer

名前のない関数/ラムダ関数のものは私を緊張させます。関数オブジェクトは完全に優れており、明示的であるため、読みやすく、見つけやすくなっています。

一方で、私は概念が好きでしたが、毎日それらを使用することはありませんでした.

c++ - C++0X の概念はなくなりました。他にどの機能を追加する必要がありますか?

9 に答える 9

Related

Reference