指定されたweak_ptrが有効な場合に呼び出されたときにラムダ/std::関数を実行するヘルパー関数を作成しようとしています。現在、次のコードは機能しますが、残念ながら、テンプレート パラメーターを定義する必要があります。自動テンプレート引数推定でこれを行う方法を探しています。

std::function <void(ArgumentTypes...)>理想的には、を一般的なテンプレート パラメーターに置き換えたいのFunctorTypeですが、 から引数を抽出する方法がわかりませんFunctorType。上記のコードは機能します。以下のコードは理論上のものです。

このようなことをする方法はありますか？

3 つの関数すべてを考えると、この呼び出しはあいまいです。

削除するf( int )と、Clang と GCC の両方で、左辺値参照よりも右辺値参照が優先されます。しかし、代わりにいずれかの参照オーバーロードを削除すると、f( int ).

過負荷の解決は通常、厳密な半順序付けによって行われますが、int互いに同等ではない 2 つのことと同等のようです。ここでのルールは何ですか？これについての不具合報告を思い出したようです。

将来の標準でint &&優先される可能性はありますか? int参照は初期化子にバインドする必要がありますが、オブジェクト型はそれほど制約されていません。したがって、Tとの間のオーバーロードは、T &&事実上、「所有権が与えられている場合は既存のオブジェクトを使用し、それ以外の場合はコピーを作成する」ことを意味する可能性があります。(これは純粋な値渡しに似ていますが、移動のオーバーヘッドを節約できます。) これらのコンパイラは現在動作しているため、これは and をオーバーロードT const &しT &&、明示的にコピーすることによって行う必要があります。しかし、それが厳密に標準であるかどうかさえわかりません。

新しい緩和された C++14 constexpr rules により、コンパイル時のプログラミングはより表現力豊かになります。標準ライブラリもアップグレードして利用できるようになるのだろうか。特に 、std::initializer_list、std::pair、std::tuple、 、 、 、 、 、 、 、 、std::complex、std::bitsetおよび卸売std::arrayと​​してマークされる最有力候補のようです。constexpr

質問:

• 標準ライブラリのどの部分がマークされるようになりましたかconstexpr?
• 他のどの部分にマークを付けることができconstexprますか?
• たとえば、関数 from<cmath>と<algorithm>マークされていないのはなぜconstexprですか?
• そうしない後方互換性の理由はありますか?

N3650から取った次の例を考えてみましょう:

私はおそらく何かを見逃していますが、私が理解asyncしawaitていれば、効果が書くことと同等である場合、上記の例で2つの構造の有用性を示すことのポイントは何ですか:

read().get()と呼び出しの両方write().get()が同期している場所は?

CRTP基本クラスでテンプレート化されたメンバー関数の戻り値の型を推測することは可能ですか?

引数の型の推測はうまく機能しますが、戻り値の型では失敗します。以下の例を考えてみましょう。

これにより、次のエラーが発生します。

私の直感的な仮定は、コンパイラがint引数 to の型を推測できる場合f、 return に対しても機能するはずboolです。テンプレートのインスタンス化時に両方の型が既知であるためです。

末尾の戻り型の関数構文を使用しようとしましたが、 に入れる有効な式が見つかりませんでしたdecltype。

編集1

関数に 1 つ以上のテンプレート化された引数がある場合、Dietmar Kühl は、間接レイヤーを使用してテンプレートのインスタンス化を遅らせることに基づく解決策を提供しました。残念ながら、これは次のように基本クラス関数に引数がない場合は機能しません。

依存型が存在しないため、同じ手法を使用しようとすると失敗します。このケースをどのように処理しますか？

編集2

Johannes Schaub が指摘したように、C++11 はデフォルトのテンプレート引数を備えているためg、任意の型に依存させてから、Dietmar のソリューションを適用することが常に可能です。

編集3

この問題は C++14 にはもう存在しません。通常の関数の戻り値の型推定があり、単純に記述できるためです。

C++14/C++1y (n3690) の草案にざっと目を通していると、セクション §21.7 でbasic_stringリテラル接尾辞が導入されていることに気付きました。

私の質問は次のとおりです。

• basic_stringリテラルを使用すると、実行時に高速になる可能性はありますか?
• 私の「素朴な」実装は完全に間違っていますか?
• ROM 内のデータのレイアウトは、basic_stringリテラルで異なる可能性がありますか、またはコンパイル時と実行時のその他の違いはありますか?

バックグラウンド

これにより、次のような文字列リテラルを直接使用できることがわかっています。

しかし、変換コンストラクター に依存することの利点は何string(const char*)ですか?

「古い」コードは次のようになります。

私が見る限り、の実装operator "" s()は基本的に次のようになります。

つまり、同じc'torを使用するだけです。そして私の推測では、それは実行時に行われなければならないということですが、私は間違っていますか?

編集：Nicol Bolasが私の例の下で正しく指摘したように、同じコンストラクターを使用していませんが、追加の長さを持つコンストラクターを使用しています。これは明らかに、構築に非常に役立ちます。これは私に疑問を残します: これは、コンパイラが文字列リテラルを ROM に入れること、またはコンパイル時に同様のものを入れることよりも良いですか?