問題タブ [c++17]

C++ では、メンバー関数の一部で動作しないクラスでクラス テンプレートをインスタンス化することは合法ですか?

例えば：

このコードはコンパイルされ、bを呼び出さない限り、 を使用できますb.call_f()。(また、明示的にインスタンス化するとtemplate class Wrapper<B>;、すべてのメンバー関数がインスタンス化されるため、コンパイル エラーが発生します。)

これは動作することが保証されていますか、それとも未定義の動作ですか? もしそうなら、概念と要件の導入により、これは C++17 で変更されますか?

コードへの参照がいくつかある質問をしました。

私は一般的にエイリアステンプレートを誤解していると思います:

enable_if_torconditional_tステートメントでエイリアス テンプレートに渡すテンプレート パラメーターを評価しないのはなぜでしょうか。

上記のコードは、enable_if_t一度に複数のテンプレート パラメータを実行するだけですか?

第二に、私は の役割について特定の誤解をしていると思いますvoid_t。このコメントは、C++17 標準が を定義していると述べていますvoid_t。ここに私が得られないものがあります:

void_t勝手な名前じゃないの？template <typename...> using void_t = void;使用する予定の場所を定義する必要がある場合void_t、任意の名前を標準化する意味は何ですか?

私はこれを読んでいましたが、registerキーワードは次の C++ 標準から削除される可能性が高いと書かれています。また、それregisterは 2011 年に廃止されたとも書かれています。では、registerストレージ クラス指定子の何が問題になっているのでしょうか。

最近のコンパイラは非常にスマートで、頻繁に使用される変数を速度 (高速アクセス) のために暗黙的に最適化し、それらを CPU レジスタに配置します。

ただし、C++ の専門家は、 を使用しない、または使用しないとも言っていますregister。registerでは、キーワードの問題点は何でしょうか。

場合によっては、単に不透明な前方宣言ではなく、公開された機能を公開したクラス宣言を提供したいことがありますが、プライベートまたは実装固有のフィールドとメソッドにコミットしたくない場合があります。これに対する 1 つの解決策は、pimpl イディオムです。内部クラスへのポインターを使用して、公開されているクラスの実装を格納します。

私は pimpl を使用するのが本当に好きではなく、言語が本当にプライベートなメンバーを持つことを許可することを望みます-クラスを使用するコードがそれらの宣言を「見ない」ようにします(したがって、実装の詳細時に再コンパイルする必要はおそらくありません)変化する）。また、最近、C++ の進化の速度が大幅に速くなっていることに気付きました。これは、標準的な更新では 3 年間のカチカチというパターンです。それで...そのような機能をC++に追加する提案はありますか? 一部のコンパイラは現在それをサポートしていますか?

典型的なプログラミングのニーズにとって、C++11 は大きなマイルストーンでした。Boost コードの 95% を標準ライブラリに置き換えました。

それでも、標準ライブラリでまだカバーされていないそのライブラリの現在の状況はどうですか?

Signals2 と Lockfree が必要なため、疑問に思い始めました。

私が理解している限り（少なくとも について）、自明でない場合（暗黙的に生成されたまたは） c++14、デストラクタは存在できません。自明でないデストラクタを持つ構造体のコンストラクタを宣言するポイントは何ですか?constexpr=defaultconstexpr

たとえば、デストラクタが明らかに明示的に定義されていても、std::unique_ptrいくつかのコンストラクタ constexpr（デフォルトおよび）があります（オブジェクトがオブジェクトは空の状態にあり、私が見たように、空のデストラクタでさえオブジェクトをコンパイル定数式で使用することはできません)nullptr_tnullptr

もう 1 つの例は、std::variantの提案です。ほとんどすべてのコンストラクターconstexprがありますが、デストラクタには署名が~variant()あり、それを行う必要があります。call get<T_j> *this).T_j::~T_j() with j being index().

私は何が欠けていますか？