std :: make_shared/std :: make_uniqueがリストの初期化を使用しない理由はありますか？

Question

具体的には、ダイレクトリスト初期化（cppreference.com（3））です。

両方std::make_sharedと均一初期機能はC++ 11に導入されました。したがって、ヒープ上にオブジェクトを割り当てる際に集約初期化を使用することができます。new Foo{1, "2", 3.0f}。これは、集約、ポッドなどのコンストラクタを持たないオブジェクトを直接初期化するのに最適です。

カジュアル構造体を関数内に効率的に宣言するなどの実際のシナリオは、ラムダは、私の経験では、非常に一般的になった：

void foo() 
{ 
    struct LambdaArgs 
    { 
     std::string arg1; 
     std::string arg2; 
     std::string arg3; 
    }; 

    auto args = std::make_shared<LambdaArgs>(LambdaArgs{"1", "2", "3"}); 

    auto lambda = [args] { 
     /// ... 
    }; 

    /// Use lambda 
    /// ... 
} 

ここauto args = std::make_shared<LambdaArgs>("1", "2", "3");はいいことwhouldが、std::make_sharedは通常として実装されているので、仕事に行くされていません。

template<typename T, typename... Args> 
std::shared_ptr<T> make_shared(Args && ...args) 
{ 
    return std::shared_ptr<T>(new T(std::forward<Args>(args)...)); 
} 

だから我々はauto args = std::make_shared<LambdaArgs>(LambdaArgs{"1", "2", "3"});と付き合っている。

std::make_sharedで解決されるはずの問題は、コンストラクタのないオブジェクトに対しても引き続き発生します。また、この回避策は、美的ではないだけでなく効率も悪くなります。

これは別の見落としであるか、この選択肢を守る理由がいくつかあります。具体的には、どのような落とし穴は、リストの初期化ソリューションにすることができますか？ std::make_uniqueは、C++ 14に後で導入されました。なぜ同じパターンに従っていますか？

Answer 1

具体的には、どのような落とし穴をリスト初期化ソリューションに含めることができますか？

リスト初期化の一般的な落とし穴のすべて。

たとえば、非initializer_listコンストラクタの非表示。 make_shared<vector<int>>(5, 2)は何をしますか？あなたの答えが「5 intの配列を構築している」場合、それは絶対に正しいです... make_sharedがリスト初期化を使用していない限り。それはあなたの瞬間を変えるからです。

間接初期化関数のすべてがコンストラクタ構文を使用しているので、これを突然変更すると、既存のコードが破損することに注意してください。だから、あなたはそれを気取らずに変えて、世界が働き続けることを期待することはできません。この場合に特有の

プラス1以上：狭く問題：

struct Agg 
{ 
    char c; 
    int i; 
}; 

あなたはこの集計を初期化するAgg a{5, 1020};を行うことができます。しかし、決してmake_shared<Agg>(5, 1020)を行うことはできませんでした。どうして？コンパイラは、リテラル5をデータ損失なしでcharに変換できることを保証できるためです。しかし、このような間接的な初期化を使用すると、5という文字列は、テンプレートによって推定され、intと推定されます。そしてコンパイラはのいずれもintをデータの損失なしでcharに変換できることを保証できません。これは「ナロー変換」と呼ばれ、リストの初期化では明示的に禁止されています。

5を明示的にcharに変換する必要があります。

標準ライブラリには、LWG 2089の問題があります。技術的にはこの問題はallocator::constructについて述べていますが、それはmake_Xのような間接的な初期化関数と、any/optional/variantのC++ 17のインプレースコンストラクタの両方に等しく適用されます。

なぜ同じパターンに従っていますか？

根本的にも予想外にも異なる動作を持つ2つの異なる機能を持つことは良いことではないため、同じパターンに従います。

Answer 2

std :: make_sharedで解決されるはずの問題は、コンストラクタなしのオブジェクトに対しても引き続き発生します。

いいえ、問題は解決しません。主な問題make_sharedは、オブジェクトが割り当てられている間にメモリリークが発生する可能性があり、所有権はスマートポインタによって取得されます。また、制御ブロックの1つの余分な割り当てを削除することもできます。

はい、直接初期化を使用できないのは不便ですが、これは決してmake_sharedの宣言された目標ではありません。