Visual Studio 2013で修正されたVisual Studio 2012のC ++ 11標準実装のバグ

この記事では、Visual Studio 2012で利用可能でVisual Studio 2013で修正されたC ++ 11標準の実装における多くのバグについて説明します。したがって、理論上使用されるはずのC ++ 11を使用できるようになりました。 VS2012のバグを回避するために「クランチ」を作成する必要があった場合は、それらを削除できます。



残念ながら、すべてのバグが修正されたわけではなく、VS2012からVS2013に何かが移行し、新しいバグが発生しました。 カットの下に、現在の状況の詳細な分析があります。

可変長テンプレートの型の数に制限がなくなりました

Visual Studio 2013は可変長テンプレートを完全にサポートしており、std :: functionやmake_sharedなどの引数の数に制限がなくなりました。 Visual Studio 2012では、この制限が存在し、5（5）でした。

型推論に関するバグを修正

自動失われたアライメント指定子

autoを使用して式__declspec（align（...））で定義された型の変数を宣言した場合、VS2012でalignが誤って処理され、不適切なメモリロケーションとランダムクラッシュが発生しました。

すべてのケースで、タイプの代わりにdecltypeを使用できませんでした

decltypeを介して定義された型は、通常の型を使用できる場所ならどこでも使用できるはずであるという事実にもかかわらず、VS2012では、たとえば次のようなコードの記述が許可されていません。

vector<int> a; decltype(a)::iterator iter = a.end(); //   VS2012
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

declvalはコンパイルエラーを引き起こしました

C ++ 11標準に準拠した一部の正しいコードは、declvalの誤った解釈のためにVS2012でコンパイルされませんでした。

is_comparableパターンを宣言するとします：

 template<typename, typename = true_type> struct is_comparable : public false_type {}; template<typenameT> struct is_comparable<T, typename is_convertible<decltype(declval<T>() > declval<T>()), bool>::type> : public true_type {};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

declvalはTが何であるかを理解しないため、これはVS2012では機能しません。

スマートポインターのバグを修正

ラムダ関数をカスタム削除機能として使用すると、bool型への変換が中断されました

ラムダ関数を使用してスマートポインターを削除したときに何が起こるかを決定した場合、このポインターをブール型に変換するコンテキストで使用することはできません。

 auto stream_deleter = [](ofstream* os) { os->close(); }; unique_ptr<ofstream, decltype(stream_deleter)> p_log(&log_file, stream_deleter); if (!p_log) // compile error cout << "Couldn't open file" << endl;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

unique_ptr ::リセットを呼び出すと、二重に削除される可能性があります

リセット方法の操作の順序は、標準で記述されている順序と一致しませんでした。 これにより、オブジェクトが二重に削除される可能性があります。 例：

 class SelfReferential { unique_ptr<SelfReferential>& _p_self; public: SelfReferential(unique_ptr<SelfReferential>& p) : _p_self(p) {} ~SelfReferential() { _p_self.reset(); } }; unique_ptr<SelfReferential> p; p = unique_ptr<SelfReferential>(new SelfReferential(p)); p.reset(); //    ~SelfReferential
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

resetメソッドを呼び出すと、SelfReferentialデストラクタが開始され、再びResetが呼び出されます。 二重削除が発生するのは、resetメソッドが、制御下のオブジェクトへのポインターを、削除前ではなく削除後にリセットするためです。

shared_ptr、保護されたデストラクタ、nullptr

nullptrに初期化して、保護されたデストラクタを持つクラスのshared_ptrを作成できませんでした：

 class Interface { public: virtual void do_stuff() = 0; protected: ~Interface() {} }; class Implementation : public Interface { public: void do_stuff() override { // ... } }; shared_ptr<Interface> ptr1 = make_shared<Implementation>(); // OK shared_ptr<Interface> ptr2 = nullptr; // 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Visual Studio 2013では、このコードは標準の意図どおりにコンパイルされます。

型特性ライブラリで修正されたバグ

誤った操作is_function

is_functionは、渡された関数に含まれる引数が多すぎる場合、誤った結果を返します。

 typedef void f(int, bool, int*, int[], int, int, int, int, int, int, int); is_function<f>::value; // false,    true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、デフォルト以外の呼び出し規約を持つ関数の結果は誤っています



同様に、is_member_function_pointerは、明示的に指定された呼び出し規約を持つメソッドの結果を正しく返すことができません



反対に、is_member_pointerは__cdeclメソッドでは正しく機能しません。

 typedef void (__cdecl A::*ccall_proc)(int, long, double); is_member_pointer<ccall_proc>::value; // false,    true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

is_objectはis_functionを介して定義されているため、多数の関数引数を伴う上記のエラーが適用され、オブジェクトの誤った定義につながります。

is_scalarはnullptr_tを認識しませんでした

is_scalar <nullptr_t>はVS2012で誤ってfalseを返しました-標準はnullptr_tをスカラー型として定義しています。

is_podはvoidを誤解した

is_podはVS2012で誤ってtrueを返しましたが、voidはPODタイプではありません

is_constructibleがリンクに対して誤った結果を返しました

is_constructibleは参照型では正しく動作せず、次のような場合にfalseを返します。

 is_constructible<const string&, string>::value; is_constructible<const string&, string&&>::value;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

alignment_ofとaligned_unionのバグ

VS2012のalignment_ofは、プライベートデストラクタを持つ型で使用すると、アクセスできないデストラクタに関する誤った警告を生成します。

また、aligned_unionはVS2012で正しく機能しませんでした。

 typedef aligned_union<16, string>::type StorageType; sizeof(string); // 24 sizeof(StorageType); // 16,    24  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

align_unionには、テンプレート引数T1、...、Tnのアライメント値を含む静的メンバーalignment_valueが必要です。 ただし、これはVS2012では実装されていません。

common_typeが誤ってvoidを返します

標準で想定されているコンパイルエラーの代わりに、VS2012でcommon_typeはvoidを返しました。

 common_type<int, string>::type; // void
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

common_typeは、*が*変換可能な場合、カスタムタイプに対して誤ってvoidを返します。

 struct A {}; struct AWrapper { AWrapper() {} AWrapper(const A&) {} }; common_type<A, AWrapper>::type; // void
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

result_ofがコンパイルされない場合があります

VS2012でこのテンプレートでmove-only引数を使用することにした場合、問題が発生します。

 result_of<Copyable(MoveOnly&&)>::type; //  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

STLコンテナおよびアルゴリズムで修正されたバグ

minmax_elementは機能しませんでした

標準では、このアルゴリズムの2つのバージョンを定義しています。

 pair<Iter, Iter> minmax_element(Iter first, Iter last) pair<Iter, Iter> minmax_element(Iter first, Iter last, Compare comp)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（first、last）を返す必要があります。firstは最小の要素を示し、lastは最大の要素を示します。範囲が空の場合はmake_pair（first、first）を返します。 ただし、VS2012では、代わりにmake_pair（min_element（first、last）、max_element（first、last））が返されました。

コンテナは、移動コンストラクタを持つために誤って要素タイプを必要としました

すべてのコンテナ移動コンストラクターは、誤って要素タイプに移動コンストラクターが必要でした。

 struct A { A() {} private: A(A&&); A(const A&); }; deque<A> source; deque<A> target(move(source)); //  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様に、mapおよびunordered_map要素のアクセス演算子には、移動コンストラクターが必要です。

 map<string, A> m; A& elem = m["abc"]; //  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

並列化と非同期に関連するエラーを修正

将来から作成されたshared_future

VS2012のもう1つのバグは、参照型とvoidのfutureとshared_futureの実装にありました。 このバグにより、次のコードをコンパイルできました（これは明らかに間違いです。将来は移動のみのタイプなので）。

 future<int&> f_ref; shared_future<int&> sf_ref(f_ref); // ,     future<void> f_void; shared_future<void> sf_void(f_void); // ,    
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スレッドクラスのメモリリーク

プログラムの終了時にメモリリークを引き起こす可能性のあるバグ。 これは、スレッドがat_thread_exit_mutexオブジェクトと一部の内部データ構造を作成したが破壊したことがないために発生しました。

promiseから受け取った将来の無駄な待機関数

Visual Studio 2012のバグにより、このようなfutureオブジェクトのwait_forおよびwait_until関数は、future_status :: timeoutまたはfuture_status :: readyの代わりにfuture_status :: deferredを返し、これらのメソッドは役に立たなくなりました。

future_error例外の無効なメッセージ

エラーコードとその説明の不一致のバグ。たとえば、「broken promise」という例外を受け取ると、メッセージには「future already retrieved」というテキストが含まれます。 エラーコードのみが正しかった。

アトミックテンプレートは、既定のコンストラクターなしで型に定義できませんでした

デフォルトのコンストラクタなしで型にアトミックテンプレートを使用しようとすると、エラーメッセージを受け取りましたが、これは正しくありません。

原子はゆっくりと働きました

VS2012では、アトミック操作が整合性チェックでオーバーロードされることがありました（必要のない場所で行われました）。 これは標準に違反していませんが、コードの動作は可能な限り遅くなりました。 VS2013には、アトミック操作の完全に新しい実装があり、はるかに高速に動作します。

乱数生成のエラーを修正

デバッグモードでは、mersenne_twister_engineをゼロに初期化しようとすると、誤ったアサートが生成されました。



minus_with_carry_engineのストリームステートメントに、未定義の動作を引き起こすエラーが含まれていました。



independent_bits_engineとshuffle_order_engineは、移動コンストラクターで内部メンバーを初期化しませんでした。これにより、無限ループが発生する場合がありました。

合理的な算術のライブラリのバグを修正

ライブラリにはいくつかのバグが見つかりました。



VS2012で次のコードを書くことができませんでした

 ratio_add<ratio<1, 2>, ratio<1, 3>>::num; ratio_add<ratio<1, 2>, ratio<1, 3>>::den;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

代わりに、それらのタイプを介して分子と分母にアクセスする必要がありました。

 ratio_add<ratio<1, 2>, ratio<1, 3>>::type::den; ratio_add<ratio<1, 2>, ratio<1, 3>>::type::num;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もう1つの間違いは、比較の実装です。

 cout << "2/60 < -1/3: " << ratio_less<r2_60, r1_3>::value << endl; // false cout << "2/60 < 1/-3: " << ratio_less<r2_60, ratio<1, -3>>::value << endl; // true    false
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、VS2012では、テンプレートに渡される分母が常に正数であることを確認する必要がありました。



別のバグは、ratio_equalが不等式を正しく判断したが、必ずしも等式を正しく判断するとは限らなかったことです。

 ratio_equal<ratio<1, 4>, ratio<4, 16>>::value; // false    true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ここに別のバグがあります。 比率<N、D>があり、Dがゼロまたはintmax_tより大きい数値の場合、プログラムは間違いなく無効です。 ただし、Visual Studio 2012はそのようなエラーを検出しませんでした。

 typedef ratio<1, 0> r_error; cout << r_error::den << endl; //   ,  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 typedef ratio<INTMAX_MIN, 1> r_error2; cout << r_error2::num << endl; //   ,  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Visual Studioの実装では、これらの状況でトリガーされるstatic_assertステートメントは比率コンストラクターに配置されます。 ただし、コンストラクタはクラスのオブジェクトを作成するときにのみ機能しますが、上記の例ではこれは発生しません。



同様に、一部のコードはコンパイルされますが、そうすべきではありません。

 // ,     -     ratio_multiply<ratio<1, INTMAX_MAX>, ratio<1, 2>>::type;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Visual Studio 2013のその他のエラー

Tuple_elementは、境界外への出入りをチェックしません

tuple_element <I、配列<T、N >>は、I <Nであることを確認し、そうでない場合はコンパイルしないでください。 これはVS2013まで発生しませんでした。

std ::関数のboolへの無効な変換

理論的には次のようにすべきときにオブジェクトが空ではなかったため、場合によっては、VS2012で変換によって誤った結果が得られることがありました。

 // JetPlane   Plane function<bool(JetPlane*)> plane_ready_func = function<bool(Plane*)>(); if (plane_ready_func) //   false,   { plane_ready_func(nullptr); //    bad_function_call }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

右辺値の割り当て

Visual Studio 2012は、標準で定義されている右辺値の割り当てを禁止していません。

 struct Dummy { int _x; }; Dummy get_dummy() { Dummy d = { 10 }; return d; } get_dummy()._x = 20; // ,    
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

align（）がパラメータを誤って更新します

この関数は戻りアドレスを正しく計算しますが、最後の2つのパラメーターを誤って更新します。

 void* p = (void*)0x1; //   200     32  //      230  size_t space = 230; void* res = align(32, 200, (void*&)p, space); // res  null  31    , //     30 space = 256; //     256 res = align(32, 200, (void*&)p, space); // res  0x20 (    32) // p  0xE8 (200 + 32)    0x20 // space  25    225
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

time_putはwchar_tでは機能しません

time_putは、wchar_tの初期化時に出力を生成しません。

おわりに

Stephan Lavavejが書いたこの投稿で、VS2013の変更の完全なリスト（C ++ 11だけでなく）を読むことができます。



新しいC ++ 11機能の実装に加えて、Visual Studio 2013は、コンパイラとライブラリの既存の機能の多くのバグを修正しました。不正なコンパイラエラーからメモリリークやパフォーマンスの低下まで。 これは間違いなく前向きな傾向です。



残念ながら、VS2013にはVS2012から継承されたいくつかのバグがまだ含まれており、いくつかの新しいバグが追加されています。 私は今、このすべてについて本を書いていますが、まだ完成していませんが、 今すぐ読むことができます。