問題タブ [c++11]

m_MAXとask（）はrun（）によって使用されますが、それ以外の場合はパブリックにしないでください。これはどのように行うことができますか？

2009 年 7 月にフランクフルトで開催された C++0x 会議で、C++0x から概念を削除することが決定されました。個人的にはがっかりしていますが、C++0x がないよりは実装可能な C++0x の方がいいと思います。後日追加されるとのことでした。

この決定/問題についてどう思いますか? それはあなたにどのように影響しますか？

聞いたことがあるかもしれませんが、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 (コンセプトの歴史と削除について)。

Windows の tdm-mingw g++ 4.4.0 で -std=gnu++0x パラメータを使用してアプリケーションをビルドしました。

これは ofstream オブジェクトを使用しており、ビルドすると次のリンク エラーが発生します。

デフォルトの古い標準を使用すると、適切にビルドされます。

これが唯一のエラーであり、-lstdc++ でリンクしようとしても役に立ちません。誰かがこれを経験したことがありますか？何か提案はありますか？

編集:次のような ofstream オブジェクトを作成しています:

うまくコンパイルされていますが、リンクされていません。

最初はBoost.Regexに依存するポータブルC++ライブラリコードを作成しようとしていますが、コンパイラがサポートしているのでTR1に移行し、std::tr1名前空間から移動した後に最終的にC++0x仕様に移行します。 stdに。これが私がプリプロセッサでやりたいことのためのいくつかの擬似コードです：

確かに、それはすべてプリプロセッサディレクティブに含まれている必要がありますが、それを実現する方法を知っていれば、ここでは質問しません。:)

概念 (つまり、最近 C++0x 標準から削除されたもの) は、Java などの言語のインターフェイスとどう違うのですか?

(C++11 を使用して) タプルを反復処理するにはどうすればよいですか? 私は次のことを試しました：

しかし、これは機能しません:

エラー 1: 申し訳ありませんが、実装されていません: 'Listener ...' を固定長の引数リストに展開できません。
エラー 2: i は定数式には使用できません。

では、タプルの要素を正しく反復処理するにはどうすればよいでしょうか?

(プリアンブル:私は C++0x ゲームに遅れて従い、C++0x 標準からの概念の削除に関する最近の論争がきっかけで、それらについてもっと学ぶようになりました。私の質問はすべて完全に仮説 -- 概念が有効な C++ コードであるとしても、しばらくの間有効ではない限り -- 概念についてもっと学ぶことにまだ興味があります。特に、最近の決定の背後にあるメリットをより完全に理解するのにどのように役立つかを考えると、その後の論争）

C++0x (最近まで) が提案した概念に関する入門資料を読んだ後、いくつかの構文上の問題に頭を悩ませています。これ以上苦労することなく、ここに私の質問があります：

1) 特定の派生概念をサポートする型 (auto キーワードを介して暗黙的に、または concept_maps を介して明示的に) も、基本概念を個別にサポートする必要がありますか? 言い換えれば、概念を別の概念から導出する行為 (例: concept B<typename T> : A<T>) には、(B, 内に) '見えない' 要求ステートメントが暗黙的に含まれていrequires A<T>;ますか? 混乱は、概念に関するウィキペディアのページに次のように記載されていることから生じます。

クラス継承と同様に、派生概念の要件を満たす型は、基本概念の要件も満たします。

つまり、型は派生概念の要件を満たす必要があるだけであり、必ずしも基本概念の要件を満たす必要はないと言っているように思えますが、これは私には意味がありません。ウィキペディアが決定的な情報源ではないことは理解しています。上記の説明は言葉の選択が悪いだけですか？

2) タイプ名をリストする概念は「自動」にすることができますか? もしそうなら、コンパイラはこれらの型名をどのように自動的にマップしますか? そうでない場合、概念で「自動」を使用することが無効になる他の機会はありますか?

明確にするために、次の架空のコードを検討してください。

これらのクラスのいずれかが SomeType と一致しますか? それとも、型名を含む概念に concept_map が必要ですか?

3) 最後に、どの公理が定義できるのか理解に苦しむ。たとえば、次のような論理的に矛盾する公理を概念に定義させることはできますか?

それは何をしますか？それも有効ですか？

これは非常に長い一連の質問であることを理解しています。事前に感謝します。

コーディング スタイルに関して、人々は C++0x ラムダをどのように使用しているのでしょうか。最も興味深い質問は、キャプチャ リストを作成する際にどの程度徹底するかということです。一方では、言語はキャプチャされた変数を明示的にリストすることを許可し、「明示的なルールは暗黙的なルールよりも優れている」ため、意図を明確に述べるために網羅的なリストを作成することは理にかなっています。例えば：

これに対するもう 1 つの議論は、ref キャプチャされたローカルの有効期間は、キャプチャされたという理由だけで変更されないため (したがって、ラムダは、有効期間が長い間終了しているローカルを簡単に参照してしまう可能性があるため)、キャプチャを明示的にすると、そのようなバグを減らすのに役立つということです。そしてそれらを追跡します。

一方、この言語は、参照されているすべてのローカルを自動キャプチャするためのショートカットも意図的に提供しているため、明らかに使用することを意図しています。そして、上記のような例では、自動キャプチャでも何が起こるかは非常に明確であり、ラムダの寿命は周囲のスコープよりも長生きしないため、使用しない理由はないと主張できます:

明らかに、これはオール オア ナッシングである必要はありませんが、いつ自動キャプチャするか、いつキャプチャを明示的に行うかを決定する何らかの論理的根拠が必要です。何かご意見は？

同様に、capture-by-copy -[=]をいつ使用するか、capture-by-reference - をいつ使用するかという問題もあり[&]ます。キャプチャによるコピーは、有効期間の問題がないため、明らかに安全です。そのため、キャプチャされた値を変更する必要がない場合 (または他の場所からの変更を確認する必要がない場合) は常にデフォルトで使用する必要があると主張できます。そのような場合、参照による参照は (時期尚早の可能性がある) 最適化として扱われ、明らかに違いが生じる場合にのみ適用されます。

一方、参照によるキャプチャはほとんどの場合高速です (特に、ほとんどの STL アルゴリズムなどの小さな型やインライン化可能なテンプレート関数の場合、コピーが実際に高速である場合は、コピーに最適化できることが多いため)、ラムダがそのスコープを超えない場合は安全です (これはすべての STL アルゴリズムの場合でもあります)。したがって、この場合の参照によるキャプチャをデフォルトにすることは、問題のない簡単で無害な最適化です。

あなたの考えは何ですか？

ドブス博士より:

概念は、C++0x の中心的な新機能になるはずだった

「概念」をカットした後でも、次の C++ 標準は遅れる可能性があります。残念ながら、C++0x はありません (C++03 の小さな修正を数えない限り)。C++1x を待つ必要があり、'x' が下位桁になることを期待します。C++1x の機能が完成したため、希望があります (一部の国家標準化団体が、標準の正式な提案に存在する機能を効果的に主張する可能性を除いて)。残された「すべて」は、未解決の技術的問題とコメントを解決するという膨大な作業です。

私は 1997 年から 2000 年にかけて、MT および MP セーフな C++ プログラミングの最先端にいました。それ以来 9 年間、標準が並行性に対処していないことは少し衝撃的です。

それで、大したことは何ですか？