Visual C++ 2003 ~ 2015 の変更履歴Visual C++ change history 2003 - 2015

この記事では、Visual Studio 2003 から Visual Studio 2015 の互換性に影響する変更についてすべて説明します。この記事の「新しい動作」や「現在」という語は、Visual Studio 2015 以降を指します。This article describes all the breaking changes from Visual Studio 2015 going back to Visual Studio 2003, and in this article the terms "new behavior" or "now" refer to Visual Studio 2015 and later. 「従来の動作」や「以前」という語は、Visual Studio 2013 以前のリリースを指します。The terms "old behavior" and "before" refer to Visual Studio 2013 and earlier releases.

最新版の Visual Studio については、「What's new for Visual C++ in Visual Studio」 (Visual Studio における Visual C++ の新機能) と「Conformance Improvements in Visual C++ in Visual Studio」 (Visual Studio における Visual C++ の準拠の強化) を参照してください。For information about the latest version of Visual Studio, see What's new for Visual C++ in Visual Studio and Conformance Improvements in Visual C++ in Visual Studio.

注意

Visual Studio 2015 と Visual Studio 2017 では、バイナリに関して重大な変更はありません。There are no binary breaking changes between Visual Studio 2015 and Visual Studio 2017.

Visual Studio の新しいバージョンにアップグレードすると、以前にコンパイルと動作が正常に行えたコードでコンパイルやランタイム エラーが発生する場合があります。When you upgrade to a new version of Visual Studio, you might encounter compilation and/or runtime errors in code that previously compiled and ran correctly. 新しいバージョンでこのような問題を引き起こす変更は 互換性に影響する変更と呼ばれ、通常は C++ 言語の基準、関数シグネチャ、またはメモリ オブジェクトのレイアウトの変更によって必要となります。Changes in the new version that cause such problems are known as breaking changes, and typically they're required by modifications in the C++ language standard, function signatures, or the layout of objects in memory.

検出や診断が難しいランタイム エラーを回避するには、異なるバージョンのコンパイラを使用してコンパイルされたバイナリには静的にリンクしないことをお勧めします。To avoid run-time errors that are difficult to detect and diagnose, we recommend that you never statically link to binaries compiled by using a different version of the compiler. また、EXE または DLL プロジェクトをアップグレードする場合、リンクするライブラリもアップグレードします。Also, when you upgrade an EXE or DLL project, make sure to upgrade the libraries that it links to. 異なるバージョンのコンパイラを使用してコンパイルされたバイナリ間 (DLL を含む) で CRT (C Runtime) または C++ 標準ライブラリ (C++ Standard Library) 型を渡さないようにしてください。Don't pass CRT (C Runtime) or C++ Standard Library (C++ Standard Library) types between binaries, including DLLs, compiled by using different versions of the compiler. 詳細については、「 Potential Errors Passing CRT Objects Across DLL Boundaries」を参照してください。For more information, see Potential Errors Passing CRT Objects Across DLL Boundaries.

COM インターフェイスまたは POD オブジェクトではないオブジェクトで、特定のレイアウトに依存するコードを記述しないでください。You should never write code that depends on a particular layout for an object that isn't a COM interface or a POD object. このようなコードを記述している場合、アップグレード後に動作することを確認する必要があります。If you do write such code, then you must ensure that it works after you upgrade. 詳細については、「ABI の境界での移植性」を参照してください。For more information, see Portability At ABI Boundaries.

また、コンパイラの準拠に関する継続的な強化によって、コンパイラが既存のソース コードを認識する方法が変わる可能性があります。Additionally, ongoing improvements to compiler conformance can sometimes change how the compiler understands your existing source code. たとえば、以前にビルドして問題なく実行できていたコードでも、ビルド時に新しいエラーや異なるエラーが発生したり、動作が変わったりする可能性があります。For example, you might find new or different errors during your build, or even behavioral differences in code that previously built and seemed to run correctly. これらの機能強化は、このドキュメントで説明しているような破壊的変更ではありませんが、問題を解決するためにソース コードの変更が必要な場合があります。Although these improvements aren't breaking changes like the ones discussed in this document, you may need to make changes to your source code to resolve these issues:

Visual Studio 2015 の準拠に関する変更Visual Studio 2015 Conformance Changes

C ランタイムライブラリ (CRT)C Runtime Library (CRT)

一般的な変更General Changes

  • リファクタリング バイナリRefactored binaries

    CRT ライブラリは 2 つの異なるバイナリにリファクタリングされています。その 1 つはユニバーサル CRT (ucrtbase) で、標準機能のほとんどが含まれています。もう 1 つは VC ランタイム ライブラリ (vcruntime) です。The CRT Library has been refactored into a two different binaries: a Universal CRT (ucrtbase), which contains most of the standard functionality, and a VC Runtime Library (vcruntime). vcruntime ライブラリには、例外処理や組み込み関数などのコンパイラ関連の機能が含まれています。The vcruntime library contains the compiler-related functionality such as exception handling, and intrinsics. 既定のプロジェクト設定を使用している場合は、この変更による影響は受けません。リンカーは、新しい既定のライブラリを自動的に使用するためです。If you are using the default project settings, then this change doesn't impact you since the linker will use the new default libraries automatically. プロジェクトの [リンカー] プロパティの [すべての既定のライブラリの無視] を [はい] に設定するか、コマンドラインで /NODEFAULTLIB リンカー オプションを使用する場合、([追加の依存ファイル] プロパティの) ライブラリのリストを更新して、新しいリファクタリング ライブラリを組み込む必要があります。If you've set the project's Linker property Ignore All Default Libraries to Yes or you are using the /NODEFAULTLIB linker option on the command line, then you must update your list of libraries (in the Additional Dependencies property) to include the new, refactored libraries. 古い CRT ライブラリ (libcmt.lib、libcmtd.lib、msvcrt.lib、msvcrtd.lib) をリファクタリングした同等のライブラリで置き換えます。Replace the old CRT library (libcmt.lib, libcmtd.lib, msvcrt.lib, msvcrtd.lib) with the equivalent refactored libraries. 2 つのリファクタリング ライブラリのそれぞれについて、静的 (.lib) バージョンと動的 (.dll) バージョンがあり、リリース (サフィックスなし) バージョンとデバッグ (サフィックス "d" を持つ) バージョンがあります。For each of the two refactored libraries, there are static (.lib) and dynamic (.dll) versions, and release (with no suffix) and debug versions (with the "d" suffix). 動的バージョンには、リンク先インポート ライブラリがあります。The dynamic versions have an import library that you link with. 2 つのリファクタリング ライブラリとは、ユニバーサル CRT (具体的には ucrtbase.dll または ucrtbase.lib、ucrtbased.dll または ucrtbased.lib)、と VC ランタイム ライブラリ (libvcruntime.lib、vcruntimeversion.dll、libvcruntimed.lib、vcruntimedversion.dll) です。The two refactored libraries are Universal CRT, specifically ucrtbase.dll or ucrtbase.lib, ucrtbased.dll or ucrtbased.lib, and the VC runtime library, libvcruntime.lib, vcruntimeversion.dll, libvcruntimed.lib, and vcruntimedversion.dll. Visual Studio 2015 と Visual Studio 2017 におけるバージョンは 140 です。The version in both Visual Studio 2015 and Visual Studio 2017 is 140. CRT ライブラリの機能」を参照してください。See CRT Library Features.

<locale.h>

  • localeconvlocaleconv

    現在、locale.h で宣言される localeconv 関数は、スレッドごとのロケールが有効なときに正常に機能します。The localeconv function declared in locale.h now works correctly when per-thread locale is enabled. 以前のバージョンのライブラリでは、この関数はスレッドのロケールではなくグローバル ロケールの lconv データを返していました。In previous versions of the library, this function would return the lconv data for the global locale, not the thread's locale.

    スレッドごとのロケールを使用する場合は、localeconv の使用を確認する必要があります。If you use per-thread locales, you should check your use of localeconv. コードで、返される lconv データがグローバル ロケール用であることを前提とする場合は、それを修正する必要があります。If your code assumes that the lconv data returned is for the global locale, you should correct it.

<math.h>

  • 数値演算ライブラリ関数の C++ のオーバーロードC++ overloads of math library functions

    以前のバージョンでは、は、 <math.h> 数値演算ライブラリ関数の C++ オーバーロードの一部を定義しましたが、すべてではありませんでした。In previous versions, <math.h> defined some, but not all, of the C++ overloads for the math library functions. 残りのオーバーロードは、ヘッダーに含まれていました <cmath> 。The rest of the overloads were in the <cmath> header. 含まれているだけのコードには <math.h> 、関数のオーバーロードの解決に関する問題がある可能性があります。Code that only included <math.h> could have problems with function overload resolution. 現在、C++ のオーバーロードはから削除されて <math.h> おり、にのみ存在し <cmath> ます。Now the C++ overloads have been removed from <math.h> and are only found in <cmath>.

    エラーを解決するには、を含め、 <cmath> から削除された関数の宣言を取得し <math.h> ます。To resolve errors, include <cmath> to get the declarations of the functions that were removed from <math.h>. 次の関数は移動されました。These functions were moved:

    • double abs(double) および float abs(float)double abs(double) and float abs(float)

    • double pow(double, int), float pow(float, float), float pow(float, int), long double pow(long double, long double), long double pow(long double, int)double pow(double, int), float pow(float, float), float pow(float, int), long double pow(long double, long double), long double pow(long double, int)

    • float および long double の各バージョンの浮動小数点関数 acosacosh 、、 asin asinhatan atanh atan2 cbrt ceil copysign cos cosh erf erfc exp exp2 expm1 fabs fdim floor fma fmax fmin fmod frexp hypot ilogb ldexp lgamma llrint llround log log10 log1p log2 lrint lround modf nearbyint nextafter nexttoward remainder remquo rint round scalbln scalbn sin sinh sqrt tan tanh tgamma 、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、およびです。truncfloat and long double versions of floating point functions acos, acosh, asin, asinh, atan, atanh, atan2, cbrt, ceil, copysign, cos, cosh, erf, erfc, exp, exp2, expm1, fabs, fdim, floor, fma, fmax, fmin, fmod, frexp, hypot, ilogb, ldexp, lgamma, llrint, llround, log, log10, log1p, log2, lrint, lround, modf, nearbyint, nextafter, nexttoward, remainder, remquo, rint, round, scalbln, scalbn, sin, sinh, sqrt, tan, tanh, tgamma, and trunc

    absヘッダーのみを含む浮動小数点型でを使用するコードがある場合 <math.h> 、浮動小数点バージョンは使用できなくなります。If you have code that uses abs with a floating point type that only includes the <math.h> header, the floating point versions will no longer be available. エラーを生成する浮動小数点引数を持つ場合でも、現在は abs(int) の呼び出しで解決します。The call now resolves to abs(int), even with a floating point argument, which produces the error:

    warning C4244: 'argument' : conversion from 'float' to 'int', possible loss of data
    

    この警告を修正するには、の呼び出しを abs 、double 引数や float 引数などの浮動小数点バージョンに置き換え abs fabs fabsf ます。または、ヘッダーを含めて、 <cmath> 引き続き使用 abs します。The fix for this warning is to replace the call to abs with a floating point version of abs, such as fabs for a double argument or fabsf for a float argument, or include the <cmath> header and continue to use abs.

  • 浮動小数点の準拠Floating point conformance

    NaNs 値や無限大値などの特殊なケースの入力に関する IEEE-754 仕様および C11 Annex F 仕様に対する準拠を改善するために、多くの変更が数値演算ライブラリに対して加えられています。Many changes to the math library have been made to improve conformance to the IEEE-754 and C11 Annex F specifications with respect to special case inputs such as NaNs and infinities. たとえば、簡易な NaN 入力 (以前のバージョンのライブラリでは、多くの場合、エラーとして扱われていた) はエラーとして扱われなくなりました。For example, quiet NaN inputs, which were often treated as errors in previous versions of the library, are no longer treated as errors. IEEE 754 標準C11 標準の付録 F をご覧ください。See IEEE 754 Standard and Annex F of the C11 Standard.

    これらの変更によってコンパイル時エラーが発生することはありませんが、プログラムの動作が変わる可能性はあり、標準に従ってより正確に動作するようになる可能性があります。These changes won't cause compile-time errors, but might cause programs to behave differently and more correctly according to the standard.

  • FLT_ROUNDSFLT_ROUNDS

    Visual Studio 2013 で FLT_ROUNDS マクロは定数式に拡張されましたが、これは正しくありませんでした。丸めモードは実行時に (たとえば、fesetround を呼び出すことにより) 構成することができるからです。In Visual Studio 2013, the FLT_ROUNDS macro expanded to a constant expression, which was incorrect because the rounding mode is configurable at runtime, for example, by calling fesetround. FLT_ROUNDS マクロは動的になり、現在の丸めモードを正確に反映します。The FLT_ROUNDS macro is now dynamic and correctly reflects the current rounding mode.

<new> および <new.h><new> and <new.h>

  • new と deletenew and delete

    以前のバージョンのライブラリでは、実装定義演算子の new 関数と delete 関数は、ランタイム ライブラリ DLL (たとえば、msvcr120.dll) からエクスポートされていました。In previous versions of the library, the implementation-defined operator new and delete functions were exported from the runtime library DLL (for example, msvcr120.dll). 現在、これらの演算子関数は常に (ランタイム ライブラリ DLL を使用する場合でも) 静的にバイナリにリンクされています。These operator functions are now always statically linked into your binaries, even when using the runtime library DLLs.

    これはネイティブ コードまたは混合コード (/clr) の破壊的変更ではありませんが、/clr:pure としてコンパイルされるコードでは、この変更によってコードのコンパイルが失敗する可能性があります。This isn't a breaking change for native or mixed code (/clr), however for code compiled as /clr:pure, this change might cause your code to fail to compile. コードを /clr:pure としてコンパイルする場合、#include <new> または #include <new.h> を追加してこの変更によるビルド エラーを回避する必要があります。If you compile code as /clr:pure, you may need to add #include <new> or #include <new.h> to work around build errors due to this change. Visual Studio 2015 では /clr:pure オプションは非推奨とされており、Visual Studio 2017 ではサポートされていません。The/clr:pure option is deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017. "ピュア" でなければならないコードは C# に移植する必要があります。Code that needs to be "pure" should be ported to C#.

<process.h>

  • _beginthread および _beginthreadex_beginthread and _beginthreadex

    現在、_beginthread 関数と _beginthreadex 関数には、モジュールへの参照が含まれています。そのモジュールで、スレッドの期間に関するスレッド プロシージャが定義されています。The _beginthread and _beginthreadex functions now hold a reference to the module in which the thread procedure is defined for the duration of the thread. これは、スレッドの実行が完了するまでモジュールが確実にアンロードされないようにするのに役立ちます。This helps to ensure that modules aren't unloaded until a thread has run to completion.

<stdarg.h>

  • va_start と参照型va_start and reference types

    C++ コードをコンパイルするときに、渡される引数が参照型でないことが、現在 va_start によりコンパイル時に検証されるようになりました。When compiling C++ code, va_start now validates at compile-time that the argument passed to it isn't of reference type. 参照型の引数は、C++ 標準では禁止されています。Reference-type arguments are prohibited by the C++ Standard.

<stdio.h> および <conio.h><stdio.h> and <conio.h>

  • 現在、関数の printf ファミリと scanf ファミリは、インラインで定義されています。The printf and scanf family of functions are now defined inline.

    および関数のすべての定義 printfscanf <stdio.h> 、、、 <conio.h> およびその他の CRT ヘッダーにインラインで移動されています。The definitions of all of the printf and scanf functions have been moved inline into <stdio.h>, <conio.h>, and other CRT headers. この破壊的変更は、プログラムで適切な CRT ヘッダーが組み込まれずにこれらの関数をローカルで宣言した場合にリンカー エラー (LNK2019、外部シンボルは未解決です) につながります。This breaking change leads to a linker error (LNK2019, unresolved external symbol) for any programs that declared these functions locally without including the appropriate CRT headers. 可能な場合、CRT ヘッダーが組み込まれるよう (つまり、#include <stdio.h> を追加するよう) またインライン関数が組み込まれるようコードを更新してください。これらのヘッダー ファイルが組み込まれるようコードを変更しない場合、別の方法として、付加的なライブラリをリンカー入力 legacy_stdio_definitions.lib に追加することもできます。If possible, you should update the code to include the CRT headers (that is, add #include <stdio.h>) and the inline functions, but if you do not want to modify your code to include these header files, an alternative solution is to add an additional library to your linker input, legacy_stdio_definitions.lib.

    このライブラリを IDE のリンカー入力に追加するには、プロジェクト ノードのコンテキスト メニューを開き、[プロパティ] を選択し、[プロジェクトのプロパティ] ダイアログ ボックスで [リンカー] を選択し、[リンカー入力] を編集して legacy_stdio_definitions.lib をセミコロン区切りリストに追加します。To add this library to your linker input in the IDE, open the context menu for the project node, choose Properties, then in the Project Properties dialog box, choose Linker, and edit the Linker Input to add legacy_stdio_definitions.lib to the semi-colon-separated list.

    プロジェクトが、2015 より前のリリースの Visual Studio でコンパイルされた静的ライブラリとリンクする場合、リンカーによって、未解決の外部シンボルが報告される可能性があります。If your project links with static libraries that were compiled with a release of Visual Studio earlier than 2015, the linker might report an unresolved external symbol. これらのエラー _iob _iob_func は、 <stdio.h> _imp_の形式で、、、または特定の関数の関連インポートの内部定義を参照する場合があり * ます。These errors might reference internal definitions for _iob, _iob_func, or related imports for certain <stdio.h> functions in the form of imp*. Microsoft は、プロジェクトをアップグレードするときに、最新バージョンの C++ コンパイラおよびライブラリですべての静的ライブラリを再コンパイルすることを推奨しています。Microsoft recommends that you recompile all static libraries with the latest version of the C++ compiler and libraries when you upgrade a project. ライブラリが、ソースを使用できないサード パーティ ライブラリである場合、更新されたバイナリをサード パーティから要求するか、そのライブラリの使用を、古いバージョンのコンパイラおよびライブラリでコンパイルする別個の DLL にカプセル化する必要があります。If the library is a third-party library for which source isn't available, you should either request an updated binary from the third party or encapsulate your usage of that library into a separate DLL that you compile with the older version of the compiler and libraries.

    警告

    Windows SDK 8.1 以前とリンクする場合、これらの未解決外部シンボル エラーが発生する可能性があります。If you are linking with Windows SDK 8.1 or earlier, you might encounter these unresolved external symbol errors. その場合、前述のように、legacy_stdio_definitions.lib をリンカー入力に追加することにより、エラーを解決する必要があります。In that case, you should resolve the error by adding legacy_stdio_definitions.lib to the linker input as described previously.

    未解決のシンボルエラーのトラブルシューティングを行うには、 dumpbin.exeを使用して、バイナリで定義されているシンボルを調べることができます。To troubleshoot unresolved symbol errors, you can try using dumpbin.exe to examine the symbols defined in a binary. 次のコマンド ラインを試行して、ライブラリで定義されているシンボルを表示してください。Try the following command line to view symbols defined in a library.

    dumpbin.exe /LINKERMEMBER somelibrary.lib
    
  • gets および _getwsgets and _getws

    gets 関数と _getws 関数が削除されました。The gets and _getws functions have been removed. gets 関数は、安全に使用できないため、C11 の標準ライブラリから削除されました。The gets function was removed from the C Standard Library in C11 because it can't be used securely. _getws 関数は、gets に相当する Microsoft 拡張です (ただしワイド文字列)。The _getws function was a Microsoft extension that was equivalent to gets but for wide strings. これらの関数の代わりとして、fgetsfgetwsgets_s、および _getws_s の使用を検討してください。As alternatives to these functions, consider use of fgets, fgetws, gets_s, and _getws_s.

  • _cgets および _cgetws_cgets and _cgetws

    _cgets 関数と _cgetws 関数は削除されました。The _cgets and _cgetws functions have been removed. これらの関数の代わりに、_cgets_s_cgetws_s の使用を検討してください。As alternatives to these functions, consider use of _cgets_s and _cgetws_s.

  • 無限大および NaN の書式設定Infinity and NaN Formatting

    以前のバージョンでは、無限大および NaNs は、MSVC 固有の sentinel 文字列のセットを使用して書式設定されていました。In previous versions, infinities and NaNs would be formatted using a set of MSVC-specific sentinel strings.

    • 無限大: 1.#INFInfinity: 1.#INF

    • 簡易な NaN: 1.#QNANQuiet NaN: 1.#QNAN

    • シグナリング NaN: 1.#SNANSignaling NaN: 1.#SNAN

    • 無限大 NaN: 1.#INDIndefinite NaN: 1.#IND

    これらの書式設定にはすべて、プレフィックスとして符号が付けられていた可能性があります。また、書式設定はフィールドの幅と精度に応じて若干異なる可能性があります (まれな例として、printf("%.2f\n", INFINITY) は 1.#J と出力されます。これは、#INF が 2 桁の精度に "丸められた" ためです)。Any of these formats may have been prefixed by a sign and may have been formatted slightly differently depending on field width and precision (sometimes with unusual effects, for example printf("%.2f\n", INFINITY) would print 1.#J because the #INF would be "rounded" to a 2-digit precision). C99 で、無限大と NaNs の書式設定の方法に関して新たな要件が導入されました。C99 introduced new requirements on how infinities and NaNs are to be formatted. 現在、MSVC の実装は、これらの要件に準拠しています。The MSVC implementation now conforms to these requirements. 新しい文字列は、次のとおりです。The new strings are as follows:

    • 無限台: infInfinity: inf

    • 簡易な NaN: nanQuiet NaN: nan

    • シグナリング NaN: nan(snan)Signaling NaN: nan(snan)

    • 不定値 NaN: nan(ind)Indefinite NaN: nan(ind)

    これらにはすべて、プレフィックスとして符号が付けられます。Any of these may be prefixed by a sign. 大文字の書式指定子が使用される場合 (%f ではなく %F)、文字列は大文字で出力されます (inf ではなく INF)。これは必須です。If a capitalized format specifier is used (%F instead of %f), then the strings are printed in capital letters (INF instead of inf), as is required.

    scanf 関数はこれらの新しい文字列を解析するよう変更され、これらの文字列は、printf および scanf によってラウンド トリップされます。The scanf functions have been modified to parse these new strings, so these strings now round-trip through printf and scanf.

  • 浮動小数点の書式設定と解析Floating point formatting and parsing

    新しい浮動小数点の書式設定と解析のアルゴリズムが導入され、正確性が向上しました。New floating point formatting and parsing algorithms have been introduced to improve correctness. この変更は、関数ファミリ printfscanfstrtod などの関数に影響を与えます。This change affects the printf and scanf families of functions, as well as functions like strtod.

    従来の書式設定アルゴリズムでは、限られた桁数のみを生成し、残りの小数点以下表示桁数はゼロで埋められていました。The old formatting algorithms would generate only a limited number of digits, then would fill the remaining decimal places with zero. 通常は、元の浮動小数点の値にラウンドトリップする文字列を生成できましたが、正確な値 (またはそれに最も近い 10 進表現) が必要な場合は十分ではありませんでした。They could usually generate strings that would round-trip back to the original floating point value, but weren't great if you wanted the exact value (or the closest decimal representation thereof). 新しい書式設定アルゴリズムでは、値を表す (または指定された有効桁数を埋める) ために必要な桁数が生成されます。The new formatting algorithms generate as many digits as are required to represent the value (or to fill the specified precision). 改善の一例として、大きな 2 の冪の出力結果をご覧ください。As an example of the improvement; consider the results when printing a large power of two:

    printf("%.0f\n", pow(2.0, 80))
    

    古い出力:Old output:

    1208925819614629200000000
    

    新しい出力:New output:

    1208925819614629174706176
    

    従来の解析アルゴリズムでは、入力文字列の最大 17 桁の有効桁数のみが考慮され、残りの桁は破棄されていました。The old parsing algorithms would consider only up to 17 significant digits from the input string and would discard the rest of the digits. 文字列によって表される値に近い概算値を生成するにはこれで十分であり、結果は通常、正しく丸められた結果に非常に近い値になっていました。This approach is sufficient to generate a close approximation of the value represented by the string, and the result is usually very close to the correctly rounded result. 新しい実装では、存在するすべての桁数を考慮に入れ、すべての入力を正しく丸めた結果が生成されます (最大長 768 桁)。The new implementation considers all present digits and produces the correctly rounded result for all inputs (up to 768 digits in length). 加えて、現在、これらの関数は丸めモードを採用しています (fesetround によって制御可能)。In addition, these functions now respect the rounding mode (controllable via fesetround). これらの関数は異なる結果を出力する可能性があるため、これは動作の破壊的変更になります。This is potentially a breaking behavior change because these functions might output different results. 新しい結果は常に、古い結果より正しくなります。The new results are always more correct than the old results.

  • 16 進数および無限大/NaN 浮動小数点の解析Hexadecimal and infinity/NaN floating point parsing

    前述のとおり、現在、浮動小数点の解析アルゴリズムは、16 進数の浮動小数点文字列 (%a および %A printf 書式指定子によって生成されるものなど) および printf 関数によって生成されるすべての無限大および NaN 文字列を解析します。The floating point parsing algorithms will now parse hexadecimal floating point strings (such as the ones generated by the %a and %A printf format specifiers) and all infinity and NaN strings that are generated by the printf functions, as described above.

  • %A および %a のゼロ パディング%A and %a zero padding

    %a および %A 書式指定子は、浮動小数点の数値を、16 進数の仮数部およびバイナリの指数として書式設定します。The %a and %A format specifiers format a floating point number as a hexadecimal mantissa and binary exponent. 以前のバージョンでは、printf 関数は文字列をゼロで埋め込んでいましたが、それは正しくありませんでした。In previous versions, the printf functions would incorrectly zero-pad strings. たとえば、printf("%07.0a\n", 1.0) は 00x1p+0 と出力されますが、本来、print 0x01p+0 と出力されるべきです。For example, printf("%07.0a\n", 1.0) would print 00x1p+0, where it should print 0x01p+0. この問題は修正されました。This flaw has been fixed.

  • %A と %a の有効桁数%A and %a precision

    %A と %a の書式指定子の既定の有効桁数は、以前のバージョンのライブラリでは 6 桁でした。The default precision of the %A and %a format specifiers was 6 in previous versions of the library. 現在、既定の有効桁数は、C 標準に準拠して 13 桁です。The default precision is now 13 for conformance with the C Standard.

    これは、%A または %a を持つ書式文字列を使用する関数の出力におけるランタイム動作の変更です。This is a runtime behavior change in the output of any function that uses a format string with %A or %a. 従来の動作では、%A 指定子を使用する出力は "1.1A2B3Cp+111" でした。In the old behavior, the output using the %A specifier might be "1.1A2B3Cp+111". 現在、同じ値の出力は "1.1A2B3C4D5E6F7p+111" です。Now the output for the same value is "1.1A2B3C4D5E6F7p+111". 従来の動作を取得するには、有効桁数を指定します (たとえば %.6A)。To get the old behavior, you can specify the precision, for example, %.6A. 精度指定」を参照してください。See Precision Specification.

  • %F 指定子%F specifier

    現在、%F 書式/変換指定子がサポートされています。The %F format/conversion specifier is now supported. 無限大と NaNs が大文字で書式設定される点を除き、機能的には %f 書式指定子と同等です。It's functionally equivalent to the %f format specifier, except that infinities and NaNs are formatted using capital letters.

    以前のバージョンでは、実装で F と N を長さの修飾子として使用していました。In previous versions, the implementation used to parse F and N as length modifiers. この動作は、アドレス空間がセグメント化されていた時代に由来するもので、これらの長さ修飾子は、遠近ポインター (それぞれ %Fp、%Ns) を示すために使用されていました。This behavior dated back to the age of segmented address spaces: these length modifiers were used to indicate far and near pointers, respectively, as in %Fp or %Ns. この動作は削除されました。This behavior has been removed. 現在、%F を検出した場合、%F 書式指定子として扱われます。%N を検出した場合、無効なパラメーターとして扱われます。If %F is encountered, it's now treated as the %F format specifier; if %N is encountered, it's now treated as an invalid parameter.

  • 指数の書式設定Exponent formatting

    %e および %E 書式指定子は、浮動小数点の数値を、10 進数の仮数部および指数として書式設定します。The %e and %E format specifiers format a floating point number as a decimal mantissa and exponent. 場合によっては、%g および %G 書式指定子もこの形式で数値を書式設定します。The %g and %G format specifiers also format numbers in this form in some cases. 以前のバージョンでは、CRT は 3 桁の指数部を持つ文字列を常に生成していました。In previous versions, the CRT would always generate strings with three-digit exponents. たとえば、printf("%e\n", 1.0) により 1.000000e+000 が出力されていましたが、これは正しくありませんでした。For example, printf("%e\n", 1.0) would print 1.000000e+000, which was incorrect. C では、指数部を 1 桁または 2 桁のみを使って表すことができる場合、2 桁のみを出力する必要があります。C requires that if the exponent is representable using only one or two digits, then only two digits are to be printed.

    Visual Studio 2005 では、グローバル準拠スイッチ _set_output_format が追加されました。In Visual Studio 2005 a global conformance switch was added: _set_output_format. プログラムは、この関数を引数 _TWO_DIGIT_EXPONENT を使って呼び出し、指数部出力の準拠を有効にすることができました。A program could call this function with the argument _TWO_DIGIT_EXPONENT, to enable conforming exponent printing. 既定の動作が変更され、標準に準拠する指数印刷モードに変更なりました。The default behavior has been changed to the standards-conforming exponent printing mode.

  • 書式文字列の検証Format string validation

    以前のバージョンでは、printf 関数と scanf 関数により、多くの無効な書式文字列が自動的に受け入れられていました。ただし、ときどき普通でない影響が生じていました。In previous versions, the printf and scanf functions would silently accept many invalid format strings, sometimes with unusual effects. たとえば、%hlhlhld は %d として扱われていました。For example, %hlhlhld would be treated as %d. 現在、無効な書式文字列はすべて、無効なパラメーターとして扱われます。All invalid format strings are now treated as invalid parameters.

  • fopen モードの文字列の検証fopen mode string validation

    以前のバージョンでは、fopen 関数ファミリにより、一部の無効なモード文字列が自動的に受け入れられていました (r+b+など)。In previous versions, the fopen family of functions silently accepted some invalid mode strings, such as r+b+. 現在、無効なモード文字列は検出され、無効なパラメーターとして扱われます。Invalid mode strings are now detected and treated as invalid parameters.

  • _O_U8TEXT モード_O_U8TEXT mode

    現在、_setmode 関数は、_O_U8TEXT モードで開かれるストリームのモードを正しく報告します。The _setmode function now correctly reports the mode for streams opened in_O_U8TEXT mode. 以前のバージョンのライブラリでは、そのようなストリームは _O_WTEXT で開かれるものとして報告されていました。In previous versions of the library, it would report such streams as being opened in _O_WTEXT.

    エンコードが UTF-8 のストリームの _O_WTEXT モードをコードが解釈する場合、これは互換性に影響する変更です。This is a breaking change if your code interprets the _O_WTEXT mode for streams where the encoding is UTF-8. アプリケーションで UTF_8 がサポートされていない場合、増加するこの共通エンコードのサポートを追加することを検討してください。If your application doesn't support UTF_8, consider adding support for this increasingly common encoding.

  • snprintf および vsnprintfsnprintf and vsnprintf

    現在、snprintf 関数と vsnprintf 関数が実装されています。The snprintf and vsnprintf functions are now implemented. 古いコードは CRT ライブラリによって実装されていなかったため、これらの関数の定義マクロ バージョンを提供していました。しかし、新しいバージョンではこれらが不要になりました。Older code often provided definitions macro versions of these functions because they were not implemented by the CRT library, but they're no longer needed in newer versions. を含める前にsnprintfまたはvsnprintfがマクロとして定義されている場合 <stdio.h> 、コンパイルが失敗し、マクロが定義された場所を示すエラーが表示されるようになりました。If snprintf or vsnprintf is defined as a macro before including <stdio.h>, compilation now fails with an error that indicates where the macro was defined.

    通常、この問題は、ユーザー コードの snprintf または vsnprintf の宣言を削除することによって修正されます。Normally, the fix to this problem is to delete any declarations of snprintf or vsnprintf in user code.

  • tmpnam は使用可能なファイル名を生成するtmpnam Generates Usable File Names

    以前のバージョンでは、tmpnam 関数および tmpnam_s 関数は、ドライブのルートにファイル名を生成していました (\sd3c など)。In previous versions, the tmpnam and tmpnam_s functions generated file names in the root of the drive (such as \sd3c.). 現在、これらの関数は、一時ディレクトリに使用可能なファイル名パスを生成します。These functions now generate usable file name paths in a temporary directory.

  • FILE カプセル化FILE Encapsulation

    以前のバージョンでは、完全なファイルの種類がでパブリックに定義されていた <stdio.h> ため、ユーザーコードがファイルに到着し、その内部を変更できるようになりました。In previous versions, the complete FILE type was defined publicly in <stdio.h>, so it was possible for user code to reach into a FILE and modify its internals. ライブラリが変更され、実装に関する詳細が隠されるようになりました。The library has been changed to hide implementation details. この変更の一環として、で定義されているように、ファイル <stdio.h> は不透明な型になり、そのメンバーは CRT 自体の外部からアクセスできなくなります。As part of this change, FILE as defined in <stdio.h> is now an opaque type and its members are inaccessible from outside of the CRT itself.

  • _outp および _inp_outp and _inp

    関数 _outp_outpw_outpd_inp_inpw、および _inpd が削除されました。The functions _outp, _outpw, _outpd, _inp, _inpw, and _inpd have been removed.

<stdlib.h>、<malloc.h>、<sys/stat.h><stdlib.h>, <malloc.h>, and <sys/stat.h>

  • strtof と wcstofstrtof and wcstof

    値を float として表せない場合に、strtof 関数および wcstof 関数で errno を ERANGE に設定できませんでした。The strtof and wcstof functions failed to set errno to ERANGE when the value wasn't representable as a float. このエラーはこれら 2 つの関数に固有のものでした。strtod 関数、wcstod 関数、strtold 関数、および wcstold 関数は影響を受けませんでした。This error was specific to these two functions; the strtod, wcstod, strtold, and wcstold functions were unaffected. この問題は修正されており、ランタイムの破壊的変更です。This issue has been fixed, and is a runtime breaking change.

  • 整列された割り当て関数Aligned allocation functions

    以前のバージョンでは、整列された割り当て関数 (_aligned_malloc_aligned_offset_malloc など) は、整列が 0 のブロックに関する要求を自動的に受け入れていました。In previous versions, the aligned allocation functions (_aligned_malloc, _aligned_offset_malloc, etc.) would silently accept requests for a block with an alignment of 0. 要求された整列は 2 のべき乗でなければならず、ゼロは不可でした。The requested alignment must be a power of two, which isn't true of zero. 整列が 0 の要求は現在、無効なパラメーターとして扱われます。A requested alignment of 0 is now treated as an invalid parameter. この問題は修正されており、ランタイムの破壊的変更です。This issue has been fixed, and is a runtime breaking change.

  • ヒープ関数Heap functions

    _heapadd 関数、_heapset 関数、および _heapused 関数は削除されました。The _heapadd, _heapset, and _heapused functions have been removed. Windows ヒープを使用するよう CRT が更新されたため、これらの関数は機能しなくなりました。These functions have been nonfunctional since the CRT was updated to use the Windows heap.

  • smallheapsmallheap

    smallheap リンク オプションは削除されました。The smallheap link option has been removed. Link Options」を参照してください。See Link Options.

<string.h>

  • wcstokwcstok

    wcstok 関数のシグネチャが変更され、C 標準で必要なものと一致するようになりました。The signature of the wcstok function has been changed to match what is required by the C Standard. 以前のバージョンのライブラリでは、この関数のシグネチャは次のとおりでした。In previous versions of the library, the signature of this function was:

    wchar_t* wcstok(wchar_t*, wchar_t const*)
    

    strtok と同様、これはスレッドごとの内部コンテキストを使用して、呼び出しの状態を追跡していました。It used an internal, per-thread context to track state across calls, as is done for strtok. 現在、この関数のシグネチャは wchar_t* wcstok(wchar_t*, wchar_t const*, wchar_t**) になり、呼び出し元は関数に対する 3 番目の引数としてコンテキストを渡すことが必須になりました。The function now has the signature wchar_t* wcstok(wchar_t*, wchar_t const*, wchar_t**), and requires the caller to pass the context as a third argument to the function.

    古いシグネチャとともに新しい _wcstok 関数が追加され、移植が簡単になりました。A new _wcstok function has been added with the old signature to ease porting. C++ コードをコンパイルする際にも、古いシグネチャを持つ wcstok のインライン オーバーロードが存在します。When compiling C++ code, there is also an inline overload of wcstok that has the old signature. このオーバーロードは、非推奨として宣言されます。This overload is declared as deprecated. C コードでは、_CRT_NON_CONFORMING_WCSTOK を定義し、wcstok の代わりに _wcstok が使用されるようにすることもできます。In C code, you may define_CRT_NON_CONFORMING_WCSTOK to cause _wcstok to be used in place of wcstok.

<time.h>

  • clockclock

    以前のバージョンでは、Windows API GetSystemTimeAsFileTime を使用して clock 関数が実装されていました。In previous versions, the clock function was implemented using the Windows API GetSystemTimeAsFileTime. この実装により、clock 関数はシステム時刻の影響を受け、単調になることがありませんでした。With this implementation, the clock function was sensitive to the system time, and was thus not necessarily monotonic. 現在は、 QueryPerformanceCounter によって clock 関数が再実装されたため、単調になっています。The clock function has been reimplemented in terms of QueryPerformanceCounter and is now monotonic.

  • fstat と _utimefstat and _utime

    以前のバージョンでは、_stat 関数、fstat関数、および _utime 関数での夏時間の処理が正しくありませんでした。In previous versions, the _stat, fstat, and _utime functions handle daylight savings time incorrectly. Visual Studio 2013 より前では、これらの関数はすべて、標準時刻をあたかも夏時間にあるかのようにに調整していましたが、これは正しい処理ではありませんでした。Prior to Visual Studio 2013, all of these functions incorrectly adjusted standard time times as if they were in daylight time.

    Visual Studio 2013 では、_stat 関数ファミリでは問題が解決されましたが、fstat 関数ファミリと _utime 関数ファミリでは修正されていませんでした。In Visual Studio 2013, the problem was fixed in the _stat family of functions, but the similar problems in the fstat and _utime families of functions were not fixed. この部分的な修正は、関数間の不整合による問題につながっていました。This partial fix led to problems due to the inconsistency between the functions. fstat および _utime の関数ファミリは現在修正され、これらすべての関数が、正確かつ一貫して夏時間を処理できるようになりました。The fstat and _utime families of functions have now been fixed, so all of these functions now handle daylight savings time correctly and consistently.

  • asctimeasctime

    以前のバージョンでは、asctime 関数は、1 桁の日の先頭をゼロで埋めていました (たとえば、Fri Jun 06 08:00:00 2014)。In previous versions, the asctime function would pad single-digit days with a leading zero, for example: Fri Jun 06 08:00:00 2014. この仕様では、そのような日の先頭を空白で埋める必要があります (たとえば、Fri Jun 6 08:00:00 2014)。The specification requires that such days be padded with a leading space, as in Fri Jun 6 08:00:00 2014. この問題は修正されています。This issue has been fixed.

  • strftime および wcsftimestrftime and wcsftime

    strftime 関数と wcsftime 関数は、書式指定子として %C、%D、%e、%F、%g、%G、%h、%n、%r、%R、%t、%T、%u、および %V をサポートしています。The strftime and wcsftime functions now support the %C, %D, %e, %F, %g, %G, %h, %n, %r, %R, %t, %T, %u, and %V format specifiers. さらに、E 修飾子と O 修飾子は、解析はされますが、無視されます。Additionally, the E and O modifiers are parsed but ignored.

    %c 書式指定子は、現行ロケールの "適切な日時の表記" を生成するものとして指定されます。The %c format specifier is specified as producing an "appropriate date and time representation" for the current locale. C ロケールでは、asctime で生成されるのと同じ書式である %a %b %e %T %Y と同じになるよう、この表記が必要です。In the C locale, this representation is required to be the same as %a %b %e %T %Y, the same form as is produced by asctime. 以前のバージョンでは、%c 書式指定子は MM/DD/YY HH:MM:SS 表記を使用して時刻を書式設定していましたが、これは正しくありませんでした。In previous versions, the %c format specifier incorrectly formatted times using a MM/DD/YY HH:MM:SS representation. この問題は修正されています。This issue has been fixed.

  • timespec と TIME_UTCtimespec and TIME_UTC

    ヘッダーは、 <time.h> timespec C11 標準の型と関数を定義するようになりました timespec_getThe <time.h> header now defines the timespec type and the timespec_get function from the C11 Standard. さらに、現在、timespec_get 関数で使用する TIME_UTC マクロが定義されています。In addition, the TIME_UTC macro, for use with the timespec_get function, is now defined. この更新は、その識別子のいずれかの定義が競合しているコードに関して、破壊的変更です。This update is a breaking change for code that has a conflicting definition for any of these identifiers.

  • CLOCKS_PER_SECCLOCKS_PER_SEC

    現在、CLOCKS_PER_SEC マクロは clock_t 型の整数に拡張されており、これは C 言語で必要です。The CLOCKS_PER_SEC macro now expands to an integer of type clock_t, as required by the C language.

C++ 標準ライブラリC++ Standard Library

新しい最適化とデバッグのチェックを有効にするために、C++ 標準ライブラリの Visual Studio の実装では、バイナリの互換性がバージョンごとに意図的に保たれていません。To enable new optimizations and debugging checks, the Visual Studio implementation of the C++ Standard Library intentionally breaks binary compatibility from one version to the next. そのため、C++ 標準ライブラリを使用すると、異なるバージョンを使用してコンパイルされたオブジェクト ファイルとスタティック ライブラリは 1 つのバイナリ (EXE または DLL) に混在させることができず、C++ 標準ライブラリ オブジェクトは異なるバージョンを使用してコンパイルされたバイナリ間で渡すことができません。Therefore, when the C++ Standard Library is used, object files and static libraries that are compiled by using different versions can't be mixed in one binary (EXE or DLL), and C++ Standard Library objects can't be passed between binaries that are compiled by using different versions. 混在があると、_MSC_VER の不一致に関するリンカー エラーが発生しますSuch mixing emits linker errors about _MSC_VER mismatches. (_MSC_VER は、コンパイラのメジャーバージョンを含むマクロです。たとえば、Visual Studio 2013 の場合は1800です)。このチェックでは、DLL の混在を検出できず、Visual Studio 2008 以前のバージョンを含む混在を検出することはできません。(_MSC_VER is the macro that contains the compiler's major version—for example, 1800 for Visual Studio 2013.) This check can't detect DLL mixing, and can't detect mixing that involves Visual Studio 2008 or earlier.

  • C++ 標準ライブラリ インクルード ファイルC++ Standard Library include files

    C++ 標準ライブラリのヘッダーのインクルード構造に対していくつかの変更が加えられました。Some changes have been made to the include structure in the C++ Standard Library headers. C++ 標準ライブラリ ヘッダーは、指定されていない方法での相互インクルードを許可されています。C++ Standard Library headers are allowed to include each other in unspecified ways. 一般に、C++ 標準に応じて必要なすべてのヘッダーを注意深くインクルードし、どの C++ 標準ライブラリ ヘッダーにどの C++ 標準ライブラリ ヘッダーが含まれるかは関係ないようにするようコードを記述する必要があります。In general, you should write your code so that it carefully includes all of the headers that it needs according to the C++ standard, and doesn't rely on which C++ Standard Library headers include which other C++ Standard Library headers. これにより、バージョン間およびプラットフォーム間でのコードの移植が可能になります。This makes code portable across versions and platforms. 少なくとも Visual Studio 2015 でのヘッダーに関する 2 つの変更がユーザー コードに影響を与えます。At least two header changes in Visual Studio 2015 affect user code. 最初に、 <string> が含まれなくなりました <iterator> 。First, <string> no longer includes <iterator>. 次に、は、を <tuple> std::array すべて含めずに宣言し <array> ます。コードには、"array" という名前の変数が含まれています。コードには "array" という名前の変数があり、using ディレクティブ "using namespace std;" があり、によって宣言されたを含む C++ 標準ライブラリヘッダー (など) が含まれ <functional> <tuple> std::array ます。Second, <tuple> now declares std::array without including all of <array>, which can break code through the following combination of code constructs: your code has a variable named "array", and you have a using-directive "using namespace std;", and you include a C++ Standard Library header (such as <functional>) that includes <tuple>, which now declares std::array.

  • steady_clocksteady_clock

    <chrono> Steady_clockの実装は、安定性および単調性の C++ 標準要件を満たすように変更されました。The <chrono> implementation of steady_clock has changed to meet the C++ Standard requirements for steadiness and monotonicity. 現在、steady_clockQueryPerformanceCounter() に基づき、high_resolution_clocksteady_clock の typedef です。steady_clock is now based on QueryPerformanceCounter and high_resolution_clock is now a typedef for steady_clock. 結果として、Visual Studio では現在、steady_clock::time_pointchrono::time_point<steady_clock> の typedef です。ただし、他の実装では異なる場合があります。As a result, in Visual Studio steady_clock::time_point is now a typedef for chrono::time_point<steady_clock>; however, this isn't necessarily the case for other implementations.

  • アロケーターおよび constallocators and const

    現在、両サイドで const 引数を受け入れるには、アロケーターの等価/非等価の比較が必要です。We now require allocator equality/inequality comparisons to accept const arguments on both sides. アロケーターがこれらの演算子をこのように定義する場合、If your allocators define these operators like this,

    bool operator==(const MyAlloc& other)
    

    それを更新して、const メンバーとして宣言する必要があります。then you should update them and declare them as const members:

    bool operator==(const MyAlloc& other) const
    
  • const 要素const elements

    C++ 標準では、常に const 要素 (vector や set など) のコンテナーが禁止されてい <const T> <const T> ます。The C++ standard has always forbidden containers of const elements (such as vector<const T> or set<const T>). Visual Studio 2013 以前では、そのようなコンテナーが受け入れられていました。Visual Studio 2013 and earlier accepted such containers. 現在のバージョンでは、そのようなコンテナーをコンパイルすることはできません。In the current version, such containers fail to compile.

  • std::allocator::deallocatestd::allocator::deallocate

    Visual Studio 2013 以前では、std::allocator::deallocate(p, n) は、n に対して渡されていた引数を無視していました。In Visual Studio 2013 and earlier, std::allocator::deallocate(p, n) ignored the argument passed in for n. C++ 標準では常に、p を返した allocate の呼び出しに最初の引数として渡される値と n が同等である必要がありました。The C++ standard has always required that n must be equal to the value passed as the first argument to the invocation of allocate which returned p. ただし、現在のバージョンでは、 nの値は検査されます。However, in the current version, the value of n is inspected. 標準で必要なものとは異なる引数を n に渡すコードは、ランタイムにクラッシュする可能性があります。Code that passes arguments for n that differ from what the standard requires might crash at runtime.

  • hash_map および hash_sethash_map and hash_set

    非標準ヘッダーファイル <hash_map> とは、 <hash_set> Visual Studio 2015 で非推奨とされており、今後のリリースでは削除される予定です。The non-standard header files <hash_map> and <hash_set> are deprecated in Visual Studio 2015 and will be removed in a future release. 代わりに、<unordered_map> および <unordered_set> を使用してください。Use <unordered_map> and <unordered_set> instead.

  • 比較子および operator()comparators and operator()

    連想コンテナー ( <map> ファミリ) では、比較子に const 呼び出し可能な関数呼び出し演算子が必要になりました。Associative containers (the <map> family) now require their comparators to have const-callable function call operators. 比較子クラス宣言の次のコードは現在、コンパイルに失敗します。The following code in a comparator class declaration now fails to compile:

    bool operator()(const X& a, const X& b)
    

    このエラーを解決するには、関数の宣言を次のように変更します。To resolve this error, change the function declaration to:

    bool operator()(const X& a, const X& b) const
    
  • 型の特徴type traits

    以前のバージョンの C++ ドラフト標準の型の特徴の古い名前が削除されました。The old names for type traits from an earlier version of the C++ draft standard have been removed. これらは C++11 で変更されており、Visual Studio 2015 では C++11 値に更新されました。These were changed in C++11 and have been updated to the C++11 values in Visual Studio 2015. 古い名前と新しい名前を次の表に示します。The following table shows the old and new names.

    以前の名前Old name 新しい名前New name
    add_referenceadd_reference add_lvalue_referenceadd_lvalue_reference
    has_default_constructorhas_default_constructor is_default_constructibleis_default_constructible
    has_copy_constructorhas_copy_constructor is_copy_constructibleis_copy_constructible
    has_move_constructorhas_move_constructor is_move_constructibleis_move_constructible
    has_nothrow_constructorhas_nothrow_constructor is_nothrow_default_constructibleis_nothrow_default_constructible
    has_nothrow_default_constructorhas_nothrow_default_constructor is_nothrow_default_constructibleis_nothrow_default_constructible
    has_nothrow_copyhas_nothrow_copy is_nothrow_copy_constructibleis_nothrow_copy_constructible
    has_nothrow_copy_constructorhas_nothrow_copy_constructor is_nothrow_copy_constructibleis_nothrow_copy_constructible
    has_nothrow_move_constructorhas_nothrow_move_constructor is_nothrow_move_constructibleis_nothrow_move_constructible
    has_nothrow_assignhas_nothrow_assign is_nothrow_copy_assignableis_nothrow_copy_assignable
    has_nothrow_copy_assignhas_nothrow_copy_assign is_nothrow_copy_assignableis_nothrow_copy_assignable
    has_nothrow_move_assignhas_nothrow_move_assign is_nothrow_move_assignableis_nothrow_move_assignable
    has_trivial_constructorhas_trivial_constructor is_trivially_default_constructibleis_trivially_default_constructible
    has_trivial_default_constructorhas_trivial_default_constructor is_trivially_default_constructibleis_trivially_default_constructible
    has_trivial_copyhas_trivial_copy is_trivially_copy_constructibleis_trivially_copy_constructible
    has_trivial_move_constructorhas_trivial_move_constructor is_trivially_move_constructibleis_trivially_move_constructible
    has_trivial_assignhas_trivial_assign is_trivially_copy_assignableis_trivially_copy_assignable
    has_trivial_move_assignhas_trivial_move_assign is_trivially_move_assignableis_trivially_move_assignable
    has_trivial_destructorhas_trivial_destructor is_trivially_destructibleis_trivially_destructible
  • launch::any ポリシーと launch::sync ポリシーlaunch::any and launch::sync policies

    非標準の launch::anylaunch::sync のポリシーが削除されました。The nonstandard launch::any and launch::sync policies were removed. 代わりに、launch::any に対して、launch:async | launch:deferred を使用します。Instead, for launch::any, use launch:async | launch:deferred. launch::sync では launch::deferred を使用します。For launch::sync, use launch::deferred. launch 列挙型」を参照してください。See launch Enumeration.

MFC と ATLMFC and ATL

  • Microsoft Foundation Classes (MFC)Microsoft Foundation Classes (MFC)

    はサイズが大きすぎるため、Visual Studio の "標準" インストールから除外されました。is no longer included in a "Typical" install of Visual Studio because of its large size. MFC をインストールするには、Visual Studio 2015 セットアップでカスタム インストール オプションを選択します。To install MFC, choose the Custom install option in Visual Studio 2015 setup. 既に Visual Studio 2015 がインストールされている場合は、Visual Studio セットアップを再度実行して MFC をインストールできます。If you already have Visual Studio 2015 installed, you can install MFC by running Visual Studio setup again. カスタム インストール オプションを選択してから、Microsoft Foundation Classes を選択します。Choose the Custom install option, and then choose Microsoft Foundation Classes. Visual Studio セットアップの実行は、コントロール パネルのコントロールであるプログラムと機能か、インストール メディアからすることができます。You can run Visual Studio setup from the Control Panel control Programs and Features, or from the installation media.

    Visual C++ 再頒布可能パッケージにも、引き続きこのライブラリが含まれています。The Visual C++ Redistributable Package still includes this library.

同時実行ランタイムConcurrency Runtime

  • concurrency::Context::Yield と競合する Windows.h の Yield マクロYield macro from Windows.h conflicting with concurrency::Context::Yield

    以前、同時実行ランタイムは #undef を使用して Yield マクロの定義を解除し、Windows.h h で定義されている Yield マクロと concurrency::Context::Yield 関数の間の競合を回避していました。The Concurrency Runtime previously used #undef to undefine the Yield macro to avoid conflicts between the Yield macro defined in Windows.h h and the concurrency::Context::Yield function. この #undef は削除され、競合しない同等の新しい API 呼び出し concurrency::Context::YieldExecution が追加されました。This #undef has been removed and a new non-conflicting equivalent API call concurrency::Context::YieldExecution has been added. Yield との競合を回避するには、コードを更新して代わりに YieldExecution 関数を呼び出すか、次の例に示すように、呼び出しサイトで Yield 関数名をかっこで囲みます。To work around conflicts with Yield, you can either update your code to call the YieldExecution function instead, or surround the Yield function name with parentheses at call sites, as in the following example:

    (concurrency::Context::Yield)();
    

Visual Studio 2015 のコンパイラ準拠の強化Compiler Conformance Improvements in Visual Studio 2015

以前のバージョンからコードをアップグレードすると、Visual Studio 2015 の準拠に関する強化によるコンパイラ エラーが生じる可能性があります。When upgrading code from previous versions, you might also encounter compiler errors that are due to conformance improvements made in Visual Studio 2015. これらの強化は、旧バージョンの Visual Studio からのバイナリの互換性に影響する変更ではありませんが、以前にはないコンパイラ エラーが発生する可能性があります。These improvements do not break binary compatibility from earlier versions of Visual Studio, but they can produce compiler errors where none were emitted before. 詳細については、「Visual C++ 2003 ~ 2015 の新機能」を参照してください。For more information, see Visual C++ What's New 2003 through 2015.

Visual Studio 2015 では、コンパイラの準拠に関する継続的な強化によって、コンパイラが既存のソース コードを認識する方法が変わる可能性があります。In Visual Studio 2015, ongoing improvements to compiler conformance can sometimes change how the compiler understands your existing source code. その結果、以前にビルドして問題なく実行できていたコードでも、ビルド時に新しいエラーや異なるエラーが発生したり、動作が変わったりする可能性があります。As a result, you might encounter new or different errors during your build, or even behavioral differences in code that previously built and seemed to run correctly.

さいわい、これらの相違点は、ほとんどのソース コードにおいて、ほとんどまたは全く影響を与えません。Fortunately, these differences have little or no impact on most of your source code. これらの相違点に対処するためにソース コードまたはその他の変更が必要な場合、修正は小さく簡単なものになる傾向があります。When source code or other changes are needed to address these differences, the fixes tend to be small and straight-forward. 以前は問題がなかったソース コードで、変更が必要な (修正前の) コード例と、正しい (修正後の) コード例を多数紹介します。We've included many examples of previously acceptable source code that might need to be changed (before) and the fixes to correct them (after).

これらの変更点はソース コードや他のビルド成果物に影響はあっても、Visual Studio の異なるバージョン間のバイナリの互換性には影響がありません。Although these differences can affect your source code or other build artifacts, they don't affect binary compatibility between updates to Visual Studio versions. 破壊的変更はより重大で、バイナリの互換性に影響が及ぶ可能性がありますが、このようなバイナリの互換性に影響する変更は、Visual Studio 2013 と Visual Studio 2015 など、Visual Studio のメジャー バージョンが異なる場合にのみ発生します。A breaking change is more severe, and can affect binary compatibility, but these kinds of binary compatibility breaks only occur between major versions of Visual Studio, for example, between Visual Studio 2013 and Visual Studio 2015. Visual Studio 2013 と Visual Studio 2015 の間の互換性に影響する変更点については、「Visual Studio 2015 の準拠に関する変更」を参照してください。For information on the breaking changes that occurred between Visual Studio 2013 and Visual Studio 2015, see Visual Studio 2015 Conformance Changes.

Visual Studio 2015 での準拠の強化Conformance Improvements in Visual Studio 2015

  • /Zc:forScope - オプション/Zc:forScope- option

    コンパイラ オプション /Zc:forScope- は非推奨となりました。今後のリリースからは削除されます。The compiler option /Zc:forScope- is deprecated and will be removed in a future release.

    Command line warning  D9035: option 'Zc:forScope-' has been deprecated and will be removed in a future release
    

    このオプションは通常、標準ではスコープから外れるポイントの後のループ変数を使用する、非標準のコードを許可するために使用されていました。Usually, this option was used in order to allow nonstandard code that uses loop variables after the point where, according to the standard, they should have gone out of scope. これは /Za オプションを使ってコンパイルするときにのみ必要でした。/Za がない場合は、ループの後でも常に for ループ変数が使用できるからです。It was only necessary when you compiled with the /Za option, since without /Za, use of a for loop variable after the end of the loop is always allowed. 標準への準拠を考慮しない場合 (たとえば、コードを他のコンパイラに移植しない場合)、/Za オプションをオフにする (または、[言語拡張機能の無効化] プロパティを [いいえ] に設定する) こともできます。If you don't care about standards conformance (for example, if your code isn't meant to portable to other compilers), you could turn off the /Za option (or set the Disable Language Extensions property to No). 移植可能で標準に準拠したコードの記述を考慮する場合、標準に準拠するようコードを再記述する必要があります。そのためには、変数の宣言をループの外側に移動します。If you do care about writing portable, standards-compliant code, you should rewrite your code so that it conforms to the standard by moving the declaration of such variables to a point outside the loop.

    // C2065 expected
    int main() {
        // Uncomment the following line to resolve.
        // int i;
        for (int i = 0; i < 1; i++);
        i = 20;   // i has already gone out of scope under /Za
    }
    
  • /Zg コンパイラ オプション/Zg compiler option

    /Zg コンパイラ オプション (関数プロトタイプの生成) は使用できなくなりました。The /Zg compiler option (Generate Function Prototypes) is no longer available. 前バージョンで、このコンパイラ オプションは非推奨とされました。This compiler option was previously deprecated.

  • mstest.exe のコマンド ラインから C++/CLI で単体テストを実行できなくなりました。You can no longer run unit tests with C++/CLI from the command line with mstest.exe. 代わりに、vstest.console.exe を使用します。Instead, use vstest.console.exe. VSTest.Console.exe のコマンド ライン オプション」を参照してください。See VSTest.Console.exe command-line options.

  • mutable キーワードmutable keyword

    mutable ストレージクラス指定子は、以前にエラーなしでコンパイルされた場所では使用できなくなりました。The mutable storage class specifier is no longer allowed in places where previously it compiled without error. 現在、コンパイラによってエラー C2071 (無効なストレージ クラス) が出されます。Now, the compiler gives error C2071 (illegal storage class). 標準に従って、 mutable 指定子はクラスのデータメンバーの名前にのみ適用でき、const または static として宣言された名前には適用できません。また、参照メンバーには適用できません。According to the standard, the mutable specifier can be applied only to names of class data members, and can't be applied to names declared const or static, and can't be applied to reference members.

    次に例を示します。For example, consider the following code:

    struct S
    {
        mutable int &r;
    };
    

    以前のバージョンのコンパイラはこれを受け入れていましたが、現在のコンパイラでは次のエラーが出されます。Previous versions of the compiler accepted this, but now the compiler gives the following error:

    error C2071: 'S::r': illegal storage class
    

    このエラーを解決するには、冗長なキーワードを削除し mutable ます。To fix the error, remove the redundant mutable keyword.

  • char_16_t と char32_tchar_16_t and char32_t

    char16_t ではまたはを char32_t 別名として使用できなく typedef なりました。これらの型は現在、組み込みとして扱われるためです。You can no longer use char16_t or char32_t as aliases in a typedef, because these types are now treated as built-in. ユーザーとライブラリの作成者が、 char16_t char32_t それぞれおよびのエイリアスとしてとを定義するのは一般的でした uint16_t uint32_tIt was common for users and library authors to define char16_t and char32_t as aliases of uint16_t and uint32_t, respectively.

    #include <cstdint>
    
    typedef uint16_t char16_t; //C2628
    typedef uint32_t char32_t; //C2628
    
    int main(int argc, char* argv[])
    {
        uint16_t x = 1; uint32_t y = 2;
        char16_t a = x;
        char32_t b = y;
        return 0;
    }
    

    コードを更新するには、 typedef 宣言を削除し、これらの名前と競合するその他の識別子の名前を変更します。To update your code, remove the typedef declarations and rename any other identifiers that collide with these names.

  • 非型テンプレート パラメーターNon-type template parameters

    非型テンプレート パラメーターを含む特定のコードは現在、明示的なテンプレート引数を指定すると、型の互換性について正しくチェックされます。Certain code that involves non-type template parameters is now correctly checked for type compatibility when you provide explicit template arguments. たとえば、次のコードは、以前のバージョンの Visual Studio でエラーなしでコンパイルしたものです。For example, the following code compiled without error in previous versions of Visual Studio.

    struct S1
    {
        void f(int);
        void f(int, int);
    };
    
    struct S2
    {
        template <class C, void (C::*Function)(int) const> void f() {}
    };
    
    void f()
    {
        S2 s2;
        s2.f<S1, &S1::f>();
    }
    

    現在のコンパイラは、正しくエラーを出します。テンプレート パラメーターの型がテンプレートの引数と一致しないからです (パラメーターは const メンバーへのポインターですが、関数 f は非 const です)。The current compiler correctly gives an error, because the template parameter type doesn't match the template argument (the parameter is a pointer to a const member, but the function f is non-const):

    error C2893: Failed to specialize function template 'void S2::f(void)'note: With the following template arguments:note: 'C=S1'note: 'Function=S1::f'
    

    コードのこのエラーに対処するには、使用するテンプレート引数の型が、テンプレート パラメーターの宣言された型と一致することを確認してください。To address this error in your code, make sure that the type of the template argument you use matches the declared type of the template parameter.

  • __declspec(align)

    コンパイラは関数で __declspec(align) を受け入れなくなりました。The compiler no longer accepts __declspec(align) on functions. このコンストラクトは常に無視されていましたが、コンパイラ エラーを生成するようになりました。This construct was always ignored, but now it produces a compiler error.

    error C3323: 'alignas' and '__declspec(align)' are not allowed on function declarations
    

    この問題を修正するには、関数の宣言から __declspec(align) を削除してください。To fix this problem, remove __declspec(align) from the function declaration. これは影響がなかったため、削除しても何も変わりません。Since it had no effect, removing it doesn't change anything.

  • 例外処理Exception handling

    例外処理への変更がいくつかあります。There are a couple of changes to exception handling. まず、例外オブジェクトはコピー可能または移動可能にする必要があります。First, exception objects have to be either copyable or movable. 次のコードは、Visual Studio 2013 ではコンパイルされますが、Visual Studio 2015 ではコンパイルされません。The following code compiled in Visual Studio 2013, but doesn't compile in Visual Studio 2015:

    struct S
    {
    public:
        S();
    private:
        S(const S &);
    };
    
    int main()
    {
        throw S(); // error
    }
    

    問題は、コピー コンストラクターはプライベートであるために通常の例外処理とは異なりオブジェクトをコピーできないことです。The problem is that the copy constructor is private, so the object can't be copied as happens in the normal course of handling an exception. コピーコンストラクターが宣言されている場合も同じことが当てはまり explicit ます。The same applies when the copy constructor is declared explicit.

    struct S
    {
        S();
        explicit S(const S &);
    };
    
    int main()
    {
        throw S(); // error
    }
    

    コードを更新するには、例外オブジェクトのコピーコンストラクターがで、マークされていないことを確認し public explicit ます。To update your code, make sure that the copy constructor for your exception object is public and not marked explicit.

    値によって例外をキャッチする場合も、例外オブジェクトをコピー可能にする必要があります。Catching an exception by value also requires the exception object to be copyable. 次のコードは、Visual Studio 2013 ではコンパイルされますが、Visual Studio 2015 ではコンパイルされません。The following code compiled in Visual Studio 2013, but doesn't compile in Visual Studio 2015:

    struct B
    {
    public:
        B();
    private:
        B(const B &);
    };
    
    struct D : public B {};
    
    int main()
    {
        try
        {
        }
        catch (D d) // error
        {
        }
    }
    

    この問題を解決するには、のパラメーターの型 catch を参照に変更します。You can fix this issue by changing the parameter type for the catch to a reference.

    catch (D& d)
    {
    }
    
  • マクロに続く文字列リテラルString literals followed by macros

    このバージョンでは、コンパイラはユーザー定義リテラルをサポートするようになりました。The compiler now supports user-defined literals. その結果、空白文字の介入がないマクロに続く文字列リテラルはユーザー定義のリテラルとして解釈されます。これにより、エラーまたは予期しない結果が起こる可能性があります。As a consequence, string literals followed by macros without any intervening whitespace are interpreted as user-defined literals, which might produce errors or unexpected results. たとえば、以前のコンパイラでは次のコードが正常にコンパイルされていました。For example, in previous compilers the following code compiled successfully:

    #define _x "there"
    char* func() {
        return "hello"_x;
    }
    int main()
    {
        char * p = func();
        return 0;
    }
    

    コンパイラはこのコードを、マクロに続く "hello" というリテラル文字列として解釈していました。これは "there" に拡張され、2 つの文字列リテラルが 1 つに連結されていました。The compiler interpreted this code as a string literal "hello" followed by a macro, which is expanded into "there", and then the two string literals were concatenated into one. Visual Studio 2015 では、コンパイラはこのシーケンスをユーザー定義リテラルと解釈しますが、一致するユーザー定義リテラル _x が定義されていないため、エラーになります。In Visual Studio 2015, the compiler interprets this sequence as a user-defined literal, but since there is no matching user-defined literal _x defined, it gives an error.

    error C3688: invalid literal suffix '_x'; literal operator or literal operator template 'operator ""_x' not found
    note: Did you forget a space between the string literal and the prefix of the following string literal?
    

    この問題を解決するには、文字列リテラルとマクロの間に空白に追加します。To fix this problem, add a space between the string literal and the macro.

  • 隣接する文字列リテラルAdjacent string literals

    以前と同様、文字列の解析に関連する変更のため、空白なしの隣接する文字列リテラル (ワイド文字列リテラルまたはナロー文字列リテラルのいずれか) は、以前のバージョンの Visual C++ では、単一の連結文字列と解釈されていました。Similarly to the previous, due to related changes in string parsing, adjacent string literals (either wide or narrow character string literals) without any whitespace were interpreted as a single concatenated string in previous releases of Visaul C++. Visual Studio 2015 では、2 つの文字列間に空白を追加する必要があります。In Visual Studio 2015, you must now add whitespace between the two strings. たとえば、次のコードを変更する必要があります。For example, the following code must be changed:

    char * str = "abc""def";
    

    この問題を修正するには、2 つの文字列間に空白を追加します。To fix this issue, add a space in between the two strings:

    char * str = "abc" "def";
    
  • placement new と deletePlacement new and delete

    delete C++ 14 標準に準拠するために、演算子が変更されました。A change has been made to the delete operator in order to bring it into conformance with C++14 standard. 標準の変更について詳しくは、「 C++ サイズの割り当て解除」をご覧ください。Details of the standards change can be found at C++ Sized Deallocation. 変更により、サイズパラメーターを受け取るグローバル演算子のフォームが追加され delete ます。The changes add a form of the global delete operator that takes a size parameter. 互換性に影響する変更点として、以前に delete 同じシグネチャを持つ演算子を ( placement new演算子に対応するために) 使用していた場合、コンパイラエラー (C2956 は、配置 new が使用されている位置で発生します。これは、コンパイラが適切な一致演算子を識別しようとするコード内の位置であるためです delete )The breaking change is that if you were previously using an operator delete with the same signature (to correspond with a placement new operator), you will receive a compiler error (C2956, which occurs at the point where the placement new is used, since that's the position in code where the compiler tries to identify an appropriate matching delete operator).

    関数 void operator delete(void *, size_t) は、C++11 の placement new 関数 void * operator new(size_t, size_t) に対応する placement delete 演算子でした。The function void operator delete(void *, size_t) was a placement delete operator corresponding to the placement new function void * operator new(size_t, size_t) in C++11. C++ 14 サイズの割り当て解除では、この delete 関数は通常の解放関数(グローバル演算子) になりました deleteWith C++14 sized deallocation, this delete function is now a usual deallocation function (global delete operator). 標準では、placement new の使用で対応する delete 関数を検索し、通常の解放関数を見つけた場合、プログラムの形式が不適切である必要があります。The standard requires that if the use of a placement new looks up a corresponding delete function and finds a usual deallocation function, the program is ill-formed.

    たとえば、コードで placement newplacement delete の両方を定義するとします。For example, suppose your code defines both a placement new and a placement delete:

    void * operator new(std::size_t, std::size_t);
    void operator delete(void*, std::size_t) noexcept;
    

    この問題が発生するのは、定義したplacement delete演算子と新しいグローバルサイズ演算子の間の関数シグネチャが一致したため delete です。The problem occurs because of the match in function signatures between a placement delete operator you've defined, and the new global sized delete operator. 別の型を使用できるかどうかを検討してください、 size_t 配置の新しいdelete 演算子。Consider whether you can use a different type other than size_t for any placement new and delete operators. の型 size_t typedef はコンパイラに依存しており、MSVC の typedef のです unsigned intThe type of the size_t typedef is compiler-dependent; it's a typedef for unsigned int in MSVC. 適切なソリューションでは、次のように列挙型を使用します。A good solution is to use an enumerated type such as this one:

    enum class my_type : size_t {};
    

    次に、 placement newの定義を変更し、 delete この型をの代わりに2番目の引数として使用するように変更し size_t ます。Then, change your definition of placement new and delete to use this type as the second argument instead of size_t. また、placement new の呼び出しを更新して新しい型を渡す (たとえば、を使用して static_cast<my_type> 整数値から変換する) 必要があります。また、との定義を更新し、 new delete 整数型にキャストバックする必要もあります。You'll also need to update the calls to placement new to pass the new type (for example, by using static_cast<my_type> to convert from the integer value) and update the definition of new and delete to cast back to the integer type. このためにを使用する必要はありません enum 。メンバーを持つクラス型 size_t も機能します。You don't need to use an enum for this; a class type with a size_t member would also work.

    代わりの方法として、placement new を完全に除去することもできます。An alternative solution is that you might be able to eliminate the placement new altogether. 配置の引数が割り当てまたは削除されるオブジェクトのサイズであるメモリプールを実装するために、配置の新しい機能が使用されている場合、サイズの割り当て解除機能は、独自のカスタムメモリプールコードを置き換えるのに適しています。また、配置関数の代わりに独自の2つの引数演算子を使用することもでき delete ます。If your code uses placement new to implement a memory pool where the placement argument is the size of the object being allocated or deleted, then sized deallocation feature might be suitable to replace your own custom memory pool code, and you can get rid of the placement functions and just use your own two-argument delete operator instead of the placement functions.

    コードを即時に更新しない場合は、コンパイラ オプション /Zc:sizedDealloc- を使用して、従来の動作に戻すことができます。If you don't want to update your code immediately, you can revert to the old behavior by using the compiler option /Zc:sizedDealloc-. このオプションを使用すると、2つの引数を持つ delete 関数は存在せず、 placement delete演算子との競合は発生しません。If you use this option, the two-argument delete functions don't exist and won't cause a conflict with your placement delete operator.

  • 共用体データ メンバーUnion data members

    共用体データ メンバーで参照型を使用することはできなくなりました。Data members of unions can no longer have reference types. 次のコードは Visual Studio 2013 では正常にコンパイルされますが、Visual Studio 2015 ではエラーになります。The following code compiled successfully in Visual Studio 2013, but produces an error in Visual Studio 2015.

    union U1
    {
        const int i;
    };
    union U2
    {
        int & i;
    };
    union U3
    {
        struct { int & i; };
    };
    

    上のコードを実行すると、次のエラーが生成されます。The preceding code produces the following errors:

    test.cpp(67): error C2625: 'U2::i': illegal union member; type 'int &' is reference type
    test.cpp(70): error C2625: 'U3::i': illegal union member; type 'int &' is reference type
    

    この問題に対処するには、参照型をポインターか値に変更します。To address this issue, change reference types either to a pointer or a value. ポインターに型を変更する場合、共用体フィールドを使用するコードでの変更が必要です。Changing the type to a pointer requires changes in the code that uses the union field. コードを値に変更すると、共用体に格納されているデータが変更されます。これは、他のフィールドに影響を与えます。共用体型のフィールドは同じメモリを共有するからです。Changing the code to a value would change the data stored in the union, which affects other fields since fields in union types share the same memory. 値のサイズによっては、共用体のサイズも変更される場合があります。Depending on the size of the value, it might also change the size of the union.

  • 匿名共用体の標準への適合が改善されました。Anonymous unions are now more conformant to the standard. 以前のバージョンのコンパイラでは、匿名共用体に対して明示的なコンストラクターとデストラクターが生成されていました。Previous versions of the compiler generated an explicit constructor and destructor for anonymous unions. これらのコンパイラで生成される関数は、Visual Studio 2015 で削除されます。These compiler-generated functions are deleted in Visual Studio 2015.

    struct S
    {
        S();
    };
    
    union
    {
        struct
        {
            S s;
        };
    } u; // C2280
    

    上のコードを実行すると、Visual Studio 2015 で次のエラーが生成されます。The preceding code generates the following error in Visual Studio 2015:

    error C2280: '<unnamed-type-u>::<unnamed-type-u>(void)': attempting to reference a deleted function
    note: compiler has generated '<unnamed-type-u>::<unnamed-type-u>' here
    

    この問題を解決するには、コンストラクターおよび/またはデストラクターの独自の定義を提供してください。To resolve this issue, provide your own definitions of the constructor and/or destructor.

    struct S
    {
        // Provide a default constructor by adding an empty function body.
        S() {}
    };
    
    union
    {
        struct
        {
            S s;
        };
    } u;
    
  • 匿名構造体を持つ共用体Unions with anonymous structs

    標準と準拠させるために、共用体の匿名構造体メンバーのランタイムの動作が変更されました。In order to conform with the standard, the runtime behavior has changed for members of anonymous structures in unions. 共用体の匿名構造体のメンバーのコンストラクターは、そのような共用体の作成時に暗黙的に呼び出されなくなりました。The constructor for anonymous structure members in a union is no longer implicitly called when such a union is created. また、共用体の匿名構造体のメンバーのデストラクターも、共用体がスコープから外れたときに暗黙的に呼び出されなくなりました。Also, the destructor for anonymous structure members in a union is no longer implicitly called when the union goes out of scope. 次のコードを検討します。共用体 U に匿名構造体が含まれています。この匿名構造体には、名前付きメンバー構造体 S が含まれており、その構造体にはデストラクターが含まれています。Consider the following code, in which a union U contains an anonymous structure that contains a named member structure S that has a destructor.

    #include <stdio.h>
    struct S
    {
        S() { printf("Creating S\n"); }
        ~S() { printf("Destroying S\n"); }
    };
    union U
    {
        struct {
            S s;
        };
        U() {}
        ~U() {}
    };
    
    void f()
    {
        U u;
        // Destructor implicitly called here.
    }
    
    int main()
    {
        f();
    
        char s[1024];
        printf("Press any key.\n");
        gets_s(s);
        return 0;
    }
    

    Visual Studio 2013 では、S のコンストラクターは共用体の作成時に呼び出され、S のデストラクターは関数 f のスタックがクリーンアップされるときに呼び出されます。In Visual Studio 2013, the constructor for S is called when the union is created, and the destructor for S is called when the stack for function f is cleaned up. しかし、Visual Studio 2015 では、コンストラクターとデストラクターは呼び出されません。But in Visual Studio 2015, the constructor and destructor aren't called. コンパイラによって、この動作の変更に関する警告が出されます。The compiler gives a warning about this behavior change.

    warning C4587: 'U::s': behavior change: constructor is no longer implicitly calledwarning C4588: 'U::s': behavior change: destructor is no longer implicitly called
    

    元の動作を復元するには、匿名構造体に名前を付けます。To restore the original behavior, give the anonymous structure a name. 非匿名構造体の実行時の動作は、コンパイラのバージョンに関係なく、同じです。The runtime behavior of non-anonymous structures is the same, regardless of the compiler version.

    #include <stdio.h>
    
    struct S
    {
        S() { printf("Creating S.\n"); }
        ~S() { printf("Destroying S\n"); }
    };
    union U
    {
        struct
        {
            S s;
        } namedStruct;
        U() {}
        ~U() {}
    };
    
    void f()
    {
        U u;
    }
    
    int main()
    {
        f();
    
        char s[1024];
        printf("Press any key.\n");
        gets_s(s);
        return 0;
    }
    

    別の方法として、新しい関数にコンストラクターとデストラクターのコードを移動し、共用体のコンストラクターおよびデストラクターからこれらの関数の呼び出しを追加します。Alternatively, try moving the constructor and destructor code into new functions, and add calls to these functions from the constructor and destructor for the union.

    #include <stdio.h>
    
    struct S
    {
        void Create() { printf("Creating S.\n"); }
        void Destroy() { printf("Destroying S\n"); }
    };
    union U
    {
        struct
        {
            S s;
        };
        U() { s.Create(); }
        ~U() { s.Destroy(); }
    };
    
    void f()
    {
        U u;
    }
    
    int main()
    {
        f();
    
        char s[1024];
        printf("Press any key.\n");
        gets_s(s);
        return 0;
    }
    
  • テンプレートの解決Template resolution

    テンプレートの名前解決に変更が加えられています。Changes have been made to name resolution for templates. C++ では、名前解決の候補を検討する場合、一致の可能性として検討されている 1 つ以上の名前により、無効なテンプレート インスタンス化が生成される可能性があります。In C++, when considering candidates for the resolution of a name, it can be the case that one or more names under consideration as potential matches produces an invalid template instantiation. これらの無効なインスタンス化は通常、それ自体はコンパイラ エラーの原因にはなりません。これは SFINAE (Substitution Failure Is Not An Error: 置き換えの失敗はエラーではない) と呼ばれます。These invalid instantiations do not normally cause compiler errors, a principle known as SFINAE (Substitution Failure Is Not An Error).

    SFINAE のコンパイラがクラス テンプレートの特殊化のインスタンス化を必要とする場合は、この処理中に発生したエラーはコンパイラ エラーです。Now, if SFINAE requires the compiler to instantiate the specialization of a class template, then any errors that occur during this process are compiler errors. 以前のバージョンでは、コンパイラはこのようなエラーを無視していました。In previous versions, the compiler would ignore such errors. 次に例を示します。For example, consider the following code:

    #include <type_traits>
    
    template< typename T>
    struct S
    {
        S() = default;
        S(const S&);
        S(S& &);
    
        template< typename U, typename = typename std::enable_if< std::is_base_of< T, U> ::value> ::type>
        S(S< U> & &);
    };
    
    struct D;
    
    void f1()
    {
        S< D> s1;
        S< D> s2(s1);
    }
    
    struct B
    {
    };
    
    struct D : public B
    {
    };
    
    void f2()
    {
        S< D> s1;
        S< D> s2(s1);
    }
    

    現在のコンパイラでコンパイルすると、次のエラーが表示されます。If you compile with the current compiler, you get the following error:

    type_traits(1110): error C2139: 'D': an undefined class is not allowed as an argument to compiler intrinsic type trait '__is_base_of'
    ..\t331.cpp(14): note: see declaration of 'D'
    ..\t331.cpp(10): note: see reference to class template instantiation 'std::is_base_of<T,U>' being compiled
    with
    [
        T=D,
        U=D
    ]
    

    これは、is_base_of の最初の呼び出しの時点でクラス D がまだ定義されていないためです。This is because at the point of the first invocation of the is_base_of the class D hasn't been defined yet.

    この場合の修正は、クラスが定義されるまでそのような型の特徴を使用しないことです。In this case, the fix is to not use such type traits until the class has been defined. BD の定義をコード ファイルの先頭に移動すると、エラーが解決されます。If you move the definitions of B and D to the beginning of the code file, the error is resolved. 定義がヘッダー ファイルにある場合、ヘッダー ファイルの include ステートメントの順序を確認し、問題のあるテンプレートが使用される前にクラス定義がコンパイルされるようにしてください。If the definitions are in header files, check the order of the include statements for the header files to make sure that any class definitions are compiled before the problematic templates are used.

  • コピー コンストラクターCopy constructors

    Visual Studio 2013 と Visual Studio 2015 の両方において、コンパイラは、クラスにユーザー定義の移動コンストラクターがあり、ユーザー定義のコピー コンストラクターはない場合に、そのクラスのコピー コンストラクターを生成します。In both Visual Studio 2013 and Visual Studio 2015, the compiler generates a copy constructor for a class if that class has a user-defined move constructor but no user-defined copy constructor. Dev14 では、この暗黙的に生成されたコピー コンストラクターは "= delete" とマークされています。In Dev14, this implicitly generated copy constructor is also marked "= delete".

  • extern "C" として宣言される main に戻り値の型が必要になったmain declared as extern "C" now requires a return type.

    次のコードに対しては、C4430 が発生するようになりました。The following code now produces C4430.

    extern "C" __cdecl main(){} // C4430
    

    このエラーを解決するには、戻り値の型を追加します。To fix the error, add the return type:

    extern "C" int __cdecl main(){} // OK
    
  • メンバーの初期化子では typename を使用できないtypename isn't allowed in a member initializer

    次のコードに対しては、C2059 が発生するようになりました。The following code now produces C2059:

    template<typename T>
    struct S1 : public T::type
    {
        S1() : typename T::type() // C2059
        {
        }
    };
    
    struct S2 {
        typedef S2 type;
    };
    
    S1<S2> s;
    

    このエラーを解決するには、 typename 初期化子からを削除します。To fix the error, remove typename from the initializer:

    S1() : T::type() // OK
    ...
    
  • 明示的な特殊化でのストレージ クラスは無視されるThe storage class on explicit specializations is ignored.

    次のコードに対しては、静的ストレージ クラスの指定子は無視されます。In the following code, the static storage class specifier is ignored

    template <typename T>
    void myfunc(T h)
    {
    }
    
    template<>
    static void myfunc(double h) // static is ignored
    {
    }
    
  • クラス テンプレート内部の static_assert で定数を使うと常にエラーになるA constant used in a static_assert inside a class template will always fail.

    次のコード static_assert を実行すると、は常に失敗します。The following code causes the static_assert to always fail:

    template <size_t some_value>
    struct S1
    {
        static_assert(false, "default not valid"); // always invoked
    
    };
    
    //other partial specializations here
    

    この問題を回避するには、次のように値をラップし struct ます。To work around this issue, wrap the value in a struct:

    template <size_t some_value>
    struct constant_false {
        static const bool value = false;
    };
    
    template <size_t some_value>
    struct S1
    {
        static_assert(constant_false<some_value>::value, "default not valid");
    };
    
    //other partial specializations here
    
  • 事前宣言に適用される規則。(C にのみ適用されます)。Rules enforced for forward declarations. (Applies only to C.)

    次のコードに対しては、C2065 が発生するようになりました。The following code now produces C2065:

    struct token_s;
    typedef int BOOL;
    typedef int INT;
    
    typedef int(*PFNTERM)(PTOKEN, BOOL, INT); // C2065: 'PTOKEN' : undeclared identifier
    

    この問題を修正するには、適切な事前宣言を追加します。To fix this problem, add the proper forward declarations:

    struct token_s;
    typedef int BOOL;
    typedef int INT;
    
    // forward declarations:
    typedef struct token_s TOKEN;
    typedef TOKEN *PTOKEN;
    
    typedef int(*PFNTERM)(PTOKEN, BOOL, INT);
    
  • 関数ポインター型のより一貫した適用More consistent enforcement of function pointer types

    次のコードに対しては、C2197 が発生するようになりました。The following code now produces C2197:

    typedef int(*F1)(int);
    typedef int(*F2)(int, int);
    
    void func(F1 f, int v1, int v2)
    {
        f(v1, v2); // C2197
    }
    
  • オーバーロード関数のあいまいな呼び出しAmbiguous calls to overloaded functions

    次のコードに対しては、C266: "'N::bind': オーバーロード関数の呼び出しを解決することができません" が発生するようになりました。The following code now produces C266: 'N::bind': ambiguous call to overloaded function

    template<typename R, typename T, typename T1, typename A1>
    void bind(R(T::*)(T1), A1&&);
    
    namespace N
    {
        template <typename T, typename R, typename ... Tx>
        void bind(R(T::*)(Tx...), T* ptr);
    }
    
    using namespace N;
    
    class Manager
    {
    public:
        void func(bool initializing);
    
        void mf()
        {
            bind(&Manager::func, this); //C2668
        }
    };
    

    このエラーを解決するには、bind: N::bind(...) への呼び出しを完全修飾します。To fix the error, you can fully qualify the call to bind: N::bind(...). ただし、この変更が宣言されていない識別子 (C2065) を使用してマニフェストになっている場合は、代わりに宣言を使用してこれを修正することが適切な場合があり using ます。However, if this change is manifest through an undeclared identifier (C2065), then it may be appropriate to fix this with a using declaration instead.

    このパターンは、ComPtr および Microsoft::WRL 名前空間内の他の型で頻繁に発生します。This pattern happens frequently with ComPtr and other types in the Microsoft::WRL namespace.

  • 不適切なアドレス指定の修正Fix incorrect address of

    次のコードに対しては、C2440: "'=': 'type *' から 'type' に変換できません" が発生するようになりました。The following code now produces C2440: '=': cannot convert from 'type *' to 'type'. このエラーを解決するには、&(type) を (type) に、また (&f()) を (f()) に変更します。To fix the error, change &(type) to (type) and (&f()) to (f()).

    // C
    typedef void (*type)(void);
    
    void f(int i, type p);
    void g(int);
    void h(void)
    {
        f(0, &(type)g);
    }
    
    // C++
    typedef void(*type)(void);
    
    type f();
    
    void g(type);
    
    void h()
    {
        g(&f());
    }
    
  • 文字列リテラルは定数配列であるString literal is a constant array

    次のコードに対しては、"C2664: 'void f(void )': 引数 1 を 'const char ()[2]' から 'void *' へ変換できません" が発生します。The following code now produces C2664: 'void f(void )': cannot convert argument 1 from 'const char ()[2]' to 'void *'

    void f(void *);
    
    void h(void)
    {
        f(&__FUNCTION__);
        void *p = &"";
    }
    

    このエラーを解決するには、関数パラメーターの型を const void* に変更するか、または h の本体を次の例のように変更します。To fix the error, change the function parameter type to const void*, or else change the body of h to look like this example:

    void h(void)
    {
        char name[] = __FUNCTION__;
        f( name);
        void *p = &"";
    }
    
  • C++ 11 の UDL の文字列C++11 UDL strings

    次のコードに対しては、エラー C3688: "リテラル サフィックス 'L' が無効です。リテラル演算子またはリテラル演算子テンプレート 'operator ""L' が見つかりません" が発生するようになりました。The following code now produces error C3688: invalid literal suffix 'L'; literal operator or literal operator template 'operator ""L' not found

    #define MACRO
    
    #define STRCAT(x, y) x\#\#y
    
    int main(){
    
        auto *val1 = L"string"MACRO;
        auto *val2 = L"hello "L"world";
    
        std::cout << STRCAT(L"hi ", L"there");
    }
    

    このエラーを解決するには、スペースを追加するようにコードを変更します。To fix the error, change the code to add a space:

    #define MACRO
    
    // Remove ##. Strings are automatically
    // concatenated so they aren't needed
    #define STRCAT(x, y) x y
    
    int main(){
        //Add space after closing quote
        auto *val1 = L"string" MACRO;
        auto *val2 = L"hello " L"world";
    
        std::cout << STRCAT(L"hi ", L"there");
    }
    

    上記の例で、MACRO は 2 つのトークン (文字列に続くマクロ) として解析されなくなります。In the example above, MACRO is no longer parsed as two tokens (a string followed by a macro). 今度は、1 つのトークン UDL として解析されます。Now it's parsed as a single token UDL. 同じことが L""L"" にも当てはまり、以前は L"" および L"" として解析されていたものが、L""L および "" として解析されるようになります。The same applies to L""L"", which was parsed previously as L"" and L"", and is now parsed as L""L and "".

    文字列連結の規則も標準への準拠に取り込まれました。つまり、L"a" "b" は L"ab" と同じです。String concatenation rules were also brought into compliance with the standard, which means L"a" "b" is equivalent to L"ab". 以前のエディションの Visual Studio では、文字幅の異なる文字列の連結は受け入れられませんでした。Previous editions of Visual Studio did not accept concatenation of strings with different character width.

  • C++11 の空の文字の削除C++11 empty character removed

    次のコードに対しては、エラー C2137: "空の文字定数" が発生するようになりました。The following code now produces error C2137: empty character constant

    bool check(wchar_t c){
        return c == L''; //implicit null character
    }
    

    このエラーを解決するには、null を明示するようにコードを変更します。To fix the error, change the code to make the null explicit:

    bool check(wchar_t c){
        return c == L'\0';
    }
    
  • MFC の例外はコピーできないため値によってキャッチできないMFC exceptions can't be caught by value because they aren't copyable

    MFC アプリケーションの次のコードに対しては、エラー C2316: "'D' がデストラクターとしてキャッチできない、またはコピー コンストラクターがアクセスできないか削除されています" が発生するようになりました。The following code in an MFC application now causes error C2316: 'D': cannot be caught as the destructor and/or copy constructor are inaccessible or deleted

    struct B {
    public:
        B();
    private:
        B(const B &);
    };
    
    struct D : public B {
    };
    
    int main()
    {
        try
        {
        }
        catch (D) // C2316
        {
        }
    }
    

    コードを修正するには、catch ブロックを catch (const D &) に変更してもかまいませんが、一般にもっとよい解決策は、MFC TRY/CATCH マクロを使うことです。To fix the code, you can change the catch block to catch (const D &) but the better solution is usually to use the MFC TRY/CATCH macros.

  • alignofはキーワードになりましたalignof is now a keyword

    次のコードに対しては、エラー C2332: "'class': タグ名がありません" が発生するようになりました。The following code now produces error C2332: 'class': missing tag name. コードを修正するには、クラスの名前を変更する必要があります。また、クラスがと同じ作業を実行している場合は、 alignof クラスを new キーワードに置き換えるだけです。To fix the code you must rename the class or, if the class is performing the same work as alignof, just replace the class with the new keyword.

    class alignof{}
    
  • constexprはキーワードになりましたconstexpr is now a keyword

    次のコードに対しては、エラー C2059: "構文エラー: ')'" が発生するようになりました。The following code now produces error C2059: syntax error: ')'. コードを修正するには、呼び出される関数または変数の名前の名前を変更する必要があり constexpr ます。To fix the code, you must rename any function or variable names that are called constexpr.

    int constexpr() {return 1;}
    
  • 移動可能な型は const にできないMovable types can't be const

    関数が移動の対象となる型を返す場合、戻り値の型をにすることはできません constWhen a function returns a type that's intended to be moved, its return type should not be const.

  • 削除されたコピー コンストラクターDeleted copy constructors

    次のコードに対しては、C2280: "'S::S(S &&)': 削除された関数を参照しようとしています" が発生するようになりました。The following code now produces C2280 'S::S(S &&)': attempting to reference a deleted function:

    struct S{
        S(int, int);
        S(const S&) = delete;
        S(S&&) = delete;
    };
    
    S s2 = S(2, 3); //C2280
    

    このエラーを修正するには、S2 に対して直接の初期化を使います。To fix the error, use direct initialization for S2:

    struct S{
        S(int, int);
        S(const S&) = delete;
        S(S&&) = delete;
    };
    
    S s2 = {2,3}; //OK
    
  • 関数ポインターへの変換は、ラムダ キャプチャがない場合にのみ生成されるConversion to function pointer only generated when no lambda capture

    Visual Studio 2015 では、次のコードに対しては C2664 が発生します。The following code produces C2664 in Visual Studio 2015.

    void func(int(*)(int)) {}
    
    int main() {
    
        func([=](int val) { return val; });
    }
    

    このエラーを解決するには、キャプチャ リストから = を削除します。To fix the error, remove the = from the capture list.

  • 変換演算子を含むあいまいな呼び出しAmbiguous calls involving conversion operators

    次のコードに対しては、エラー C2440: "'type cast': 'S2' から 'S1' に変換できません" が発生するようになりました。The following code now produces error C2440: 'type cast': cannot convert from 'S2' to 'S1':

    struct S1 {
        S1(int);
    };
    
    struct S2 {
        operator S1();
        operator int();
    };
    
    void f(S2 s2)
    {
        (S1)s2;
    }
    

    このエラーを解決するには、変換演算子を明示的に呼び出します。To fix the error, explicitly call the conversion operator:

    void f(S2 s2)
    {
        //Explicitly call the conversion operator
        s2.operator S1();
        // Or
        S1((int)s2);
    }
    

    次のコードに対しては、エラー C2593: "'operator =' があいまいです" が発生するようになりました。The following code now produces error C2593: 'operator =' is ambiguous:

    struct S1 {};
    
    struct S2 {
        operator S1&();
        operator S1() const;
    };
    
    void f(S1 *p, S2 s)
    {
        *p = s;
    }
    

    このエラーを解決するには、変換演算子を明示的に呼び出します。To fix the error, explicitly call the conversion operator:

    void f(S1 *p, S2 s)
    {
        *p = s.operator S1&();
    }
    
  • 非静的データ メンバーの初期化 (NSDMI) での無効なコピー初期化の修正Fix invalid copy initialization in non-static data member initialization (NSDMI)

    次のコードに対しては、エラー C2664: "'S1::S1(S1 &&)': 引数 1 を 'bool' から 'const S1 &' へ変換できません" が発生するようになりました。The following code now produces error C2664: 'S1::S1(S1 &&)': cannot convert argument 1 from 'bool' to 'const S1 &':

    struct S1 {
        explicit S1(bool);
    };
    
    struct S2 {
        S1 s2 = true; // error
    };
    

    このエラーを修正するには、直接の初期化を使います。To fix the error, use direct initialization:

    struct S2 {
    S1 s1{true}; // OK
    };
    
  • decltype ステートメント内のコンストラクターへのアクセスAccessing constructors inside decltype statements

    次のコードに対しては、C2248: 'S::S': "クラス 'S' で宣言されているプライベート メンバーにアクセスできません" が発生するようになりました。The following code now produces C2248: 'S::S': cannot access private member declared in class 'S':

    class S {
        S();
    public:
        int i;
    };
    
    class S2 {
        auto f() -> decltype(S().i);
    };
    

    このエラーを解決するには、SS2 のフレンド宣言を追加します。To fix the error, add a friend declaration for S2 in S:

    class S {
        S();
        friend class S2; // Make S2 a friend
    public:
        int i;
    };
    
  • ラムダの既定のコンストラクターが暗黙的に削除されるDefault ctor of lambda is implicitly deleted

    次のコードに対しては、エラー C3497: "ラムダのインスタンスは作成できません" が発生するようになりました。The following code now produces error C3497: you cannot construct an instance of a lambda:

    void func(){
        auto lambda = [](){};
    
        decltype(lambda) other;
    }
    

    このエラーを解決するには、既定のコンストラクターを呼び出す必要がないようにします。To fix the error, remove the need for the default constructor to be called. ラムダが何もキャプチャしない場合は、関数ポインターにキャストできます。If the lambda doesn't capture anything, then it can be cast to a function pointer.

  • 削除された代入演算子でのラムダLambdas with a deleted assignment operator

    次のコードに対しては、エラー C2280 が発生するようになりました。The following code now produces error C2280:

    #include <memory>
    #include <type_traits>
    
    template <typename T, typename D>
    std::unique_ptr<T, typename std::remove_reference<D &&>::type> wrap_unique(T *p, D &&d);
    
    void f(int i)
    {
        auto encodedMsg = wrap_unique<unsigned char>(nullptr, [i](unsigned char *p) {
        });
        encodedMsg = std::move(encodedMsg);
    }
    

    このエラーを解決するには、ラムダをファンクター クラスに置き換えるか、代入演算子を使う必要がないようにします。To fix the error, replace the lambda with a functor class or remove the need to use the assignment operator.

  • 削除されたコピー コンストラクターでのオブジェクト移動の試みAttempting to move an object with deleted copy constructor

    次のコードに対しては、エラー C2280: "'moveable::moveable(const moveable &)': 削除された関数を参照しようとしています" が発生するようになりました。The following code now produces error C2280: 'moveable::moveable(const moveable &)': attempting to reference a deleted function

    struct moveable {
    
        moveable() = default;
        moveable(moveable&&) = default;
        moveable(const moveable&) = delete;
    };
    
    struct S {
        S(moveable && m) :
            m_m(m)//copy constructor deleted
        {}
        moveable m_m;
    };
    

    エラーを解決するには、代わりに std::move を使用します。To fix the error, use std::move instead:

    S(moveable && m) :
        m_m(std::move(m))
    
  • ローカル クラスは、同じ関数で後に定義されている他のローカル クラスを参照できないLocal class can't reference other local class defined later in the same function

    次のコードに対しては、エラー C2079: "'s' が未定義の struct 'main::S2' で使用しています" が発生するようになりました。The following code now produces error C2079: 's' uses undefined struct 'main::S2'

    int main()
    {
        struct S2;
        struct S1 {
            void f() {
                S2 s;
            }
        };
        struct S2 {};
    }
    

    このエラーを解決するには、S2 の定義を上に移動します。To fix the error, move up the definition of S2:

    int main()
    {
        struct S2 { //moved up
        };
    
    struct S1 {
        void f() {
            S2 s;
            }
        };
    }
    
  • 派生コンストラクターの本体内の保護された既定コンストラクターは呼び出すことができないCannot call a protected base ctor in the body of derived ctor.

    次のコードに対しては、エラー C2248: "'S1::S1': クラス 'S1' で宣言されている保護されているメンバーにアクセスできません" が発生するようになりました。The following code now produces error C2248: 'S1::S1': cannot access protected member declared in class 'S1'

    struct S1 {
    protected:
        S1();
    };
    
    struct S2 : public S1 {
        S2() {
            S1();
        }
    };
    

    このエラーを解決するには、S2 でコンストラクターから S1() の呼び出しを削除し、必要がある場合は別の関数に配置します。To fix the error, in S2 remove the call to S1() from the constructor and if necessary put it in another function.

  • {}ポインターへの変換を禁止します{} prevents conversion to pointer

    次のコードに対しては、C2439: "'S::p': 指定されたメンバーは初期化できません" が発生するようになりました。The following code now produces C2439 'S::p': member could not be initialized

    struct S {
        S() : p({ 0 }) {}
        void *p;
    };
    

    このエラーを解決するに 0 は、 nullptr 次の例に示すように、の中から中かっこを削除するか、代わりにを使用します。To fix the error, remove the braces from around the 0 or else use nullptr instead, as shown in this example:

    struct S {
        S() : p(nullptr) {}
        void *p;
    };
    
  • 正しくないマクロ定義とかっこ付きの使用法Incorrect macro definition and usage with parentheses

    次の例に対しては、エラー C2008: "';': マクロ定義内で指定された文字の使い方が間違っています" が発生するようになりました。The following example now produces error C2008: ';': unexpected in macro definition

    #define A; //cause of error
    
    struct S {
        A(); // error
    };
    

    この問題を解決するには、先頭の行を #define A(); に変更します。To fix the problem, change the top line to #define A();

    次のコードに対しては、エラー C2059: "構文エラー: ')'" が発生します。The following code produces error C2059: syntax error: ')'

    //notice the space after 'A'
    #define A () ;
    
    struct S {
        A();
    };
    

    このコードを修正するには、A と () の間のスペースを削除します。To fix the code, remove the space between A and ().

    次のコードに対しては、エラー C2091: "関数は関数を返せません" が発生します。The following code produces error C2091: function returns function:

    #define DECLARE void f()
    
    struct S {
        DECLARE();
    };
    

    このエラーを解決するには、S の DECLARE の後のかっこを削除して、DECLARE; にします。To fix the error, remove the parentheses after DECLARE in S: DECLARE;.

    次のコードに対しては、エラー C2062: "型 'int' は予期されていません" が発生します。The following code produces error C2062: type 'int' unexpected

    #define A (int)
    
    struct S {
        A a;
    };
    

    この問題を解決するには、A を次のように定義します。To fix the problem, define A like this:

    #define A int
    
  • 宣言内の余分なかっこExtra parens in declarations

    次のコードに対しては、エラー C2062: "型 'int' は予期されていません" が発生します。The following code produces error C2062: type 'int' unexpected

    struct S {
        int i;
        (int)j;
    };
    

    このエラーを解決するには、j を囲むかっこを削除します。To fix the error, remove the parentheses around j. わかりやすくするためにかっこが必要な場合は、を使用し typedef ます。If the parentheses are needed for clarity, then use a typedef.

  • コンパイラで生成されるコンストラクターと __declspec(novtable)Compiler-generated constructors and __declspec(novtable)

    Visual Studio 2015 では、仮想基底クラスを使う抽象クラスのコンパイラによって生成されるインライン コンストラクターで、__declspec(dllimport) と組み合わせて使うと __declspec(novtable) の不適切な使用が公開される可能性が高くなっています。In Visual Studio 2015, there is an increased likelihood that compiler-generated inline constructors of abstract classes with virtual base classes may expose improper usage of __declspec(novtable) when used in combination with __declspec(dllimport).

  • auto では初期化子リストの直接適用に含まれる式が 1 つでなければならないauto requires single expression in direct-list-initialization

    次のコードに対しては、エラー C3518: "'testPositions': 初期化子リストを直接適用するコンテキストでは、'auto' の型は、単一の初期化子式からのみ推測できます" が発生するようになりました。The following code now produces error C3518: 'testPositions': in a direct-list-initialization context the type for 'auto' can only be deduced from a single initializer expression

    auto testPositions{
        std::tuple<int, int>{13, 33},
        std::tuple<int, int>{-23, -48},
        std::tuple<int, int>{38, -12},
        std::tuple<int, int>{-21, 17}
    };
    

    このエラーを解決する 1 つの可能性は、testPositions を次のように初期化することです。To fix the error, one possibility is to initialize testPositions as follows:

    std::tuple<int, int> testPositions[]{
        std::tuple<int, int>{13, 33},
        std::tuple<int, int>{-23, -48},
        std::tuple<int, int>{38, -12},
        std::tuple<int, int>{-21, 17}
    };
    
  • is_convertible に対する型のチェックと型へのポインターChecking types vs. pointers to types for is_convertible

    次のコードでは、静的アサーションが失敗するようになりました。The following code now causes the static assertion to fail.

    struct B1 {
    private:
        B1(const B1 &);
    };
    struct B2 : public B1 {};
    struct D : public B2 {};
    
    static_assert(std::is_convertible<D, B2>::value, "fail");
    

    このエラーを修正するには、とのポインターを比較するようにを変更し static_assert D B2 ます。To fix the error, change the static_assert so that it compares pointers to D and B2:

    static_assert(std::is_convertible<D*, B2*>::value, "fail");
    
  • __declspec (novtable) 宣言は一貫している必要があります__declspec(novtable) declarations must be consistent

    __declspec 宣言は、すべてのライブラリ間で一貫している必要があります。__declspec declarations must be consistent across all libraries. 次のコードに対しては、単一定義規則 (ODR) 違反が発生するようになりました。The following code will now produce a one-definition rule (ODR) violation:

    //a.cpp
    class __declspec(dllexport)
        A {
    public:
        A();
        A(const A&);
        virtual ~A();
    private:
        int i;
    };
    
    A::A() {}
    A::~A() {}
    A::A(const A&) {}
    
    //b.cpp
    // compile with cl.exe /nologo /LD /EHsc /Osx b.cpp
    #pragma comment(lib, "A")
    class __declspec(dllimport) A
    {
    public: A();
            A(const A&);
            virtual ~A();
    private:
        int i;
    };
    
    struct __declspec(novtable) __declspec(dllexport) B
        : virtual public A {
        virtual void f() = 0;
    };
    
    //c.cpp
    #pragma comment(lib, "A")
    #pragma comment(lib, "B")
    class __declspec(dllimport) A
    {
    public:
        A();
        A(const A&);
        virtual ~A();
    private:
        int i;
    };
    struct  /* __declspec(novtable) */ __declspec(dllimport) B // Error. B needs to be novtable here also.
        : virtual public A
    {
        virtual void f() = 0;
    };
    
    struct C : virtual B
    {
        virtual void f();
    };
    
    void C::f() {}
    C c;
    

更新プログラム 1 の準拠の強化Conformance Improvements in Update 1

  • プライベートの仮想基底クラスと間接継承Private virtual base classes and indirect inheritance

    以前のバージョンのコンパイラでは、派生クラスは間接的に派生したprivate virtual基底クラスのメンバー関数を呼び出すことができました。Previous versions of the compiler allowed a derived class to call member functions of its indirectly derived private virtual base classes. この従来の動作は正しい動作ではなく、C++ 標準に準拠していません。This old behavior was incorrect and doesn't conform to the C++ standard. コンパイラはこの方法で記述されたコードを受け入れなくなりました。その結果、コンパイラ エラー C2280 を発行します。The compiler no longer accepts code written in this way, and issues compiler error C2280 as a result.

    error C2280: 'void *S3::__delDtor(unsigned int)': attempting to reference a deleted function
    

    例 (変更前)Example (before)

    class base
    {
    protected:
        base();
        ~base();
    };
    
    class middle : private virtual base {}; class top : public virtual middle {};
    
    void destroy(top *p)
    {
        delete p;  //
    }
    

    例 (変更後)Example (after)

    class base;  // as above
    
    class middle : protected virtual base {};
    class top : public virtual middle {};
    
    void destroy(top *p)
    {
        delete p;
    }
    

    - - または -- or -

    class base;  // as above
    
    class middle : private virtual base {};
    class top : public virtual middle, private virtual bottom {};
    
    void destroy(top *p)
    {
        delete p;
    }
    
  • オーバーロードされた operator new と operator deleteOverloaded operator new and operator delete

    以前のバージョンのコンパイラでは、メンバー以外の operator new とメンバー以外の operator delete を static として宣言することや、グローバル名前空間以外の名前空間で宣言することが許可されていました。Previous versions of the compiler allowed non-member operator new and non-member operator delete to be declared static, and to be declared in namespaces other than the global namespace. この以前の動作により、プログラマが意図したまたは演算子の実装をプログラムが呼び出さないというリスクが生じ、その new delete 結果、実行時に異常な動作が発生します。This old behavior created a risk that the program would not call the new or delete operator implementation that the programmer intended, resulting in silent bad runtime behavior. コンパイラはこの方法で記述されたコードを受け入れなくなりました。代わりにコンパイラ エラー C2323 を発行します。The compiler no longer accepts code written in this way and issues compiler error C2323 instead.

    error C2323: 'operator new': non-member operator new or delete functions may not be declared static or in a namespace other than the global namespace.
    

    例 (変更前)Example (before)

    static inline void * __cdecl operator new(size_t cb, const std::nothrow_t&)  // error C2323
    

    例 (変更後)Example (after)

    void * __cdecl operator new(size_t cb, const std::nothrow_t&)  // removed 'static inline'
    

    また、コンパイラは特定の診断を提供しませんが、インライン演算子 new は不適切な形式と見なされます。Additionally, although the compiler doesn't give a specific diagnostic, inline operator new is considered ill-formed.

  • 非クラス型で 'operator type()' (ユーザー定義の変換) を呼び出すCalling 'operator type()' (user-defined conversion) on non-class types

    以前のバージョンのコンパイラでは 'operator type()' を非クラス型で呼び出すことが許可されていましたが、それは何の警告もなく無視されていました。Previous versions of the compiler allowed 'operator type()' to be called on non-class types while silently ignoring it. この従来の動作のせいで、問題のあるコードが警告なしに生成される危険性が生じ、結果として、予期しないランタイム動作の原因となっていました。This old behavior created a risk of silent bad code generation, resulting in unpredictable runtime behavior. コンパイラはこの方法で記述されたコードを受け入れなくなりました。代わりにコンパイラ エラー C2228 を発行します。The compiler no longer accepts code written in this way and issues compiler error C2228 instead.

    error C2228: left of '.operator type' must have class/struct/union
    

    例 (変更前)Example (before)

    typedef int index_t;
    void bounds_check(index_t index);
    void login(int column)
    {
        bounds_check(column.operator index_t());  // error C2228
    }
    

    例 (変更後)Example (after)

    typedef int index_t;
    void bounds_check(index_t index);
    void login(int column)
    {
        bounds_check(column);  // removed cast to 'index_t', 'index_t' is an alias of 'int'
    }
    
  • 詳細な型指定子の冗長な typenameRedundant typename in elaborated type specifiers

    以前のバージョンのコンパイラは詳細 typename な型指定子で許可されていましたが、この方法で記述されたコードは意味が正しくありません。Previous versions of the compiler allowed typename in an elaborated type specifier, but code written in this way is semantically incorrect. コンパイラはこの方法で記述されたコードを受け入れなくなりました。代わりにコンパイラ エラー C3406 を発行します。The compiler no longer accepts code written in this way and issues compiler error C3406 instead.

    error C3406: 'typename' cannot be used in an elaborated type specifier
    

    例 (変更前)Example (before)

    template <typename class T>
    class container;
    

    例 (変更後)Example (after)

    template <class T>  // alternatively, could be 'template <typename T>'; 'typename' is not elaborating a type specifier in this case
    class container;
    
  • 初期化子リストからの配列の型推論Type deduction of arrays from an initializer list

    以前のバージョンのコンパイラでは、初期化子リストからの配列の型推論はサポートされていませんでした。Previous versions of the compiler did not support type deduction of arrays from an initializer list. コンパイラでこの形式の型推論がサポートされるようになりました。その結果、初期化子リストを使用した関数テンプレートへの呼び出しがあいまいになったり、以前のバージョンのコンパイラとは異なるオーバーロードが選ばれたりする可能性があります。The compiler now supports this form of type deduction and, as a result, calls to function templates using initializer lists might now be ambiguous or a different overload might be chosen than in previous versions of the compiler. これらの問題を解決するには、プログラマの意図したオーバーロードをプログラムが明示的に指定する必要があります。To resolve these issues, the program must now explicitly specify the overload that the programmer intended.

    この新しい動作により、オーバーロードの解決で過去の候補と同程度に優れた追加候補が検討されると、呼び出しはあいまいになり、結果としてコンパイラはコンパイラ エラー C2668 を発行します。When this new behavior causes overload resolution to consider an additional candidate that's equally as good as the historic candidate, the call becomes ambiguous and the compiler issues compiler error C2668 as a result.

    error C2668: 'function' : ambiguous call to overloaded function.
    

    例 1: オーバーロード関数のあいまいな呼び出し (変更前)Example 1: Ambiguous call to overloaded function (before)

    // In previous versions of the compiler, code written in this way would unambiguously call f(int, Args...)
    template < typename... Args>
    void f(int, Args...);  //
    
    template < int N, typename... Args>
    void f(const int(&)[N], Args...);
    
    int main()
    {
        // The compiler now considers this call ambiguous, and issues a compiler error
         f({ 3 });   error C2668 : 'f' ambiguous call to overloaded function
    }
    

    例 1: オーバーロード関数のあいまいな呼び出し (変更後)Example 1: ambiguous call to overloaded function (after)

    template < typename... Args>
    void f(int, Args...);  //
    
    template < int N, typename... Args>
    void f(const int(&)[N], Args...);
    
    int main()
    {
        // To call f(int, Args...) when there is just one expression in the initializer list, remove the braces from it.
        f(3);
    }
    

    この新しい動作により、オーバーロードの解決で過去の候補よりも適合度の高い追加候補が検討されると、呼び出しはあいまいにならずに新しい候補に解決され、プログラムの動作は変化します。これはプログラマの意図した動作とは異なる場合があります。When this new behavior causes overload resolution to consider an additional candidate that's a better match than the historic candidate, the call resolves unambiguously to the new candidate, causing a change in program behavior that's probably different than the programmer intended.

    例 2: オーバーロードの解決の変更 (変更前)Example 2: change in overload resolution (before)

    // In previous versions of the compiler, code written in this way would unambiguously call f(S, Args...)
    struct S
    {
        int i;
        int j;
    };
    
    template < typename... Args>
    void f(S, Args...);
    
    template < int N, typename... Args>
    void f(const int *&)[N], Args...);
    
    int main()
    {
        // The compiler now resolves this call to f(const int (&)[N], Args...) instead
         f({ 1, 2 });
    }
    

    例 2: オーバーロードの解決の変更 (変更後)Example 2: change in overload resolution (after)

    struct S;  // as before
    
    template < typename... Args>
    void f(S, Args...);
    
    template < int N, typename... Args>
    void f(const int *&)[N], Args...);
    
    int main()
    {
        // To call f(S, Args...), perform an explicit cast to S on the initializer list.
        f(S{ 1, 2 });
    }
    
  • switch ステートメントの警告の復元Restoration of switch statement warnings

    以前のバージョンのコンパイラは、ステートメントに関連するいくつかの警告を削除しました。 switch これらの警告は復元されました。A previous version of the compiler removed some warnings related to switch statements; these warnings have now been restored. コンパイラは復元された警告を発行するようになり、特定の case (既定の case を含む) に関連する警告が、switch ステートメントの最後の行ではなく、問題のある case を含む行で発行されるようになりました。The compiler now issues the restored warnings, and warnings related to specific cases (including the default case) are now issued on the line containing the offending case, rather than on the last line of the switch statement. この結果、以前とは異なる行でそれらの警告が発行されるようになり、以前は #pragma warning(disable:####) を使用して抑制できていた警告も、意図どおりに抑制できなくなる可能性があります。As a result of now issuing those warnings on different lines than in the past, warnings previously suppressed by using #pragma warning(disable:####) may no longer be suppressed as intended. 意図どおりにこれらの警告を抑制するには、問題がある最初の case の上の行まで #pragma warning(disable:####) ディレクティブを移動しなければならない場合があります。To suppress these warnings as intended, it might be necessary to move the #pragma warning(disable:####) directive to a line above the first offending case. 復元された警告を次に示します。The following are the restored warnings:

    warning C4060: switch statement contains no 'case' or 'default' labels
    
    warning C4061: enumerator 'bit1' in switch of enum 'flags' is not explicitly handled by a case label
    
    warning C4062: enumerator 'bit1' in switch of enum 'flags' is not handled
    
    warning C4063: case 'bit32' is not a valid value for switch of enum 'flags'
    
    warning C4064: switch of incomplete enum 'flags'
    
    warning C4065: switch statement contains 'default' but no 'case' labels
    
    warning C4808: case 'value' is not a valid value for switch condition of type 'bool'
    
    Warning C4809: switch statement has redundant 'default' label; all possible 'case' labels are given
    

    C4063 の例 (変更前)Example of C4063 (before)

    class settings
    {
    public:
        enum flags
        {
            bit0 = 0x1,
            bit1 = 0x2,
            ...
        };
        ...
    };
    
    int main()
    {
        auto val = settings::bit1;
    
        switch (val)
        {
        case settings::bit0:
            break;
    
        case settings::bit1:
            break;
    
             case settings::bit0 | settings::bit1:  // warning C4063
                break;
        }
    };
    

    C4063 の例 (変更後)Example of C4063 (after)

    class settings { ... };  // as above
    int main()
    {
        // since C++11, use std::underlying_type to determine the underlying type of an enum
        typedef std::underlying_type< settings::flags> ::type flags_t;
    
            auto val = settings::bit1;
    
        switch (static_cast< flags_t> (val))
        {
        case settings::bit0:
            break;
    
        case settings::bit1:
            break;
    
        case settings::bit0 | settings::bit1:  // ok
            break;
        }
    };
    

    その他の復元の警告の例については、それらのドキュメントをご覧ください。Examples of the other restored warnings are provided in their documentation.

  • #include: パス名で親ディレクトリの指定子 '..' を使用する (/Wall /WX にのみ影響)#include: use of parent-directory specifier '..' in pathname (only affects /Wall /WX)

    以前のバージョンのコンパイラでは、親ディレクトリの指定子の使用が検出されませんでした '… 'Previous versions of the compiler did not detect the use of the parent-directory specifier '..' パス名で #include ディレクティブです。in the pathname of #include directives. この方法で記述されたコードは通常、プロジェクトの相対パスが正しく使用されていないためにプロジェクトの外部に存在するヘッダーをインクルードすることを目的としています。Code written in this way is usually intended to include headers that exist outside of the project by incorrectly using project-relative paths. この従来の動作のせいで、プログラマが意図したものとは異なるソース ファイルをインクルードしてプログラムがコンパイルされる危険性や、これらの相対パスを他のビルド環境に移植できない危険性が生じました。This old behavior created a risk that the program could be compiled by including a different source file than the programmer intended, or that these relative paths would not be portable to other build environments. コンパイラは、この方法で書かれたコードを検出してプログラマに通知し、有効な場合にはオプションのコンパイラ警告 C4464 を発行するようになりました。The compiler now detects and notifies the programmer of code written in this way and issues an optional compiler warning C4464, if enabled.

    warning C4464: relative include path contains '..'
    

    例 (変更前)Example (before)

    #include "..\headers\C4426.h"  // emits warning C4464
    

    例 (変更後)Example (after)

    #include "C4426.h"  // add absolute path to 'headers\' to your project's include directories
    

    さらに、コンパイラは特定の診断を示しませんが、プロジェクトのインクルード ディレクトリを指定する場合、親ディレクトリの指定子 ".." を使用することもお勧めします。Additionally, although the compiler doesn't give a specific diagnostic, we also recommend that the parent-directory specifier ".." shouldn't be used to specify your project's include directories.

  • #pragma optimize() がヘッダー ファイルの終わりを超える (/Wall /WX にのみ影響)#pragma optimize() extends past end of header file (only affects /Wall /WX)

    以前のバージョンのコンパイラでは、翻訳単位内に含まれるヘッダー ファイルをエスケープする最適化フラグの設定の変更は検出されませんでした。Previous versions of the compiler did not detect changes to optimization flag settings that escape a header file included within a translation unit. コンパイラは、この方法で書かれたコードを検出してプログラマに通知し、有効な場合には、問題のある #includeの位置でオプションのコンパイラ警告 C4426 を発行するようになりました。The compiler now detects and notifies the programmer of code written in this way and issues an optional compiler warning C4426 at the location of the offending #include, if enabled. この警告が発行されるのは、この変更が、コンパイラに対するコマンドライン引数によって設定された最適化フラグと競合する場合のみです。This warning is only issued if the changes conflict with the optimization flags set by command-line arguments to the compiler.

    warning C4426: optimization flags changed after including header, may be due to #pragma optimize()
    

    例 (変更前)Example (before)

    // C4426.h
    #pragma optimize("g", off)
    ...
    // C4426.h ends
    
    // C4426.cpp
    #include "C4426.h"  // warning C4426
    

    例 (変更後)Example (after)

    // C4426.h
    #pragma optimize("g", off)
                ...
    #pragma optimize("", on)  // restores optimization flags set via command-line arguments
    // C4426.h ends
    
    // C4426.cpp
    #include "C4426.h"
    
  • #pragma warning(push)#pragma warning(pop) の不一致 (/Wall /WX にのみ影響)Mismatched #pragma warning(push) and #pragma warning(pop) (only affects /Wall /WX)

    以前のバージョンのコンパイラでは、#pragma warning(push) の状態の変更が、異なるソース ファイルの #pragma warning(pop) 状態の変更とペアになっていても (故意であることはまれですが)、それを検出しませんでした。Previous versions of the compiler did not detect #pragma warning(push) state changes being paired with #pragma warning(pop) state changes in a different source file, which is rarely intended. この従来の動作のせいで、プログラマの意図と異なる一連の警告が有効な状態でプログラムがコンパイルされる危険性が生じ、結果として、問題のあるランタイム動作が警告なしに発生する原因となっていました。This old behavior created a risk that the program would be compiled with a different set of warnings enabled than the programmer intended, possibly resulting in silent bad runtime behavior. コンパイラは、この方法で書かれたコードを検出してプログラマに通知し、有効な場合には、一致する #pragma warning(pop) の位置でオプションのコンパイラの警告 C5031 を発行するようになりました。The compiler now detects and notifies the programmer of code written in this way and issues an optional compiler warning C5031 at the location of the matching #pragma warning(pop), if enabled. この警告には、対応する #pragma warning(push) の場所を参照するメモが含まれます。This warning includes a note referencing the location of the corresponding #pragma warning(push).

    warning C5031: #pragma warning(pop): likely mismatch, popping warning state pushed in different file
    

    例 (変更前)Example (before)

    // C5031_part1.h
    #pragma warning(push)
    #pragma warning(disable:####)
    ...
    // C5031_part1.h ends without #pragma warning(pop)
    
    // C5031_part2.h
    ...
    #pragma warning(pop)  // pops a warning state not pushed in this source file
    ...
    // C5031_part1.h ends
    
    // C5031.cpp
    #include "C5031_part1.h" // leaves #pragma warning(push) 'dangling'
    ...
    #include "C5031_part2.h" // matches 'dangling' #pragma warning(push), resulting in warning C5031
    ...
    

    例 (変更後)Example (after)

    // C5031_part1.h
    #pragma warning(push)
    #pragma warning(disable:####)
    ...
    #pragma warning(pop)  // pops the warning state pushed in this source file
    // C5031_part1.h ends without #pragma warning(pop)
    
    // C5031_part2.h
    #pragma warning(push)  // pushes the warning state pushed in this source file
    #pragma warning(disable:####)
    ...
    #pragma warning(pop)
    // C5031_part1.h ends
    
    // C5031.cpp
    #include "C5031_part1.h" // #pragma warning state changes are self-contained and independent of other source files or their #include order.
    ...
    #include "C5031_part2.h"
    ...
    

    一般的ではありませんが、意図的にこの方法でコードを記述する場合があります。Though uncommon, code written in this way is sometimes intentional. この方法で記述されたコードは #include の順序の変更の影響を受けます。可能な場合は、自己完結型の方法を使用してソース コード ファイルで警告状態を管理することをお勧めします。Code written in this way is sensitive to changes in #include order; when possible, we recommend that source code files manage warning state in a self-contained way.

  • 一致していない #pragma warning(push) (/Wall /WX にのみ影響)Unmatched #pragma warning(push) (only affects /Wall /WX)

    以前のバージョンのコンパイラでは、翻訳単位の末尾で一致していない #pragma warning(push) の状態の変更は検出されませんでした。Previous versions of the compiler did not detect unmatched #pragma warning(push) state changes at the end of a translation unit. コンパイラは、この方法で書かれたコードを検出してプログラマに通知し、有効な場合には、一致していない #pragma warning(push) の位置でオプションのコンパイラ警告 C5032 を発行するようになりました。The compiler now detects and notifies the programmer of code written in this way and issues an optional compiler warning C5032 at the location of the unmatched #pragma warning(push), if enabled. この警告が発行されるのは、翻訳単位にコンパイル エラーがない場合のみです。This warning is only issued if there are no compilation errors in the translation unit.

    warning C5032: detected #pragma warning(push) with no corresponding #pragma warning(pop)
    

    例 (変更前)Example (before)

    // C5032.h
    #pragma warning(push)
    #pragma warning(disable:####)
    ...
    // C5032.h ends without #pragma warning(pop)
    
    // C5032.cpp
    #include "C5032.h"
    ...
    // C5032.cpp ends -- the translation unit is completed without #pragma warning(pop), resulting in warning C5032 on line 1 of C5032.h
    

    例 (変更後)Example (after)

    // C5032.h
    #pragma warning(push)
    #pragma warning(disable:####)
    ...
    #pragma warning(pop) // matches #pragma warning (push) on line 1
    // C5032.h ends
    
    // C5032.cpp
    #include "C5032.h"
    ...
    // C5032.cpp ends -- the translation unit is completed without unmatched #pragma warning(push)
    
  • #pragma 警告状態の追跡が強化された結果、追加の警告が発行される場合があります。Additional warnings might be issued as a result of improved #pragma warning state tracking

    以前のバージョンのコンパイラでは、#pragma 警告状態の変化の追跡が不十分なため、すべての意図された警告を発行できませんでした。Previous versions of the compiler tracked #pragma warning state changes insufficiently well to issue all intended warnings. この動作により、プログラマの意図したものとは異なる状況で、事実上、特定の警告が抑制される危険性がありました。This behavior created a risk that certain warnings would be effectively suppressed in circumstances different than the programmer intended. コンパイラにより #pragma warning 状態がより確実に追跡されるようになりました (特にテンプレート内部での #pragma warning 状態の変化に関連するもの)。また #pragma warning(push)#pragma warning(pop) の意図しない使用をプログラマが特定する助けになるように、新しい警告 C5031 と C5032 を必要に応じて発行されるようになりました。The compiler now tracks #pragma warning state more robustly -- especially related to #pragma warning state changes inside of templates -- and optionally issues new warnings C5031 and C5032, which are intended to help the programmer locate unintended uses of #pragma warning(push) and #pragma warning(pop).

    #pragma warning 状態の変更の追跡が強化された結果、以前は誤って抑制されていた警告、または以前は誤って診断されていた問題に関連する警告が発行されるようになる場合があります。As a result of improved #pragma warning state change tracking, warnings formerly incorrectly suppressed or warnings related to issues formerly misdiagnosed might now be issued.

  • 制御が渡らないコードの識別の強化Improved identification of unreachable code

    C++ 標準ライブラリが変更されたり、以前のバージョンのコンパイラよりも関数呼び出しのインライン化機能が強化されたりしたため、コンパイラは特定のコードに制御が渡らないことを示せるようになりました。C++ Standard Library changes and improved ability to inline function calls over previous versions of the compiler might allow the compiler to prove that certain code is now unreachable. この新しい動作の結果、警告 C4720 のインスタンスが新しく、あるいはより頻繁に発行される可能性があります。This new behavior can result in new and more-frequently issued instances of warning C4720.

    warning C4720: unreachable code
    

    多くの場合、この警告が発行されるのは、最適化を有効にしてコンパイルするときだけです。最適化により、より多くの関数呼び出しがインライン化されたり、冗長なコードが削除されたり、コードに制御が渡っていないことを他の方法で判別できるようになったりするためです。In many cases, this warning might only be issued when compiling with optimizations enabled, since optimizations may inline more function calls, eliminate redundant code, or otherwise make it possible to determine that certain code is unreachable. 警告 C4720 の新しいインスタンスが try/catch ブロックで頻繁に発生 (特に std::find の使用に関連して) していることが確認されています。We have observed that new instances of warning C4720 have frequently occurred in try/catch blocks, especially in relation to use of std::find.

    例 (変更前)Example (before)

    try
    {
        auto iter = std::find(v.begin(), v.end(), 5);
    }
    catch (...)
    {
        do_something();   // ok
    }
    

    例 (変更後)Example (after)

    try
    {
        auto iter = std::find(v.begin(), v.end(), 5);
    }
    catch (...)
    {
        do_something();   // warning C4702: unreachable code
    }
    

更新プログラム 2 の準拠の強化Conformance Improvements in Update 2

  • SFINAE 式の部分的なサポートの結果として、追加の警告とエラーが発行される場合があるAdditional warnings and errors might be issued as a result of partial support for expression SFINAE

    以前のバージョンのコンパイラは、SFINAE 式がサポートされていないため、指定子内の特定の種類の式を解析しませんでした decltypePrevious versions of the compiler did not parse certain kinds of expressions inside decltype specifiers due to lack of support for expression SFINAE. この従来の動作は正しい動作ではなく、C++ 標準に準拠していません。This old behavior was incorrect and doesn't conform to the C++ standard. コンパイラは、継続的な適合性の向上により、これらの式を解析し、SFINAE 式を部分的にサポートするようになりました。The compiler now parses these expressions and has partial support for expression SFINAE due to ongoing conformance improvements. その結果、コンパイラは、以前のバージョンのコンパイラが解析しなかった式で検出された警告とエラーを発行します。As a result, the compiler now issues warnings and errors found in expressions that previous versions of the compiler did not parse.

    この新しい動作によって、 decltype まだ宣言されていない型を含む式が解析されると、コンパイラはコンパイラエラー C2039 を結果として発行します。When this new behavior parses a decltype expression that includes a type that hasn't been declared yet, the compiler issues compiler error C2039 as a result.

    error C2039: 'type': is not a member of '`global namespace''
    

    例 1: 宣言されていない型の使用 (変更前)Example 1: use of an undeclared type (before)

    struct s1
    {
        template < typename T>
        auto f() - > decltype(s2< T> ::type::f());  // error C2039
    
        template< typename>
        struct s2 {};
    }
    

    例 1 (変更後)Example 1 (after)

    struct s1
    {
        template < typename>  // forward declare s2struct s2;
    
            template < typename T>
        auto f() - > decltype(s2< T> ::type::f());
    
        template< typename>
        struct s2 {};
    }
    

    この新しい動作によって、 decltype 依存名が型であることを指定するために必要なキーワードの使用が不足している式が解析されると、コンパイラ typename はコンパイラの警告 C4346 をコンパイラエラー C2923 と共に発行します。When this new behavior parses a decltype expression that's missing a necessary use of the typename keyword to specify that a dependent name is a type, the compiler issues compiler warning C4346 together with compiler error C2923.

    warning C4346: 'S2<T>::Type': dependent name is not a type
    
    error C2923: 's1': 'S2<T>::Type' is not a valid template type argument for parameter 'T'
    

    例 2: 依存名が型ではない (変更前)Example 2: dependent name isn't a type (before)

    template < typename T>
    struct s1
    {
        typedef T type;
    };
    
    template < typename T>
    struct s2
    {
        typedef T type;
    };
    
    template < typename T>
    T declval();
    
    struct s
    {
        template < typename T>
        auto f(T t) - > decltype(t(declval< S1< S2< T> ::type> ::type> ()));  // warning C4346, error C2923
    };
    

    例 2 (変更後)Example 2 (after)

    template < typename T> struct s1 { ... };  // as above
    template < typename T> struct s2 { ... };  // as above
    
    template < typename T>
    T declval();
    
    struct s
    {
        template < typename T>
        auto f(T t) - > decltype(t(declval< S1< typename S2< T> ::type> ::type> ()));
    };
    
  • volatile****メンバー変数は、暗黙的に定義されたコンストラクターと代入演算子を防ぎますvolatile member variables prevent implicitly defined constructors and assignment operators

    以前のバージョンのコンパイラでは、メンバー変数を持つクラスで、 volatile 既定のコピー/移動コンストラクターと既定のコピー/移動代入演算子が自動的に生成されるようになりました。Previous versions of the compiler allowed a class that has volatile member variables to have default copy/move constructors and default copy/move assignment operators automatically generated. この従来の動作は正しい動作ではなく、C++ 標準に準拠していません。This old behavior was incorrect and doesn't conform to the C++ standard. コンパイラは、メンバー変数を持つクラスが重要な構築および代入演算子を持つことを認識するようになりました。これに volatile より、これらの演算子の既定の実装が自動的に生成されるのを防ぐことができます。The compiler now considers a class that has volatile member variables to have non-trivial construction and assignment operators, which prevents default implementations of these operators from being automatically generated. そのようなクラスが共用体 (またはクラス内の匿名共用体) のメンバーである場合は、共用体のコピー/移動コンストラクターとコピー/移動代入演算子 (または匿名共用体を含むクラス) は、暗黙的に削除済みとして定義されます。When such a class is a member of a union (or an anonymous union inside of a class), the copy/move constructors and copy/move assignment operators of the union (or the class containing the anonymous union) will be implicitly defined as deleted. 明示的に定義することなく、共用体 (または無名共用体を含むクラス) を構築またはコピーしようとするとエラーとなり、結果として、コンパイラはコンパイラ エラー C2280 を発行します。Attempting to construct or copy the union (or class containing the anonymous union) without explicitly defining them is an error and the compiler issues compiler error C2280 as a result.

    error C2280: 'B::B(const B &)': attempting to reference a deleted function
    

    例 (変更前)Example (before)

    struct A
    {
        volatile int i;
        volatile int j;
    };
    
    extern A* pa;
    
    struct B
    {
        union
        {
            A a;
            int i;
        };
    };
    
    B b1{ *pa };
    B b2(b1);  // error C2280
    

    例 (変更後)Example (after)

    struct A
    {
        int i; int j;
    };
    
    extern volatile A* pa;
    
    A getA()  // returns an A instance copied from contents of pa
    {
        A a;
        a.i = pa - > i;
        a.j = pa - > j;
        return a;
    }
    
    struct B;  // as above
    
    B b1{ GetA() };
    B b2(b1);  // error C2280
    
  • 静的メンバー関数は、CV 修飾子をサポートしていません。Static member functions do not support cv-qualifiers.

    以前のバージョンの Visual Studio 2015 は、静的メンバー関数が CV 修飾子を持つことを許可していました。Previous versions of Visual Studio 2015 allowed static member functions to have cv-qualifiers. この動作は、Visual Studio 2015 および Visual Studio 2015 Update 1 での回帰が原因です。Visual Studio 2013 および以前のバージョンのコンパイラは、この方法で記述されたコードを拒否します。This behavior is due to a regression in Visual Studio 2015 and Visual Studio 2015 Update 1; Visual Studio 2013 and previous versions of the compiler reject code written in this way. Visual Studio 2015 および Visual Studio 2015 Update 1 の動作は正しいものではなく、C++ 標準に準拠していません。The behavior of Visual Studio 2015 and Visual Studio 2015 Update 1 is incorrect and doesn't conform to the C++ standard. Visual Studio 2015 Update 2 は、この方法で記述されたコードを拒否し、コンパイラ エラー C2511 を代わりに発行します。Visual Studio 2015 Update 2 rejects code written in this way and issues compiler error C2511 instead.

    error C2511: 'void A::func(void) const': overloaded member function not found in 'A'
    

    例 (変更前)Example (before)

    struct A
    {
        static void func();
    };
    
    void A::func() const {}  // C2511
    

    例 (変更後)Example(after)

    struct A
    {
        static void func();
    };
    
    void A::func() {}  // removed const
    
  • 列挙型の事前宣言は、WinRT コードでは許可されていません (/ZW にのみ影響)Forward declaration of enum is not allowed in WinRT code (only affects /ZW)

    Windows ランタイム (WinRT) 用にコンパイルされたコード enum では、コンパイラスイッチを使用して .Net Framework 用にマネージ C++ コードをコンパイルする場合と同様に、型を事前宣言することはできません /clrCode compiled for the Windows Runtime (WinRT) doesn't allow enum types to be forward declared, similarly to when managed C++ code is compiled for the .Net Framework using the /clr compiler switch. この動作により、確実に列挙型のサイズがわかり、WinRT 型システムに正しくプロジェクションを実行することができます。This behavior ensures that the size of an enumeration is always known and can be correctly projected to the WinRT type system. コンパイラは、この方法で記述されたコードを拒否し、コンパイラ エラー C3197 と共にコンパイラ エラー C2599 を発行します。The compiler rejects code written in this way and issues compiler error C2599 together with compiler error C3197.

    error C2599: 'CustomEnum': the forward declaration of a WinRT enum is not allowed
    
    error C3197: 'public': can only be used in definitions
    

    例 (変更前)Example (before)

    namespace A {
        public enum class CustomEnum : int32;  // forward declaration; error C2599, error C3197
    }
    
    namespace A {
        public enum class CustomEnum : int32
        {
            Value1
        };
    }
    
    public ref class Component sealed
    {
    public:
        CustomEnum f()
        {
            return CustomEnum::Value1;
        }
    };
    

    例 (変更後)Example (after)

              // forward declaration of CustomEnum removed
    namespace A {
        public enum class CustomEnum : int32
        {
            Value1
        };
    }
    
    public ref class Component sealed
    {
    public:
        CustomEnum f()
        {
            return CustomEnum::Value1;
        }
    };
    
  • オーバーロードされた非メンバー operator new と operator delete をインラインで宣言できない (レベル 1 (/W1) 既定で有効)Overloaded non-member operator new and operator delete may not be declared inline (Level 1 (/W1) on-by-default)

    以前のバージョンのコンパイラは、非メンバー operator new と operator delete 関数がインラインで宣言されるときに警告を発行しません。Previous versions of the compiler do not issue a warning when non-member operator new and operator delete functions are declared inline. この方法で記述されたコードは、形式が正しくなく (診断は必要なし)、new 演算子と delete 演算子の不一致 (特に、サイズ割り当て解除と共に使用された場合) から生じるメモリの問題を引き起こす可能性があります。この問題を診断するのは難しい場合があります。Code written in this way is ill-formed (no diagnostic required) and can cause memory issues resulting from mismatched new and delete operators (especially when used together with sized deallocation) that can be difficult to diagnose. コンパイラは警告 C4595 を発行するようになったので、この方法で記述されたコードを識別しやすくなりました。The compiler now issues compiler warning C4595 to help identify code written in this way.

    warning C4595: 'operator new': non-member operator new or delete functions may not be declared inline
    

    例 (変更前)Example (before)

    inline void* operator new(size_t sz)  // warning C4595
    {
        ...
    }
    

    例 (変更後)Example (after)

    void* operator new(size_t sz)  // removed inline
    {
        ...
    }
    

    この方法で記述されたコードを修正するには、演算子の定義をヘッダー ファイルから対応するソース ファイルに移動することが必要な場合があります。Fixing code that's written in this way might require that the operator definitions be moved out of a header file and into a corresponding source file.

更新プログラム 3 の準拠の強化Conformance Improvements in Update 3

  • std::is_convertable は self-assignment (標準ライブラリ) を検出するようになりましたstd::is_convertable now detects self-assignment (standard library)

    以前のバージョンの std::is_convertable type-trait は、コピー コンストラクターが削除済みまたはプライベートの場合、クラス型の自己代入を正しく検出していませんでした。Previous versions of the std::is_convertable type-trait did not correctly detect self-assignment of a class type when its copy constructor is deleted or private. これで、 std::is_convertable<>::value false 削除またはプライベートコピーコンストラクターを使用してクラス型に適用した場合、は正しくに設定されます。Now, std::is_convertable<>::value is correctly set to false when applied to a class type with a deleted or private copy constructor.

    この変更に関連するコンパイラの診断はありません。There is no compiler diagnostic associated with this change.

    Example

    #include <type_traits>
    
    class X1
    {
                public:
                X1(const X1&) = delete;
                };
    
    class X2
    {
                private:
                X2(const X2&);
                };
    
    static_assert(std::is_convertible<X1&, X1>::value, "BOOM");static_assert(std::is_convertible<X2&, X2>::value, "BOOM");
    

    以前のバージョンのコンパイラでは、 std::is_convertable<>::value が誤ってに設定されているため、この例の下部にある静的アサーションが成功し true ます。In previous versions of the compiler, the static assertions at the bottom of this example pass because std::is_convertable<>::value was incorrectly set to true. これで、 std::is_convertable<>::value はに正しく設定され false 、静的なアサーションは失敗します。Now, std::is_convertable<>::value is correctly set to false, causing the static assertions to fail.

  • 既定値にされた、または削除された単純なコピー コンストラクターと移動コンストラクターのアクセス指定子の尊重Defaulted or deleted trivial copy and move constructors respect access specifiers

    以前のバージョンのコンパイラは、既定値にされた、または削除された単純なコピー コンストラクターと移動コンストラクターを呼び出し前に確認していませんでした。Previous versions of the compiler did not check the access specifier of defaulted or deleted trivial copy and move constructors before allowing them to be called. この従来の動作は正しい動作ではなく、C++ 標準に準拠していません。This old behavior was incorrect and doesn't conform to the C++ standard. 場合によっては、この従来の動作のせいで、問題のあるコードが警告なしに生成される危険性が生じ、結果として、予期しないランタイム動作の原因となっていました。In some cases, this old behavior created a risk of silent bad code generation, resulting in unpredictable runtime behavior. コンパイラは、既定値に指定された、または削除された単純なコピー コンストラクターと移動コンストラクターをチェックし、呼び出し可能かどうかを判断し、呼び出し不能と判断した場合に、コンパイラの警告 C2248 を結果として返します。The compiler now checks the access specifier of defaulted or deleted trivial copy and move constructors to determine whether it can be called, and if not, issues compiler warning C2248 as a result.

    error C2248: 'S::S' cannot access private member declared in class 'S'
    

    例 (変更前)Example (before)

    class S {
    public:
        S() = default;
    private:
        S(const S&) = default;
    };
    
    void f(S);  // pass S by value
    
    int main()
    {
        S s;
        f(s);  // error C2248, can't invoke private copy constructor
    }
    

    例 (変更後)Example (after)

    class S {
    public:
        S() = default;
    private:
        S(const S&) = default;
    };
    
    void f(const S&);  // pass S by reference
    
    int main()
    {
        S s;
        f(s);
    }
    
  • 属性が指定された ATL コードのサポートの非推奨化 (デフォルトでレベル 1 (/W1))Deprecation of attributed ATL code support (Level 1 (/W1) on-by-default)

    以前のバージョンのコンパイラは、属性が指定された ATL コードをサポートしていました。Previous versions of the compiler supported attributed ATL code. Visual Studio 2008 から始まった、属性が指定された ATL コードのサポートを停止する次のフェーズとして、属性が指定された ATL コードは非推奨になりました。As the next phase of removing support for attributed ATL code that began in Visual Studio 2008, attributed ATL code has been deprecated. コンパイラは、非推奨になったこの種類のコードを特定するために、コンパイラの警告 C4467 を発行するようになりました。The compiler now issues compiler warning C4467 to help identify this kind of deprecated code.

    warning C4467: Usage of ATL attributes is deprecated
    

    コンパイラからサポートが削除されるまで、属性が指定された ATL コードを今後も使い続ける場合は、/Wv:18 または /wd:4467 コマンド ライン引数をコンパイラに渡すことで、またはソース コードに #pragma warning(disable:4467) を追加することで、この警告を無効にすることができます。If you want to continue using attributed ATL code until support is removed from the compiler, you can disable this warning by passing the /Wv:18 or /wd:4467 command-line arguments to the compiler, or by adding #pragma warning(disable:4467) in your source code.

    例 1 (変更前)Example 1 (before)

              [uuid("594382D9-44B0-461A-8DE3-E06A3E73C5EB")]
    class A {};
    

    例 1 (変更後)Example 1 (after)

    __declspec(uuid("594382D9-44B0-461A-8DE3-E06A3E73C5EB")) A {};
    

    非推奨になった ATL 属性の使用を防ぐために、次のコード例のように、IDL ファイルを作成する場合がありますSometimes you might need or want to create an IDL file to avoid the use deprecated ATL attributes, as in the example code below

    例 2 (変更後)Example 2 (before)

    [emitidl];
    [module(name = "Foo")];
    
    [object, local, uuid("9e66a290-4365-11d2-a997-00c04fa37ddb")]
    __interface ICustom {
        HRESULT Custom([in] long l, [out, retval] long *pLong);
        [local] HRESULT CustomLocal([in] long l, [out, retval] long *pLong);
    };
    
    [coclass, appobject, uuid("9e66a294-4365-11d2-a997-00c04fa37ddb")]
    class CFoo : public ICustom
    {
        // ...
    };
    

    まず、*.idl ファイルを作成します。vc140.idl で生成されるファイルを使用して、インターフェイスと注釈を含む *.idl ファイルを取得することができます。First, create the *.idl file; the vc140.idl generated file can be used to obtain an *.idl file containing the interfaces and annotations.

    次に、MIDL 手順をビルドに追加し、C++ インターフェイス定義が生成されるようにします。Next, add a MIDL step to your build to make sure that the C++ interface definitions are generated.

    例 2 IDL (変更後)Example 2 IDL (after)

    import "docobj.idl";
    
    [
        object, local, uuid(9e66a290 - 4365 - 11d2 - a997 - 00c04fa37ddb)
    ]
    
    interface ICustom : IUnknown {
        HRESULT  Custom([in] long l, [out, retval] long *pLong);
        [local] HRESULT  CustomLocal([in] long l, [out, retval] long *pLong);
    };
    
    [version(1.0), uuid(29079a2c - 5f3f - 3325 - 99a1 - 3ec9c40988bb)]
    library Foo
    {
        importlib("stdole2.tlb");
    importlib("olepro32.dll");
    [
        version(1.0),
        appobject,uuid(9e66a294 - 4365 - 11d2 - a997 - 00c04fa37ddb)
    ]
    
    coclass CFoo {
        interface ICustom;
    };
    }
    

    次に、以下のコード例のように、実装ファイルで ATL を直接使用します。Then, use ATL directly in the implementation file, as in the example code below.

    例 2 実装 (変更後)Example 2 Implementation (after)

    #include <idl.header.h>
    #include <atlbase.h>
    
    class ATL_NO_VTABLE CFooImpl :
        public ICustom,
        public ATL::CComObjectRootEx< CComMultiThreadModel>
    {
    public:
        BEGIN_COM_MAP(CFooImpl)
            COM_INTERFACE_ENTRY(ICustom)
        END_COM_MAP()
    };
    
  • プリコンパイル済みヘッダー (PCH) ファイルと一致しない #include ディレクティブ (/Wall /WX にのみ影響)Precompiled header (PCH) files and mismatched #include directives (only affects /Wall /WX)

    以前のバージョンのコンパイラは、プリコンパイル済みヘッダー (PCH) ファイルの使用時に、-Yc-Yu のコンパイル間のソース ファイルの #include ディレクティブ一致しない場合でも、受け入れていました。Previous versions of the compiler accepted mismatched #include directives in source files between -Yc and -Yu compilations when using precompiled header (PCH) files. この方法で記述されたコードは、コンパイラで処理できなくなります。Code written in this way is no longer accepted by the compiler. コンパイラは、PCH ファイルの使用時に #include ディレクティブの不一致を特定できるようにコンパイラの警告 CC4598 を発行するようになりました。The compiler now issues compiler warning CC4598 to help identify mismatched #include directives when using PCH files.

    warning C4598: 'b.h': included header file specified for Ycc.h at position 2 does not match Yuc.h at that position
    

    例 (変更前):Example (before):

    X.cpp (-Ycc.h)X.cpp (-Ycc.h)

    #include "a.h"
    #include "b.h"
    #include "c.h"
    

    Z.cpp (-Yuc.h)Z.cpp (-Yuc.h)

    #include "b.h"
    #include "a.h"  // mismatched order relative to X.cpp
    #include "c.h"
    

    例 (変更後)Example (after)

    X.cpp (-Ycc.h)X.cpp (-Ycc.h)

    #include "a.h"
    #include "b.h"
    #include "c.h"
    

    Z.cpp (-Yuc.h)Z.cpp (-Yuc.h)

    #include "a.h"
    #include "b.h" // matched order relative to X.cpp
    #include "c.h"
    
  • プリコンパイル済みヘッダー (PCH) ファイルと一致しない #include ディレクトリ (/Wall /WX にのみ影響)Precompiled header (PCH) files and mismatched include directories (only affects /Wall /WX)

    プリコンパイル済みヘッダー (PCH) ファイルの使用時に、以前のバージョンのコンパイラは、コンパイラ -Yc-Yu のコンパイルで一致しない include ディレクトリ (-I) コマンド ライン引数を受け入れていました。Previous versions of the compiler accepted mismatched include directory (-I) command-line arguments to the compiler between -Yc and -Yu compilations when using precompiled header (PCH) files. この方法で記述されたコードは、コンパイラで処理できなくなります。Code written in this way is no longer accepted by the compiler. コンパイラは、PCH ファイルの使用時に include ディレクトリ (-I) コマンド ライン引数を特定できるコンパイラの警告 CC4599 を発行するようになりました。The compiler now issues compiler warning CC4599 to help identify mismatched include directory (-I) command line arguments when using PCH files.

    warning C4599: '-I..' : specified for Ycc.h at position 1 does not match Yuc.h at that position
    

    例 (変更前)Example (before)

    cl /c /Wall /Ycc.h -I.. X.cpp
    cl /c /Wall /Yuc.h Z.cpp
    

    例 (変更後)Example (after)

    cl /c /Wall /Ycc.h -I.. X.cpp
    cl /c /Wall /Yuc.h -I.. Z.cpp
    

Visual Studio 2013 の準拠に関する変更Visual Studio 2013 Conformance Changes

コンパイラCompiler

  • Finalキーワードは、以前にコンパイルされた未解決のシンボルエラーを生成するようになりました。The final keyword now generates an unresolved symbol error where it would have compiled previously:

    struct S1 {
        virtual void f() = 0;
    };
    
    struct S2 final : public S1 {
        virtual void f();
    };
    
    int main(S2 *p)
    {
        p->f();
    }
    

    以前のバージョンでは、呼び出しが呼び出しであったため、エラーは発行されませんでしたが、 virtual 実行時にプログラムがクラッシュします。In earlier versions, an error wasn't issued because the call was a virtual call; nevertheless, the program would crash at runtime. 現在は、クラスが final であると認識されるため、リンカー エラーが発生します。Now, a linker error is issued because the class is known to be final. この例でエラーを解決するには、S2::f の定義を含む obj に対してリンクを行うことになります。In this example, to fix the error, you would link against the obj that contains the definition of S2::f.

  • コンパイラは現在 ISO C++ 標準に準拠しているため、名前空間の中でフレンド関数を使用する場合は、そのフレンド関数を参照する前に再宣言する必要があります。そうしない場合は、エラーが発生します。When you use friend functions in namespaces, you must redeclare the friend function before you refer to it or you will get an error because the compiler now conforms to the ISO C++ Standard. たとえば、次の例はコンパイルされなくなります。For example, this example no longer compiles:

    namespace NS {
        class C {
            void func(int);
            friend void func(C* const) {}
        };
    
        void C::func(int) {
            NS::func(this);  // error
        }
    }
    

    このコードを修正するには、関数を宣言し friend ます。To correct this code, declare the friend function:

    namespace NS {
        class C {
            void func(int);
            friend void func(C* const) {}
        };
    
        void func(C* const);  // conforming fix
    
        void C::func(int) {
            NS::func(this);
        }
    
  • C++ 標準では、クラス内で明示的な特殊化は許可されません。The C++ Standard doesn't allow explicit specialization in a class. Microsoft C++ コンパイラでは、特定の状況でこの作業を実行できますが、次の例のような状況では、現在はエラーが生成されます。コンパイラが、2 番目の関数が最初の関数の特殊化であることを認識しないことが原因です。Although the Microsoft C++ compiler allows it in some cases, in cases such as the following example, an error is now generated because the compiler doesn't consider the second function to be a specialization of the first one.

    template < int N>
    class S {
    public:
        template  void f(T& val);
        template < > void f(char val);
    };
    
    template class S< 1>;
    

    このコードを修正するには、2 番目の関数を変更します。To correct this code, modify the second function:

    template <> void f(char& val);
    
  • コンパイラでは、次の例に示す 2 つの関数のあいまいさの解消が行われなくなりました。現在ではエラーが出力されます。The compiler no longer tries to disambiguate the two functions in the following example, and now emits an error:

    template< typename T> void Func(T* t = nullptr);
    template< typename T> void Func(...);
    
    int main() {
        Func< int>(); // error
    }
    

    このコードを修正するには、呼び出しを明確にします。To correct this code, clarify the call:

    template< typename T> void Func(T* t = nullptr);
    template< typename T> void Func(...);
    
    int main() {
        Func< int>(nullptr); // ok
    }
    
  • コンパイラが ISO C++ 11 に準拠する前に、次のコードはコンパイルされ、型に解決されることになり x int ます。Before the compiler was made compliant with ISO C++11, the following code would have compiled and caused x to resolve to type int:

    auto x = {0};
    int y = x;
    

    このコードは、 x 型に解決されるようになり std::initializer_list<int> 、型に割り当てようとする次の行でエラーが発生し x int ます。This code now resolves x to a type of std::initializer_list<int> and causes an error on the next line that tries to assign x to type int. (既定では変換は行われません)。このコードを修正するには、を使用して int を置き換え auto ます。(There is no conversion by default.) To correct this code, use int to replace auto:

    int x = {0};
    int y = x;
    
  • 初期化の際に右辺値の型が左辺値の型と一致しない場合、集約の初期化は許可されなくなり、ISO C++11 標準では縮小変換を使用しない場合は均一な初期化が必要なためエラーが発行されます。Aggregate initialization is no longer allowed when the type of the right-hand value doesn't match the type of the left-hand value that's being initialized, and an error is issued because the ISO C++11 Standard requires uniform initialization to work without narrowing conversions. 以前は、縮小変換が使用できる場合、エラーの代わりにコンパイラの警告 (レベル 4) C4242 警告が発行されていました。Previously, if a narrowing conversion was available, a Compiler Warning (level 4) C4242 warning would have been issued instead of an error.

    int i = 0;
    char c = {i}; // error
    

    このコードを修正するには、明示的な縮小変換を追加します。To correct this code, add an explicit narrowing conversion:

    int i = 0;
    char c = {static_cast<char>(i)};
    
  • 次の初期化は、もう許可されません。The following initialization is no longer allowed:

    void *p = {{0}};
    

    このコードを修正するには、次の形式のどちらかを使用します。To correct this code, use either of these forms:

    void *p = 0;
    // or
    void *p = {0};
    
  • 名前参照が変更されました。Name lookup has changed. 次のコードは、Visual Studio 2012 の C++ コンパイラと Visual Studio 2013 の C++ コンパイラで結果が異なります。The following code is resolved differently in the C++ compiler in Visual Studio 2012 and Visual Studio 2013:

    enum class E1 { a };
    enum class E2 { b };
    
    int main()
    {
        typedef E2 E1;
        E1::b;
    }
    

    Visual Studio 2012 では、式 E1::b に含まれる E1 は、グローバル スコープ内の ::E1 に解決されていました。In Visual Studio 2012, the E1 in expression E1::b resolved to ::E1 in the global scope. Visual Studio 2013 では、式 E1::b に含まれる E1main() 内で typedef E2 定義に解決され、型は ::E2 になります。In Visual Studio 2013, E1 in expression E1::b resolves to the typedef E2 definition in main() and has type ::E2.

  • オブジェクトのレイアウトが変更されました。Object layout has changed. x64 では、クラスのオブジェクト レイアウトが以前のリリースから変更される場合があります。On x64, the object layout of a class may change from previous releases. 関数があり、関数 virtual を持つ基底クラスがない場合 virtual 、コンパイラのオブジェクトモデルは、 virtual データメンバーのレイアウトの後に関数テーブルへのポインターを挿入します。If it has a virtual function but it doesn't have a base class that has a virtual function, the object model of the compiler inserts a pointer to a virtual function table after the data member layout. これは、レイアウトがすべての場合に最適となるわけではないことを意味します。This means the layout may not be optimal in all cases. 以前のリリースでは、x64 の最適化によってレイアウトが調整されましたが、複雑なコードでは正常に機能しなかったため、Visual Studio 2013 では削除されました。In previous releases, an optimization for x64 would try to improve the layout for you, but because it failed to work correctly in complex code situations, it was removed in Visual Studio 2013. たとえば、次のコードを検討してみましょう。For example, consider this code:

    __declspec(align(16)) struct S1 {
    };
    
    struct S2 {
        virtual ~S2();
        void *p;
        S1 s;
    };
    
  • Visual Studio 2013 では、x64 の sizeof(S2) の結果は 48 ですが、以前のリリースでは 32 に評価されます。In Visual Studio 2013, the result of sizeof(S2) on x64 is 48, but in previous releases, it evaluates to 32. これを x64 の Visual Studio 2013 C++ コンパイラで32に評価するには、関数を持つダミー基底クラスを追加し virtual ます。To make this evaluate to 32 in the Visual Studio 2013 C++ compiler for x64, add a dummy base class that has a virtual function:

    __declspec(align(16)) struct S1 {
    };
    
    struct dummy {
        virtual ~dummy() {}
    };
    struct S2 : public dummy {
        virtual ~S2();
        void *p;
        S1 s;
    };
    

    以前のリリースで最適化しようとしたコード内の場所を検索するには、そのリリースのコンパイラオプションと /W3 コンパイラオプションを使用して、警告 C4370 を有効にします。To find places in your code that an earlier release would have tried to optimize, use a compiler from that release together with the /W3 compiler option and turn on warning C4370. 次に例を示します。For example:

    #pragma warning(default:4370)
    
    __declspec(align(16)) struct S1 {
    };
    
    struct S2 {
        virtual ~S2();
        void *p;
        S1 s;
    };
    

    Visual Studio 2013 以前のバージョンでは、このコードで "C4370: 'S2': パッキングの改善のために、前バージョンのコンパイラからクラスのレイアウトが変更されました" というメッセージが出力されます。Before Visual Studio 2013, this code outputs this message: "warning C4370: 'S2' : layout of class has changed from a previous version of the compiler due to better packing".

    x86 コンパイラでは、すべてのバージョンのコンパイラで同じ標準以下のレイアウト問題があります。The x86 compiler has the same suboptimal layout issue in all versions of the compiler. たとえば、次のコードが x86 でコンパイルされた場合を考えます。For example, if this code is compiled for x86:

    struct S {
        virtual ~S();
        int i;
        double d;
    };
    

    sizeof(S) の結果は 24 です。The result of sizeof(S) is 24. しかし、これは、説明した x64 の代替手段を使用すると 16 に減らせます。However, it can be reduced to 16 if you use the workaround mentioned for x64:

    struct dummy {
        virtual ~dummy() {}
    };
    
    struct S : public dummy {
        virtual ~S();
        int i;
        double d;
    };
    

標準ライブラリStandard Library

Visual Studio 2013 の C++ コンパイラは、Visual Studio 2010 で実装された _ITERATOR_DEBUG_LEVEL の不一致を検出し、RuntimeLibrary の不一致も検出します。The C++ compiler in Visual Studio 2013 detects mismatches in _ITERATOR_DEBUG_LEVEL, which was implemented in Visual Studio 2010, and RuntimeLibrary mismatches. これらの不一致は、コンパイラ オプション /MT (静的なリリース)、/MTd (静的なデバッグ)、/MD (動的なリリース)、および /MDd (動的なデバッグ) が混在する場合に発生します。These mismatches occur when compiler options /MT (static release), /MTd (static debug), /MD (dynamic release), and /MDd (dynamic debug) are mixed.

  • コードが、以前のリリースのシミュレートされたエイリアスのテンプレートを検出した場合、変更する必要があります。If your code acknowledges the previous release's simulated alias templates, you have to change it. たとえば、allocator_traits<A>::rebind_alloc<U>::other の代わりに、allocator_traits<A>::rebind_alloc<U> と指定する必要があります。For example, instead of allocator_traits<A>::rebind_alloc<U>::other, now you have to say allocator_traits<A>::rebind_alloc<U>. ratio_add<R1, R2>::type は必要でなくなり、ratio_add<R1, R2> を使うことが勧められていますが、前者でもコンパイルは可能です。これは、ratio<N, D> を使用して圧縮するには、typedef "型" が必要であるためです (既に圧縮されている場合も同じ型を使用します)。Although ratio_add<R1, R2>::type is no longer necessary and we now recommend that you say ratio_add<R1, R2>, the former will still compile because ratio<N, D> is required to have a "type" typedef for a reduced ratio, which will be the same type if it's already reduced.

  • #include <algorithm> または std::min()を呼び出すときに、std::max() を使用する必要があります。You must use #include <algorithm> when you call std::min() or std::max().

  • 既存のコードで以前のリリースのシミュレートされたスコープの列挙型を使用している場合 (名前空間にラップされた従来の対象外の列挙型)、それを変更する必要があります。If your existing code uses the previous release's simulated scoped enums—traditional unscoped enums wrapped in namespaces—you have to change it. たとえば、型 std::future_status::future_status を参照していた場合は、std::future_status を指定する必要があります。For example, if you referred to the type std::future_status::future_status, now you have to say std::future_status. ただし、ほとんどのコードは影響を受けません。たとえば、std::future_status::ready は引き続きコンパイルされます。However, most code is unaffected—for example, std::future_status::ready still compiles.

  • explicit operator bool() は、演算子 unspecified-bool-type() よりも厳格です。explicit operator bool() is stricter than operator unspecified-bool-type(). explicit operator bool() を使用すると、bool に明示的に変換できます。たとえば、shared_ptr<X> sp を使用している場合、static_cast<bool>(sp)bool b(sp) の両方が有効です。また、if (sp)!spsp && などのブール値検証可能な bool への "状況依存型変換" も用意されています。explicit operator bool() permits explicit conversions to bool—for example, given shared_ptr<X> sp, both static_cast<bool>(sp) and bool b(sp) are valid—and Boolean-testable "contextual conversions" to bool—for example, if (sp), !sp, sp && whatever. ただし、explicit operator bool() は bool への暗黙の変換を禁止するため、bool b = sp; と指定することはできません。また bool を戻り値の型として指定したり、return sp を指定したりすることもできません。However, explicit operator bool() forbids implicit conversions to bool, so you can't say bool b = sp; and given a bool return type, you can't say return sp.

  • 現在は、実際の可変個引数テンプレートが実装されているため、_VARIADIC_MAX と関連マクロは何の影響も及ぼしません。Now that real variadic templates are implemented, _VARIADIC_MAX and related macros have no effect. 依然として _VARIADIC_MAX を定義している場合は、無視されます。If you're still defining _VARIADIC_MAX, it's ignored. シミュレートされた可変個引数テンプレートを他の方法でサポートすることを意図して Microsoft のマクロ メカニズムを活用していた場合は、コードを変更する必要があります。If you acknowledged our macro machinery intended to support simulated variadic templates in any other way, you have to change your code.

  • 通常のキーワードに加えて、C++ 標準ライブラリ ヘッダーは状況依存のキーワード overridefinal のマクロ置換を禁止するようになりました。In addition to ordinary keywords, C++ Standard Library headers now forbid the macro replacement of the context-sensitive keywords override and final.

  • reference_wrapperref()、および cref() は、一時オブジェクトへのバインディングを禁止するようになります。reference_wrapper, ref(), and cref() now forbid binding to temporary objects.

  • <random>では、コンパイル時の事前条件が厳密に適用されるようになりました。<random> now strictly enforces its compile-time preconditions.

  • さまざまな C++ 標準ライブラリ型の特徴は、"T は完全な型であるものとする" という事前条件を持つことです。Various C++ Standard Library type traits have the precondition "T shall be a complete type". コンパイラは、この事前条件をより厳密に実装するようになりましたが、あらゆる状況でこのことを強制するとは限りません。Although the compiler now enforces this precondition more strictly, it may not enforce it in all situations. (C++ 標準ライブラリ事前条件に違反すると、未定義の動作がトリガーされるため、標準では、強制を保証していません)。(Because C++ Standard Library precondition violations trigger undefined behavior, the Standard doesn't guarantee enforcement.)

  • C++ 標準ライブラリは /clr:oldSyntax をサポートしていません。The C++ Standard Library doesn't support /clr:oldSyntax.

  • Common_type<> の C++ 11 仕様には、予期しない、望ましくない結果がありました。特に、common_type <int, int> :: type は int&& を返します。The C++11 specification for common_type<> had unexpected and undesired consequences; in particular, it makes common_type<int, int>::type return int&&. このため、コンパイラはライブラリの作業グループの問題2141に対して提案された解決策を実装します。これにより common_type <int, int=""> :: type は int を返します。Therefore, the compiler implements the Proposed Resolution for Library Working Group issue 2141, which makes common_type<int, int="">::type return int.

    この変更の副作用として、id ケースは機能しなくなりました (common_type は <T> 常に型 t になるとは限りません)。As a side-effect of this change, the identity case no longer works (common_type<T> doesn't always result in type T). この動作は、上記の「推奨される解決」に準拠していますが、コードの互換性に影響があります。This behavior complies with the Proposed Resolution, but it breaks any code that relied on the previous behavior.

    ID 型の特徴が必要な場合、 std::identity で定義された非標準の <type_traits> は <void>で機能しないので使用しないでください。If you require an identity type trait, don't use the non-standard std::identity that's defined in <type_traits> because it won't work for <void>. 代わりに、要件に応じた独自の ID 対応の動作を実装します。Instead, implement your own identity type trait to suit your needs. 次に例を示します。Here's an example:

    template < typename T> struct Identity {
        typedef T type;
    };
    

MFC と ATLMFC and ATL

  • Visual Studio 2013 のみ: Unicode が広く使用されていて、MBCS の使用が大幅に拒否されたため、MFC MBCS ライブラリは Visual Studio に含まれていません。Visual Studio 2013 only: MFC MBCS Library isn't included in Visual Studio because Unicode is so popular and use of MBCS has declined significantly. この変更により、新しいコントロールとメッセージの多くは Unicode 専用になったため、MFC は Windows SDK 自体により緊密に整合するようになりました。This change also keeps MFC more closely aligned with the Windows SDK itself, because many of the new controls and messages are Unicode-only. ただし、MFC MBCS ライブラリを引き続き使用する必要がある場合は、Microsoft ダウンロードセンターの「 Visual Studio 2013 用のマルチバイト MFC ライブラリ」からダウンロードできます。However, if you must continue to use the MFC MBCS library, you can download it from the Microsoft Download Center at Multibyte MFC Library for Visual Studio 2013. Visual C++ 再頒布可能パッケージにも、引き続きこのライブラリが含まれています。The Visual C++ Redistributable Package still includes this library. (注: MBCS DLL は Visual Studio 2015 以降の C++ セットアップ コンポーネントに含まれています。)(Note: The MBCS DLL is included in the C++ setup components in Visual Studio 2015 and later).

  • MFC リボンのアクセシビリティが変更されました。Accessibility for the MFC ribbon is changed. 1 レベルのアーキテクチャではなく、階層的なアーキテクチャが用意されました。Instead of a one-level architecture, there is now a hierarchical architecture. CRibbonBar::EnableSingleLevelAccessibilityMode() を呼び出して、引き続き古い動作を使用することもできます。You can still use the old behavior by calling CRibbonBar::EnableSingleLevelAccessibilityMode().

  • CDatabase::GetConnect メソッドは削除されました。CDatabase::GetConnect method is removed. セキュリティを改善するために、接続文字列は暗号化された状態で格納され、必要な場合にのみ復号化されるようになりました。プレーンテキストとして返すことはできません。To improve security, the connection string is now stored encrypted and is decrypted only as needed; it can't be returned as plain text. この文字列を取得するには、CDatabase::Dump メソッドを使用します。The string can be obtained by using the CDatabase::Dump method.

  • CWnd::OnPowerBroadcast のシグネチャが変更されました。Signature of CWnd::OnPowerBroadcast is changed. このメッセージ ハンドラーのシグネチャは、2 番目のパラメーターとして LPARAM を受け取るように変更されました。The signature of this message handler is changed to take an LPARAM as the second parameter.

  • メッセージ ハンドラーに対応するためにシグネチャが変更されました。Signatures are changed to accommodate message handlers. 新しく追加された ON_WM_* メッセージ ハンドラーを使用するために、次の関数のパラメーター リストが変更されました。The parameter lists of the following functions have been changed to use newly added ON_WM_* message handlers:

    • CWnd::OnDisplayChange は (WPARAM, LPARAM) から (UINT, int, int) に変更され、メッセージ マップに新しい ON_WM_DISPLAYCHANGE マクロを使用できるようになりました。CWnd::OnDisplayChange changed to (UINT, int, int) instead of (WPARAM, LPARAM) so that the new ON_WM_DISPLAYCHANGE macro can be used in the message map.

    • CFrameWnd::OnDDEInitiate は (WPARAM, LPARAM) から (CWnd*, UINT, UNIT) に変更され、メッセージ マップに新しい ON_WM_DDE_INITIATE マクロを使用できるようになりました。CFrameWnd::OnDDEInitiate changed to (CWnd*, UINT, UNIT) instead of (WPARAM, LPARAM) so that the new ON_WM_DDE_INITIATE macro can be used in the message map.

    • CFrameWnd::OnDDEExecute は (WPARAM, LPARAM) から (CWnd*, HANDLE) に変更され、メッセージ マップに新しい ON_WM_DDE_EXECUTE マクロを使用できるようになりました。CFrameWnd::OnDDEExecute changed to (CWnd*, HANDLE) instead of (WPARAM, LPARAM) so that the new ON_WM_DDE_EXECUTE macro can be used in the message map.

    • CFrameWnd::OnDDETerminate のパラメーターは (WPARAM, LPARAM) から (CWnd*) に変更され、メッセージ マップに新しい ON_WM_DDE_TERMINATE マクロを使用できるようになりました。CFrameWnd::OnDDETerminate changed to (CWnd*) as the parameter instead of (WPARAM, LPARAM) so that the new ON_WM_DDE_TERMINATE macro can be used in the message map.

    • CMFCMaskedEdit::OnCut は (WPARAM, LPARAM) からパラメーターなしに変更され、メッセージ マップで新しい ON_WM_CUT マクロを使用できるようになりました。CMFCMaskedEdit::OnCut changed to no parameters instead of (WPARAM, LPARAM) so that the new ON_WM_CUT macro can be used in the message map.

    • CMFCMaskedEdit::OnClear は (WPARAM, LPARAM) からパラメーターなしに変更され、メッセージ マップで新しい ON_WM_CLEAR マクロを使用できるようになりました。CMFCMaskedEdit::OnClear changed to no parameters instead of (WPARAM, LPARAM) so that the new ON_WM_CLEAR macro can be used in the message map.

    • CMFCMaskedEdit::OnPaste は (WPARAM, LPARAM) からパラメーターなしに変更され、メッセージ マップで新しい ON_WM_PASTE マクロを使用できるようになりました。CMFCMaskedEdit::OnPaste changed to no parameters instead of (WPARAM, LPARAM) so that the new ON_WM_PASTE macro can be used in the message map.

  • #ifdef ディレクティブは MFC ヘッダー ファイル内から削除されました。#ifdef directives in the MFC header files are removed. MFC ヘッダー ファイル内に存在していた、サポートされていないバージョンの Windows (WINVER < 0x0501) に関連する多数の #ifdef ディレクティブが削除されました。Numerous #ifdef directives in the MFC header files related to unsupported versions of Windows (WINVER < 0x0501) are removed.

  • ATL DLL (atl120.dll) が削除されました。ATL DLL (atl120.dll) is removed. ATL は、ヘッダーおよび 1 つのスタティック ライブラリ (atls.lib) として提供されるようになりました。ATL is now provided as headers and a static library (atls.lib).

  • atlsd.lib、atlsn.lib、および atlsnd.lib が削除されました。Atlsd.lib, atlsn.lib, and atlsnd.lib are removed. atls.lib は、文字セットに対する依存関係を持たず、デバッグ/リリースに固有のコードも含まなくなりました。Atls.lib no longer has character-set dependencies or code that's specific for debug/release. これは、Unicode/ANSI のどちらでも、またデバッグ/リリースのどちらでも同じ動作をするため、このライブラリのただ 1 つのバージョンが必要とされるようになりました。Because it works the same for Unicode/ANSI and debug/release, only one version of the library is required.

  • ATL DLL と共に ATL/MFC Trace Tool が削除され、トレース機構が簡略化されました。ATL/MFC Trace tool is removed together with the ATL DLL, and the tracing mechanism is simplified. CTraceCategory コンストラクターは 1 つのパラメーター (カテゴリ名) を受け取り、TRACE マクロは CRT のデバッグ レポート関数を呼び出します。The CTraceCategory constructor now takes one parameter (the category name), and the TRACE macros call the CRT debug reporting functions.

Visual Studio 2012 の重要な変更点Visual Studio 2012 Breaking Changes

コンパイラCompiler

  • /Yl コンパイラ オプションは変更されました。The /Yl compiler option has changed. コンパイラは既定でこのオプションを使用しますが、状況によっては LNK2011 エラーが発生する可能性があります。By default, the compiler uses this option, which can lead to LNK2011 errors under certain conditions. 詳細については、「/Yl (Inject PCH Reference for Debug Library)」(/Yl (デバッグ ライブラリの PCH 参照の挿入)) を参照してください。For more information, see /Yl (Inject PCH Reference for Debug Library).

  • を使用してコンパイルされたコードでは /clrenum class キーワードは、共通言語ランタイム (CLR) の列挙型ではなく、c++ 11 の列挙型を定義します。In code that's compiled by using /clr, the enum class keyword defines a C++11 enum, not a common language runtime (CLR) enum. CLR enum を定義するには、アクセシビリティを明示する必要があります。To define a CLR enum, you must be explicit about its accessibility.

  • 依存名を明確に区別するには、テンプレート キーワードを使用します (C++ 言語標準の準拠)。Use the template keyword to explicitly disambiguate a dependent name (C++ Language Standard compliance). 次の例では、あいまいさを解決するために、強調表示されたテンプレート キーワードを使用する必要があります。In the following example, the highlighted template keyword is mandatory to resolve the ambiguity. 詳細については、「Name Resolution for Dependent Types」(依存する型の名前解決) を参照してください。For more information, see Name Resolution for Dependent Types.

    template < typename X = "", typename = "" AY = "">
    struct Container { typedef typename AY::template Rebind< X> ::Other AX; };
    
  • float 型の定数式は、次の例のようにテンプレート引数として使用できなくなりました。Constant expression of type float is no longer allowed as a template argument, as shown in the following example.

    template<float n=3.14>
    struct B {};  // error C2993: 'float': illegal type for non-type template parameter 'n'
    
  • /GS コマンドライン オプションを使用してコンパイルし、off-by-one の脆弱性があるコードの場合、次の疑似コード例で示すように、実行時にプロセスが停止する可能性があります。Code that's compiled by using the /GS command-line option and that has an off-by-one vulnerability may lead to process termination at runtime, as shown in the following pseudocode example.

    char buf[MAX]; int cch; ManipulateString(buf, &cch); // ... buf[cch] = '\0'; // if cch >= MAX, process will terminate
    
  • x86 ビルドの既定のアーキテクチャは SSE2 に変更されたため、コンパイラから SSE 命令が発せられる可能性があります。その結果、XMM レジスタを使用して浮動小数点演算が実行されます。The default architecture for x86 builds is changed to SSE2; therefore, the compiler may emit SSE instructions, and will use the XMM registers to perform floating-point calculations. 以前の動作に戻すには、/arch:IA32 コンパイラ フラグを使用してアーキテクチャを IA32 と指定します。If you want to revert to previous behavior, then use the /arch:IA32 compiler flag to specify the architecture as IA32.

  • コンパイラから、以前は発行されなかったコンパイラの警告 (レベル 4) C4703 と C4701 が発行される可能性があります。The compiler may issue warnings Compiler Warning (level 4) C4703 and C4701 where previously it did not. コンパイラでは、ポインター型の初期化されていないローカル変数の使用がより厳格にチェックされるようになりました。The compiler applies stronger checks for use of uninitialized local variables of pointer type.

  • 新しいリンカー フラグ /HIGHENTROPYVA を指定すると、通常 Windows 8 では、メモリの割り当てが実行され、64 ビット アドレスが返されます When the new linker flag /HIGHENTROPYVA is specified, Windows 8 typically causes memory allocations to return a 64-bit address. (Windows 8 より前の場合、このような割り当てでは、2 GB 未満のアドレスが返されることが多くなります)。この変更により、既存のコードでポインターの切り捨てのバグが発生する可能性があります。(Prior to Windows 8, such allocations more often returned addresses that were less than 2 GB.) This change may expose pointer truncation bugs in existing code. 既定では、このスイッチはオンです。By default, this switch is on. この動作を無効にするには、/HIGHENTROPYVA:NO を指定します。To disable this behavior, specify /HIGHENTROPYVA:NO.

  • マネージド コンパイラ (Visual Basic/C#) は、マネージド ビルドの場合に /HIGHENTROPYVA もサポートしています。The managed compiler (Visual Basic/C#) also supports /HIGHENTROPYVA for managed builds. ただし、この場合、/HIGHENTROPYVAswitch は既定でオフです。However, in this case, the /HIGHENTROPYVAswitch is off by default.

IDEIDE

  • C++/CLI で Windows フォーム アプリケーションを作成しないことをお勧めしますが、既存の C++/CLI UI アプリケーションの保守はサポートされます。Although we recommend that you do not create Windows Forms applications in C++/CLI, maintenance of existing C++/CLI UI applications is supported. Windows フォーム アプリケーションやその他の .NET UI アプリケーションを作成する必要がある場合は、C# または Visual Basic を使用してください。If you have to create a Windows Forms application, or any other .NET UI application, use C# or Visual Basic. C++/CLI は、相互運用性の目的でのみ使用してください。Use C++/CLI for interoperability purposes only.

並列パターン ライブラリとコンカレンシー ランタイム ライブラリParallel Patterns Library and Concurrency Runtime Library

UmsThreadDefaultSchedulerType 列挙体は非推奨です。The SchedulerType enumeration of UmsThreadDefault is deprecated. UmsThreadDefault を指定すると、非推奨の警告が生成され、内部的に ThreadScheduler にマップされます。Specification of UmsThreadDefault produces a deprecated warning, and internally maps back to the ThreadScheduler.

標準ライブラリStandard Library

  • C++98/03 標準と C++11 標準間の破壊的変更に伴い、明示的なテンプレート引数を使用して (make_pair<int, int>(x, y) のように) make_pair() を呼び出しても、一般的に Visual Studio 2012 の Visual C++ ではコンパイルされなくなりました。Following a breaking change between the C++98/03 and C++11 standards, using explicit template arguments to call make_pair() — as in make_pair<int, int>(x, y) — typically doesn't compile in Visual C++ in Visual Studio 2012. このソリューションでは、 make_pair() のように、明示的なテンプレート引数を指定せずに常にを呼び出し make_pair(x, y) ます。The solution is to always call make_pair() without explicit template arguments — as in make_pair(x, y). 明示的なテンプレート引数を指定すると、この関数の目的を達成できません。Providing explicit template arguments defeats the purpose of the function. 結果の型を正確に制御する必要がある場合は、pair<short, short>(int1, int2) のように make_pair ではなく pair を使用します。If you require precise control over the resulting type, use pair instead of make_pair — as in pair<short, short>(int1, int2).

  • C++ 98/03 と C++ 11 標準の間のもう1つの重大な変更: が暗黙的に B に変換可能で、B が暗黙的に C に変換可能ではありませんが、が C に暗黙的に変換可能ではありません。 C++ 98/03 および Visual Studio 2010 は、 pair<A, X> 暗黙的または明示的に変換することができ pair<C, X> ます。Another breaking change between the C++98/03 and C++11 standards: When A is implicitly convertible to B and B is implicitly convertible to C, but A isn't implicitly convertible to C, C++98/03 and Visual Studio 2010 permitted pair<A, X> to be converted (implicitly or explicitly) to pair<C, X>. (もう1つの型である X は、ここでは重要ではなく、ペアの最初の型に固有ではありません)。Visual Studio 2012 の C++ コンパイラは、が暗黙的に C に変換できないことを検出し、オーバーロードの解決からペアの変換を削除します。(The other type, X, isn't of interest here, and isn't specific to the first type in the pair.) The C++ compiler in Visual Studio 2012 detects that A isn't implicitly convertible to C, and removes the pair conversion from overload resolution. この変更は、多くのシナリオでは、よい結果になります。This change is a positive for many scenarios. たとえば、この変更で、func(const pair<int, int>&)func(const pair<string, string>&) のオーバーロードと、pair<const char *, const char *> を指定した func() の呼び出しはコンパイルされるようになります。For example, overloading func(const pair<int, int>&) and func(const pair<string, string>&), and calling func() with pair<const char *, const char *> will compile with this change. ただし、積極的なペアの変換に依存するコードの場合、これは互換性に影響する変更です。However, this change breaks code that relied on aggressive pair conversions. 通常、このようなコードを修正するには、変換の一部を明示的に実行します。たとえば、make_pair(static_cast<B>(a), x)pair<C, X> を受け取る関数に渡します。Such code can typically be fixed by performing one part of the conversion explicitly—for example, by passing make_pair(static_cast<B>(a), x) to a function that expects pair<C, X>.

  • Visual Studio 2010 では、プリプロセッサのメカニズムでオーバーロードと特殊化を排除することで、引数の上限が 10 個の可変個引数テンプレート (たとえば、make_shared<T>(arg1, arg2, argN)) のシミュレーションが行われていました。Visual Studio 2010 simulated variadic templates—for example, make_shared<T>(arg1, arg2, argN)—up to a limit of 10 arguments, by stamping out overloads and specializations with preprocessor machinery. Visual Studio 2012 では、引数の上限は 5 個まで減ったので、多くのユーザーは、コンパイル時間とコンパイラのメモリ使用量が改善されました。In Visual Studio 2012, this limit is reduced to five arguments to improve compile times and compiler memory consumption for the majority of users. ただし、プロジェクト全体で _VARIADIC_MAX を 10 と明示的に定義することで、以前の上限を設定できます。However, you can set the previous limit by explicitly defining _VARIADIC_MAX as 10, project-wide.

  • C++ 標準ライブラリのヘッダーを含める場合、C++11 17.6.4.3.1 [macro.names]/2 では、キーワードのマクロ置換が禁止されるようになりました。C++11 17.6.4.3.1 [macro.names]/2 forbids macro replacement of keywords when C++ Standard Library headers are included. マクロ置換されたキーワードが検出されると、ヘッダーからコンパイラ エラーが発行されますThe headers now emit compiler errors if they detect macro-replaced keywords. (_ALLOW_KEYWORD_MACROS を定義すると、そのようなコードをコンパイルできますが、その使用は強くお勧めしません)。例外として、のマクロ形式 new が既定で許可されてい #pragma push_macro("new") / #undef new / #pragma pop_macro("new") ます。これは、ヘッダーがを使用して包括的に保護するためです。(Defining _ALLOW_KEYWORD_MACROS allows such code to compile, but we strongly discourage that usage.) As an exception, the macro form of new is permitted by default, because the headers comprehensively defend themselves by using #pragma push_macro("new")/#undef new/#pragma pop_macro("new"). _ENFORCE_BAN_OF_MACRO_NEW を定義すると、その名前が示すとおりの処理が実行されます。Defining _ENFORCE_BAN_OF_MACRO_NEW does exactly what its name implies.

  • 多様な最適化とデバッグのチェックを実装するために、C++ 標準ライブラリの実装では、バイナリの互換性が Visual Studio のバージョン (2005、2008、2010、2012) ごとに意図的に保たれていません。To implement various optimizations and debugging checks, the C++ Standard Library implementation intentionally breaks binary compatibility among versions of Visual Studio (2005, 2008, 2010, 2012). C++ 標準ライブラリを使用すると、異なるバージョンを使用してコンパイルされたオブジェクト ファイルとスタティック ライブラリは 1 つのバイナリ (EXE または DLL) に混在させることができず、C++ 標準ライブラリ オブジェクトは異なるバージョンを使用してコンパイルされたバイナリ間で渡すことができません。When the C++ Standard Library is used, it forbids the mixing of object files and static libraries that are compiled by using different versions into one binary (EXE or DLL), and forbids the passing of C++ Standard Library objects between binaries that are compiled by using different versions. Visual Studio 2010 を使用してコンパイルした (C++ 標準ライブラリを使用する) オブジェクト ファイルとスタティック ライブラリと、Visual Studio 2012 の C++ コンパイラを使用してコンパイルしたものが混在すると、_MSC_VER の不一致に関するリンカー エラーが発生します。この _MSC_VER は、コンパイラのメジャー バージョン (Visual Studio 2012 の Visual C++ の場合は 1700) を含むマクロです。The mixing of object files and static libraries (using the C++ Standard Library that were compiled by using Visual Studio 2010 with ones that were compiled by using The C++ compiler in Visual Studio 2012 emits linker errors about _MSC_VER mismatch, where _MSC_VER is the macro that contains the compiler's major version (1700 for Visual C++ in Visual Studio 2012). このチェックでは、DLL の混在を検出できず、Visual Studio 2008 以前のバージョンが関係する混在も検出できません。This check can't detect DLL mixing, and can't detect mixing that involves Visual Studio 2008 or earlier.

  • Visual Studio 2012 の C++ コンパイラでは、Visual Studio 2010 で実装された _ITERATOR_DEBUG_LEVEL の不一致の検出に加え、ランタイム ライブラリの不一致も検出します。In addition to detecting _ITERATOR_DEBUG_LEVEL mismatches, which was implemented in Visual Studio 2010, The C++ compiler in Visual Studio 2012 detects Runtime Library mismatches. これらの不一致は、コンパイラ オプション /MT (静的なリリース)、/MTd (静的なデバッグ)、/MD (動的なリリース)、および /MDd (動的なデバッグ) が混在する場合に発生します。These mismatches occur when the compiler options /MT (static release), /MTd (static debug), /MD (dynamic release), and /MDd (dynamic debug) are mixed.

  • operator<()operator>()operator<=()、および operator>=() は、以前はコンテナーの std::unordered_map および stdext::hash_map ファミリに使用できましたが、実装しても役に立っていませんでした。operator<(), operator>(), operator<=(), and operator>=() were previously available for the std::unordered_map and stdext::hash_map families of containers, although their implementations were not useful. これらの標準ではない演算子は、Visual Studio 2012 の Visual C++ から削除されました。These non-standard operators have been removed in Visual C++ in Visual Studio 2012. また、std::unordered_map ファミリの operator==() および operator!=() の実装は、stdext::hash_map ファミリも対象にするように拡張されました Additionally, the implementation of operator==() and operator!=() for the std::unordered_map family has been extended to cover the stdext::hash_map family. (新しいコードでは、stdext::hash_map ファミリを使用しないことをお勧めします)。(We recommend that you avoid the use of the stdext::hash_map family in new code.)

  • C++11 22.4.1.4 [locale.codecvt] では、変更可能な stateT&パラメーターが codecvt::length()codecvt::do_length() によって取得されるように指定されていましたが、Visual Studio 2010 によって const stateT& が取得されました。C++11 22.4.1.4 [locale.codecvt] specifies that codecvt::length() and codecvt::do_length() should take modifiable stateT& parameters, but Visual Studio 2010 took const stateT&. Visual Studio 2012 の C++ コンパイラは、標準で必須のパラメーターとして stateT& を受け取ります。The C++ compiler in Visual Studio 2012 takes stateT& as mandated by the standard. この違いは、仮想関数 do_length() をオーバーライドする場合に重要になります。This difference is significant for anyone who is attempting to override the virtual function do_length().

CRTCRT

  • C ランタイム (CRT) ヒープは new と malloc() に使用されますが、プライベートではなくなりました。The C Runtime (CRT) heap, which is used for new and malloc(), is no longer private. CRT はプロセス ヒープを使用するようになりました。The CRT now uses the process heap. これは、DLL がアンロードされたときにヒープが破棄されないことを意味します。そのため、CRT に静的にリンクする Dll は、DLL コードによって割り当てられたメモリがアンロードされる前にクリーンアップされるようにする必要があります。This means that the heap isn't destroyed when a DLL is unloaded, so DLLs that link statically to the CRT must ensure memory that's allocated by the DLL code is cleaned up before it's unloaded.

  • iscsymf() 関数は負の値でアサートします。The iscsymf() function asserts with negative values.

  • threadlocaleinfostruct 構造体は、ロケール関数の変更に対応するために変更されました。The threadlocaleinfostruct struct has changed to accommodate the changes to locale functions.

  • memxxx()strxxx() などの対応する組み込みがある CRT 関数は intrin.h から削除されました。CRT functions that have corresponding intrinsics such as memxxx(), strxxx() are removed from intrin.h. これらの関数のためにのみ intrin.h を含めた場合、今後は対応する CRT ヘッダーも含める必要があります。If you included intrin.h only for these functions, you must now include the corresponding CRT headers.

MFC と ATLMFC and ATL

  • Fusion サポート (afxcomctl32.h) が削除されました。したがって、で定義されているすべてのメソッド <afxcomctl32.h> が削除されています。Removed Fusion support (afxcomctl32.h); therefore, all methods that are defined in <afxcomctl32.h> have been removed. ヘッダーファイル <afxcomctl32.h> と <afxcomctl32.inl> が削除されました。Header files <afxcomctl32.h> and <afxcomctl32.inl> have been deleted.

  • CDockablePane::RemoveFromDefaultPaneDividier の名前は CDockablePane::RemoveFromDefaultPaneDivider に変更されました。Changed the name of CDockablePane::RemoveFromDefaultPaneDividier to CDockablePane::RemoveFromDefaultPaneDivider.

  • LPCTSTR を使用するように CFileDialog::SetDefExt のシグネチャは変更されました。そのため、Unicode のビルドに影響があります。Changed the signature of CFileDialog::SetDefExt to use LPCTSTR; therefore, Unicode builds are affected.

  • 互換性のために残されていた ATL トレース カテゴリは削除されました。Removed obsolete ATL tracing categories.

  • const CRect を受け取るように CBasePane::MoveWindow のシグネチャは変更されました。Changed the signature of CBasePane::MoveWindow to take a const CRect.

  • CMFCEditBrowseCtrl::EnableBrowseButton のシグネチャは変更されました。Changed the signature of CMFCEditBrowseCtrl::EnableBrowseButton.

  • CMFCBaseTabCtrl から m_fntTabs および m_fntTabsBold を削除しました。Removed m_fntTabs and m_fntTabsBold from CMFCBaseTabCtrl.

  • CMFCRibbonStatusBarPane コンストラクターにパラメーターが追加されました Added a parameter to the CMFCRibbonStatusBarPane constructors. (これは既定のパラメーターなので、ソースの重大な変更ではありません)。(It is a default parameter, and so it's not source-breaking.)

  • CMFCRibbonCommandsListBox コンストラクターにパラメーターが追加されました Added a parameter to the CMFCRibbonCommandsListBox constructor. (これは既定のパラメーターなので、ソースの重大な変更ではありません)。(It is a default parameter, and so it's not source-breaking.)

  • AFXTrackMouse API (と関連する timer proc) が削除されました。Removed the AFXTrackMouse API (and related timer proc). 代わりに、Win32 API TrackMouseEventを使用します。Use the Win32 TrackMouseEvent API instead.

  • CFolderPickerDialog コンストラクターにパラメーターが追加されました Added a parameter to the CFolderPickerDialog constructor. (これは既定のパラメーターなので、ソースの重大な変更ではありません)。(It is a default parameter, and so it's not source-breaking.)

  • CFileStatus 構造体のサイズは変更されました。m_attribute のメンバーは、(GetFileAttributes から返される値に合わせて) BYTE から DWORD に変更されました。CFileStatus structure size changed: The m_attribute member changed from BYTE to DWORD (to match the value that's returned from GetFileAttributes).

  • Unicode ビルドの場合、CRichEditCtrlCRichEditView は、RICHEDIT_CLASS (RichEdit 3.0 コントロール) ではなく MSFTEDIT_CLASS (RichEdit 4.1 コントロール) を使用します。CRichEditCtrl and CRichEditView use MSFTEDIT_CLASS (RichEdit 4.1 control) instead of RICHEDIT_CLASS (RichEdit 3.0 control) in Unicode builds.

  • Windows Vista、Windows 7、Windows 8 では、AFX_GLOBAL_DATA::IsWindowsThemingDrawParentBackground は常に TRUE なので、削除されました。Removed AFX_GLOBAL_DATA::IsWindowsThemingDrawParentBackground because it's always TRUE on Windows Vista, Windows 7, and Windows 8.

  • Windows Vista、Windows 7、Windows 8 では、AFX_GLOBAL_DATA::IsWindowsLayerSupportAvailable は常に TRUE なので、削除されました。Removed AFX_GLOBAL_DATA::IsWindowsLayerSupportAvailable because it's always TRUE on Windows Vista, Windows 7, and Windows 8.

  • AFX_GLOBAL_DATA::DwmExtendFrameIntoClientArea は削除されました。Removed AFX_GLOBAL_DATA::DwmExtendFrameIntoClientArea. Windows Vista、Windows 7、Windows 8 では、Windows API を直接呼び出してください。Call Windows API directly on Windows Vista, Windows 7, and Windows 8.

  • AFX_GLOBAL_DATA::DwmDefWindowProc は削除されました。Removed AFX_GLOBAL_DATA::DwmDefWindowProc. Windows Vista、Windows 7、Windows 8 では、Windows API を直接呼び出してください。Call Windows API directly on Windows Vista, Windows 7, and Windows 8.

  • 名前の競合を排除するために、AFX_GLOBAL_DATA::DwmIsCompositionEnabled の名前は IsDwmCompositionEnabled に変更されました。Renamed AFX_GLOBAL_DATA::DwmIsCompositionEnabled to IsDwmCompositionEnabled to eliminate name collision.

  • 複数の MFC の内部タイマーの識別子を変更し、定義を afxres.h (AFX_TIMER_ID_*) に移動しました。Changed identifiers for a number of MFC internal timers and moved the definitions to afxres.h (AFX_TIMER_ID_*).

  • ON_WM_EXITSIZEMOVE マクロに合わせて OnExitSizeMove メソッドのシグネチャは変更されました。Changed the signature of OnExitSizeMove method to agree with the ON_WM_EXITSIZEMOVE macro:

    • CFrameWndEx

    • CMDIFrameWndEx

    • CPaneFrameWnd

  • ON_WM_DWMCOMPOSITIONCHANGED マクロに合わせて OnDWMCompositionChanged の名前とシグネチャは変更されました。Changed the name and signature of OnDWMCompositionChanged to agree with the ON_WM_DWMCOMPOSITIONCHANGED macro:

    • CFrameWndEx

    • CMDIFrameWndEx

    • CPaneFrameWnd

  • ON_WM_MOUSELEAVE マクロに合わせて OnMouseLeave メソッドのシグネチャは変更されました。Changed the signature of OnMouseLeave method to agree with the ON_WM_MOUSELEAVE macro:

    • CMFCCaptionBar

    • CMFCColorBar

    • CMFCHeaderCtrl

    • CMFCProperySheetListBox

    • CMFCRibbonBar

    • CMFCRibbonPanelMenuBar

    • CMFCRibbonRichEditCtrl

    • CMFCSpinButtonCtrl

    • CMFCToolBar ReplaceThisTextCMFCToolBar ReplaceThisText

    • CMFCToolBarComboBoxEdit

    • CMFCToolBarEditCtrl

    • CMFCAutoHideBar

  • ON_WM_POWERBROADCAST マクロに合わせて OnPowerBroadcast のシグネチャは変更されました。Changed the signature of OnPowerBroadcast to agree with the ON_WM_POWERBROADCAST macro:

    • CFrameWndEx

    • CMDIFrameWndEx

  • ON_WM_STYLECHANGED マクロに合わせて OnStyleChanged のシグネチャは変更されました。Changed the signature of OnStyleChanged to agree with the ON_WM_STYLECHANGED macro:

    • CMFCListCtrl

    • CMFCStatusBar

  • 内部メソッド FontFamalyProcFonts の名前は FontFamilyProcFonts に変更されました。Renamed the internal method FontFamalyProcFonts to FontFamilyProcFonts.

  • 一部の状況で発生するメモリ リークを排除するために、多数のグローバル静的 CString オブジェクトが削除されました (#defines に置き換えられました)。また、次のクラス メンバー変数が削除されました。Removed numerous global static CString objects to eliminate memory leaks in some situations (replaced with #defines), and the following class member variables:

    • CKeyBoardManager::m_strDelimiter

    • CMFCPropertyGridProperty::m_strFormatChar

    • CMFCPropertyGridProperty::m_strFormatShort

    • CMFCPropertyGridProperty::m_strFormatLong

    • CMFCPropertyGridProperty::m_strFormatUShort

    • CMFCPropertyGridProperty::m_strFormatULong

    • CMFCPropertyGridProperty::m_strFormatFloat

    • CMFCPropertyGridProperty::m_strFormatDouble

    • CMFCToolBarImages::m_strPngResType

    • CMFCPropertyGridProperty::m_strFormat

  • CKeyboardManager::ShowAllAccelerators のシグネチャが変更されました。また、アクセラレータの区切り文字パラメーターが削除されました。Changed the signature of CKeyboardManager::ShowAllAccelerators and removed the accelerator delimiter parameter.

  • CPropertyPage::GetParentSheet が追加されました。CPropertyPage クラスで GetParent の代わりに呼び出して、正しい親シート ウィンドウを取得してください。これは CPropertyPage の親ウィンドウまたは親の親ウィンドウの場合があります。Added CPropertyPage::GetParentSheet, and in the CPropertyPage class, call it instead of GetParent to get the correct parent sheet window, which may be the parent or a grandparent window to CPropertyPage. 必要に応じて、GetParent ではなく GetParentSheet を呼び出すようにコードを変更します。You might have to change your code to call GetParentSheet instead of GetParent.

  • バランスが取れておらず、誤って無効になる警告を引き起こす ATLBASE.H の #pragma warning(push) が修正されました。Fixed unbalanced #pragma warning(push) in ATLBASE.H, which caused warnings to be disabled incorrectly. ATLBASE.H が解析された後、警告は適切に有効になるようになりました。Those warnings are now enabled correctly after ATLBASE.H has been parsed.

  • D2D に関連するメソッドが AFX_GLOBAL_DATA から _AFX_D2D_STATE に移動されました。Moved D2D-related methods from AFX_GLOBAL_DATA to _AFX_D2D_STATE:

    • GetDirectD2dFactory

    • GetWriteFactory

    • GetWICFactory

    • InitD2D

    • ReleaseD2DRefs

    • IsD2DInitialized

    • D2D1MakeRotateMatrix

    • たとえば、afxGlobalData.IsD2DInitialized を呼び出す代わりに AfxGetD2DState->IsD2DInitialized を呼び出します。Instead of calling, for example, afxGlobalData.IsD2DInitialized, call AfxGetD2DState->IsD2DInitialized.

  • 互換性のために残されていた ATL*.CPP ファイルが \atlmfc\include\ フォルダーから削除されました。Removed obsolete ATL*.CPP files from the \atlmfc\include\ folder.

  • DLLMain の要件を満たすために、afxGlobalData の初期化は CRT の初期化時ではなくオンデマンドに移動されました。Moved afxGlobalData initialization to on-demand instead of at CRT initialization time, to satisfy DLLMain requirements.

  • RemoveButtonByIndex メソッドが CMFCOutlookBarPane クラスに追加されました。Added the RemoveButtonByIndex method to the CMFCOutlookBarPane class.

  • CMFCCmdUsageCount::IsFreqeuntlyUsedCmdIsFrequentlyUsedCmd に修正されました。Corrected CMFCCmdUsageCount::IsFreqeuntlyUsedCmd to IsFrequentlyUsedCmd.

  • RestoreOriginalstate のいくつかのインスタンスは RestoreOriginalState (CMFCToolBar, CMFCMenuBar, CMFCOutlookBarPane) に修正されました。Corrected several instances of RestoreOriginalstate to RestoreOriginalState (CMFCToolBar, CMFCMenuBar, CMFCOutlookBarPane).

  • 使用されていないメソッド (SetCaptionStyleIsDrawCaptionIsHideDisabledButtonsGetRecentSiblingPaneInfoCanAdjustLayout) が CDockablePane から削除されました。Removed unused methods from CDockablePane: SetCaptionStyle, IsDrawCaption, IsHideDisabledButtons, GetRecentSiblingPaneInfo, and CanAdjustLayout.

  • CDockablePane の静的メンバー変数 m_bCaptionTextm_bHideDisabledButtons が削除されました。Removed CDockablePane static member variables m_bCaptionText and m_bHideDisabledButtons.

  • オーバーライド DeleteString メソッドが CMFCFontComboBox に追加されました。Added an override DeleteString method to CMFCFontComboBox.

  • 使用されていないメソッド (GetMinLength および IsLastPaneOnLastRow) が CPane から削除されました。Removed unused methods from CPane: GetMinLength and IsLastPaneOnLastRow.

  • CPane::GetDockSiteRow(CDockingPanesRow *) の名前を CPane::SetDockSiteRow に変更しました。Renamed CPane::GetDockSiteRow(CDockingPanesRow *) to CPane::SetDockSiteRow.

Visual Studio 2010 の重要な変更点Visual Studio 2010 Breaking Changes

コンパイラCompiler

  • キーワードには、 auto 新しい既定の意味があります。The auto keyword has a new default meaning. 古い意味はまれにしか使用されないので、ほとんどのアプリケーションはこの変更の影響を受けません。Because use of the old meaning is rare, most applications will not be affected by this change.

  • 新しいキーワードが導入されました static_assert 。コードにその名前の識別子が既に存在する場合、名前の競合が発生します。The new static_assert keyword is introduced, which will cause a name conflict if there is already an identifier by that name in your code.

  • 新しいラムダ表記をサポートすると、IDL uuid 属性の引用符なしの GUID のコーディングはサポートされなくなります。Support for the new lambda notation excludes support for coding an unquoted GUID in an IDL uuid attribute.

  • .NET Framework 4 では、破損状態例外という概念を導入しました。これは、プロセスが回復不能な破損状態のままになる例外です。The .NET Framework 4 introduces the concept of corrupted state exceptions, which are exceptions that leave a process in an unrecoverable corrupted state. 既定では、他のすべての例外をキャッチする /EHa コンパイラ オプションを使用しても、破損状態例外をキャッチできません。By default, you can't catch a corrupted state exception, even with the /EHa compiler option that catches all other exceptions. 破損状態例外を明示的にキャッチするには、__try-__except ステートメントを使用します。To explicitly catch a corrupted state exception, use __try-__except statements. または、[HandledProcessCorruptedStateExceptions] 属性を適用して、破損状態例外をキャッチする関数を有効にします。Or, apply the [HandledProcessCorruptedStateExceptions]attribute to enable a function to catch corrupted state exceptions. この変更は、主に、破損状態例外をキャッチする必要があるシステム プログラマに影響があります。This change affects primarily system programmers who might have to catch a corrupted state exception. 8 つの例外として、STATUS_ACCESS_VIOLATION、STATUS_STACK_OVERFLOW、EXCEPTION_ILLEGAL_INSTRUCTION、EXCEPTION_IN_PAGE_ERROR、EXCEPTION_INVALID_DISPOSITION、EXCEPTION_NONCONTINUABLE_EXCEPTION、EXCEPTION_PRIV_INSTRUCTION、STATUS_UNWIND_CONSOLIDATE があります。The eight exceptions are STATUS_ACCESS_VIOLATION, STATUS_STACK_OVERFLOW, EXCEPTION_ILLEGAL_INSTRUCTION, EXCEPTION_IN_PAGE_ERROR, EXCEPTION_INVALID_DISPOSITION, EXCEPTION_NONCONTINUABLE_EXCEPTION, EXCEPTION_PRIV_INSTRUCTION, STATUS_UNWIND_CONSOLIDATE. これらの例外の詳細については、GetExceptionCode マクロを参照してください。For more information about these exceptions, see the GetExceptionCode macro.

  • /GS コンパイラ オプションは改善され、以前のバージョンよりも包括的にバッファー オーバーランを防ぐことができるようになりました。The revised /GS compiler option guards against buffer overruns more comprehensively than in earlier versions. このバージョンでは、スタックに追加のセキュリティ チェックが挿入され、パフォーマンスが低下する可能性があります。This version might insert additional security checks in the stack that might decrease performance. 特定の関数についてセキュリティ チェックを挿入しないようにコンパイラに指示するには、新しい __declspec(safebuffers) キーワードを使用します。Use the new __declspec(safebuffers) keyword to instruct the compiler to not insert security checks for a particular function.

  • /GL (プログラム全体の最適化) と /clr (共通言語ランタイムのコンパイル) という 2 つのコンパイラ オプションを指定してコンパイルすると、/GL オプションは無視されます。If you compile with both the /GL (Whole Program Optimization) and /clr (Common Language Runtime Compilation) compiler options, the /GL option is ignored. この組み合わせのコンパイラ オプションではほとんどメリットがないため、この変更が加えられました。This change was made because the combination of compiler options provided little benefit. この変更の結果、ビルドのパフォーマンスは改善されました。As a result of this change, the performance of the build is improved.

  • 既定では、Visual Studio 2010 でのトライグラフのサポートは無効です。By default, support for trigraphs is disabled in Visual Studio 2010. トライグラフのサポートを有効にするには、/Zc:trigraphs コンパイラ オプションを使用します。Use the /Zc:trigraphs compiler option to enable trigraphs support. トライグラフは、2 つの連続する疑問符 ("??") と、一意の 3 番目の文字で構成されます。A trigraph consists of two consecutive question marks ("??") followed by a unique third character. コンパイラはトライグラフを対応する区切り文字に置き換えます。The compiler replaces a trigraph with a corresponding punctuation character. たとえば、??= というトライグラフは '#' という文字に置き換えられます。For example, the compiler replaces the ??= trigraph with the '#' character. トライグラフは、一部の区切り文字に対応する適切なグラフィック表示がない文字セットを含む C ソース ファイルで使用できます。Use trigraphs in C source files that use a character set that doesn't contain convenient graphic representations for some punctuation characters.

  • リンカーは Windows 98 の最適化をサポートしなくなりました。The linker no longer supports optimizing for Windows 98. /OPT (最適化) オプションで /OPT:WIN98 または /OPT:NOWIN98 を指定すると、コンパイル時エラーが発生します。The /OPT (Optimizations) option produces a compile time error if you specify /OPT:WIN98 or /OPT:NOWIN98.

  • RuntimeLibrary および DebugInformationFormat ビルド システム プロパティで指定されている既定のコンパイラ オプションは変更されました。The default compiler options that are specified by the RuntimeLibrary and DebugInformationFormat build system properties have been changed. これらのプロパティは、既定で、Visual C++ リリース 7.0 ~ 10.0 で作成されたプロジェクトで指定されます。By default, these build properties are specified in projects that are created by Visual C++ releases 7.0 through 10.0. Visual C++ 6.0 で作成したプロジェクトを移行する場合は、これらのプロパティの値を指定するかどうかを検討してください。If you migrate a project that was created by Visual C++ 6.0, consider whether to specify a value for these properties.

  • Visual Studio 2010 では、RuntimeLibrary = MultiThreaded (/MD)、DebugInformationFormat = ProgramDatabase (/Zi) です。In Visual Studio 2010, RuntimeLibrary = MultiThreaded (/MD) and DebugInformationFormat = ProgramDatabase (/Zi). Visual C++ 9.0 では、RuntimeLibrary = MultiThreaded (/MT)、DebugInformationFormat = Disabled です。In Visual C++ 9.0, RuntimeLibrary = MultiThreaded (/MT) and DebugInformationFormat = Disabled.

CLRCLR

  • Microsoft C# と Visual Basic のコンパイラから、非プライマリ相互運用機能アセンブリ (非 PIA) を生成できるようになりました。The Microsoft C# and Visual Basic compilers can now produce a no primary interop assembly (no-PIA). 非 PIA アセンブリは、関連するプライマリ相互運用機能アセンブリ (PIA) を展開しなくても COM 型を使用できます。A no-PIA assembly can use COM types without the deployment of the relevant primary interop assembly (PIA). Visual C# または Visual Basic で生成された非 PIA アセンブリを使用する場合は、コンパイル コマンドで PIA アセンブリを参照してから、ライブラリを使用する非 PIA アセンブリを参照する必要があります。When consuming no-PIA assemblies produced by Visual C# or Visual Basic, you must reference the PIA assembly on the compile command before you reference any no-PIA assembly that uses the library.

Visual Studio C++ プロジェクトと MSBuildVisual Studio C++ projects and MSBuild

  • Visual Studio C++ プロジェクトは MSBuild ツールに基づくようになりました。Visual Studio C++ projects are now based on the MSBuild tool. その結果、プロジェクト ファイルでは、新しい XML ファイル形式と .vcxproj ファイルのサフィックスを使用します。Consequently, project files use a new XML file format and a .vcxproj file suffix. Visual Studio 2010 は、プロジェクト ファイルを以前のバージョンの Visual Studio から新しいファイル形式に自動的に変換します。Visual Studio 2010 automatically converts project files from earlier versions of Visual Studio to the new file format. 以前のビルド ツールの VCBUILD.exe、またはプロジェクト ファイルのサフィックス .vcproj に依存している場合、既存のプロジェクトは影響を受けます。An existing project is affected if it depends on the previous build tool, VCBUILD.exe, or project file suffix, .vcproj.

  • 以前のリリースの Visual C++ では、プロパティ シートの遅延評価をサポートしていました。In earlier releases, Visual C++ supported the late evaluation of property sheets. たとえば、親プロパティ シートが子プロパティ シートをインポートし、子に定義されている変数を親が使用して他の変数を定義することができます。For example, a parent property sheet could import a child property sheet, and the parent could use a variable defined in the child to define other variables. 遅延評価によって、子プロパティ シートがインポートされる前であっても、親が子の変数を使用できるようになります。Late evaluation enabled the parent to use the child variable even before the child property sheet was imported. MSBuild では早期評価のみがサポートされるため、Visual Studio 2010 では、プロジェクト シート変数は定義前に使用できません。In Visual Studio 2010, a project sheet variable can't be used before it's defined because MSBuild supports only early evaluation.

IDEIDE

  • アプリケーションの終了ダイアログ ボックスで、アプリケーションは終了しなくなります。The application termination dialog box no longer ends an application. 以前のリリースでは、abort() または terminate() 関数でアプリケーションの製品版ビルドを閉じると、C ランタイム ライブラリのコンソール ウィンドウまたはダイアログ ボックスにアプリケーションの終了メッセージが表示されていました。In previous releases, when the abort() or terminate() function closed the retail build of an application, the C Run-Time Library displayed an application termination message in a console window or dialog box. メッセージの一部を引用すると、"このアプリケーションは、通常と異なる方法でランタイムにアプリケーションを中止するように要求しました。The message said in part, "This application has requested the Runtime to terminate it in an unusual way. 詳細については、アプリケーションのサポート チームに問い合わせてください" と表示されていました。Please contact the application's support team for more information." Windows によって現在の終了ハンドラー (通常は Windows エラー報告 (ワトソン博士) ダイアログボックスまたは Visual Studio デバッガー) が表示されたため、アプリケーション終了メッセージは冗長でした。The application termination message was redundant because Windows subsequently displayed the current termination handler, which was usually the Windows Error Reporting (Dr. Watson) dialog box or the Visual Studio debugger. Visual Studio 2010 以降、C ランタイム ライブラリではこのメッセージが表示されなくなりました。Starting in Visual Studio 2010, the C Run-Time Library doesn't display the message. また、ランタイムでは、デバッガーの起動前にアプリケーションが終了しなくなりました。Furthermore, the runtime prevents the application from ending before a debugger starts. アプリケーションの終了メッセージの以前の動作に依存している場合にのみ、これは互換性に影響する変更です。This is a breaking change only if you depend on the previous behavior of the application termination message.

  • 特に Visual Studio 2010 では、IntelliSense は C++/CLI コードまたは属性に使用できません。[すべての参照の検索] はローカル変数には使用できません。また、コード モデルでは、インポートしたアセンブリから型名を取得したり、型を完全修飾名に解決したりすることはできません。Specifically for Visual Studio 2010, IntelliSense doesn't work for C++/CLI code or attributes, Find All References doesn't work for local variables, and Code Model doesn't retrieve type names from imported assemblies or resolve types to their fully qualified names.

ライブラリLibraries

  • SafeInt クラスは Visual C++ に含まれていません。また、別のダウンロードにも含まれなくなりました。The SafeInt class is included in Visual C++ and is no longer in a separate download. "SafeInt" という名前のクラスを開発した場合にのみ、これは破壊的変更です。This is a breaking change only if you've developed a class that's also named "SafeInt".

  • ライブラリ展開モデルは、特定バージョンのダイナミック リンク ライブラリを検索するためにマニフェストを使用しなくなりました。The libraries deployment model no longer uses manifests to find a particular version of a dynamic link library. 各ダイナミック リンク ライブラリの名前にはバージョン番号が含まれているので、その名前を使用してライブラリを特定してください。Instead, the name of each dynamic link library contains its version number, and you use that name to locate the library.

  • 以前のバージョンの Visual Studio では、ランタイム ライブラリを再ビルドできます。In previous versions of Visual Studio, you could rebuild the run time libraries. Visual Studio 2010 では、C ランタイム ライブラリ ファイルの独自のコピーのビルドがサポートされなくなりました。Visual Studio 2010 no longer supports building your own copies of the C run time library files.

標準ライブラリStandard Library

  • <iterator>ヘッダーは、他の多くのヘッダーファイルによって自動的には含まれなくなりました。The <iterator> header is no longer included automatically by many other header files. 代わりに、ヘッダーで定義されているスタンドアロンの反復子のサポートが必要な場合は、そのヘッダーを明示的に含めます。Instead, include that header explicitly if you require support for the standalone iterators defined in the header. 以前のビルド ツールの VCBUILD.exe、またはプロジェクト ファイルのサフィックス .vcproj.iterator に依存している場合、既存のプロジェクトは影響を受けます。An existing project is affected if it depends on the previous build tool, VCBUILD.exe, or project file suffix, .vcproj.iterator.

  • ヘッダーでは、 <algorithm> checked_ * および unchecked_ * 関数は削除されます。In the <algorithm> header, the checked_* and unchecked_* functions are removed. また、> ヘッダーでクラスが削除され、 <iterator> checked_iterator クラスが unchecked_array_iterator 追加されています。And in the <iterator>> header, the checked_iterator class is removed, and the unchecked_array_iterator class has been added.

  • CComPtr::CComPtr(int) コンストラクターは削除されました。The CComPtr::CComPtr(int) constructor is removed. このコンストラクターを使用すると、NULL マクロから CComPtr オブジェクトを構築できますが、必須ではなく、ゼロ以外の整数から無意味な構造を構築できます。That constructor allowed a CComPtr object to be constructed from the NULL macro, but was unnecessary and allowed nonsensical constructions from non-zero integers.

    CComPtr は NULL から構築できます。これは 0 と定義されますが、リテラル 0 以外の整数から構築されると失敗します。A CComPtr can still be constructed from NULL, which is defined as 0, but will fail if constructed from an integer other than literal 0. 代わりにを使用 nullptr してください。Use nullptr instead.

  • 次の ctype メンバー関数 (ctype::_Do_narrow_sctype::_Do_widen_sctype::_narrow_sctype::_widen_s) は削除されました。The following ctype member functions were removed: ctype::_Do_narrow_s, ctype::_Do_widen_s, ctype::_narrow_s, ctype::_widen_s. これらのメンバー関数のいずれかをアプリケーションで使用する場合は、対応するセキュリティで保護されていないバージョン (ctype::do_narrowctype::do_widenctype::narrowctype::widen) に置き換えます。If an application uses one of these member functions, you must replace it with the corresponding non-secure version: ctype::do_narrow, ctype::do_widen, ctype::narrow, ctype::widen.

CRT、MFC、ATL ライブラリCRT, MFC, and ATL Libraries

  • CRT、MFC、および ATL ライブラリをビルドするために、ユーザー サポートは削除されました。Support has been removed for users to build the CRT, MFC, and ATL libraries. たとえば、適切な NMAKE ファイルが指定されていないとします。For example, no appropriate NMAKE file is provided. 一方、ユーザーは、これらのライブラリのソース コードに対してアクセス権を持っています。However, users still have access to the source code for these libraries. また、Microsoft がこれらのライブラリのビルドに使用する MSBuild オプションについて説明したドキュメントが、Visual C++ チーム ブログに投稿される可能性があります。And a document that describes the MSBuild options that Microsoft uses to build these libraries will probably be posted in a Visual C++ Team Blog.

  • IA64 の MFC のサポートは削除されました。MFC support for IA64 has been removed. ただし、IA64 の CRT と ATL のサポートはまだ提供されています。However, support for the CRT and ATL on IA64 is still provided.

  • MFC モジュール定義 (.def) ファイルでは序数が再利用されなくなりました。Ordinals are no longer reused in MFC module-definition (.def) files. この変更は、マイナー バージョン間で序数の違いがないことを示します。また、サービス パックとクイック修正エンジニアリング リリースのバイナリの互換性は改善される予定です。This change means ordinals will not be different between minor versions, and binary compatibility for service packs and quick fix engineering releases will be improved.

  • 新しい仮想関数が CDocTemplate クラスに追加されました。A new virtual function was added to the CDocTemplate class. この新しい仮想関数は CDocTemplate Class です。This new virtual function is CDocTemplate Class. 以前のバージョンの OpenDocumentFile には 2 つのパラメーターがありました。The previous version of OpenDocumentFile had two parameters. 新しいバージョンのパラメーターは 3 つです。The new version has three parameters. 再起動マネージャーをサポートするには、CDocTemplate から派生したクラスで、3 つのパラメーターがあるバージョンを実装する必要があります。To support the restart manager, any class derived from CDocTemplate must implement the version that has three parameters. 新しいパラメーターは bAddToMRU です。The new parameter is bAddToMRU.

マクロと環境変数Macros and Environment Variables

  • 環境変数 __MSVCRT_HEAP_SELECT はサポートされなくなりました。The environment variable __MSVCRT_HEAP_SELECT is no longer supported. この環境変数は削除されました。これに代わる機能はありません。This environment variable is removed and there is no replacement.

Microsoft Macro Assembler リファレンスMicrosoft Macro Assembler Reference

  • Microsoft Macro Assembler リファレンス コンパイラからいくつかのディレクティブが削除されました。Several directives were removed from the Microsoft Macro Assembler Reference compiler. 削除されたディレクティブは、.186.286.286P.287.8086.8087、および .NO87 です。The removed directives are .186, .286, .286P, .287, .8086, .8087, and .NO87.

Visual Studio 2008 の重要な変更点Visual Studio 2008 Breaking Changes

コンパイラCompiler

  • Windows 95、Windows 98、Windows ME、および Windows NT プラットフォームはサポートされなくなりました。The Windows 95, Windows 98, Windows ME, and Windows NT platforms are no longer supported. これらのオペレーティング システムは対象のプラットフォーム一覧から削除されました。These operating systems have been removed from the list of targeted platforms.

  • コンパイラは、ATL サーバーと直接関連する複数の属性をサポートしなくなりました。The compiler no longer supports multiple attributes that were directly associated with ATL Server. 次の属性はサポートされなくなりました。The following attributes are no longer supported:

    • perf_counterperf_counter

    • perf_objectperf_object

    • perfmonperfmon

    • request_handlerrequest_handler

    • soap_handlersoap_handler

    • soap_headersoap_header

    • soap_methodsoap_method

    • tag_nametag_name

Visual Studio C++ のプロジェクトVisual Studio C++ projects

  • 以前のバージョンの Visual Studio からプロジェクトをアップグレードする場合、必要に応じて 0x0500 以上になるように WINVER マクロと _WIN32_WINNT マクロを変更します。When upgrading projects from previous versions of Visual Studio, you might have to modify the WINVER and _WIN32_WINNT macros so that they are greater than or equal to 0x0500.

  • Visual Studio 2008 以降、新しいプロジェクト ウィザードでは C++ SQL Server プロジェクトを作成するオプションがなくなりました。Beginning with Visual Studio 2008, the new project wizard doesn't have an option to create a C++ SQL Server project. 以前のバージョンの Visual Studio を使用して作成した SQL Server プロジェクトは、今後も適切にコンパイルされ、動作します。SQL Server projects created by using an earlier version of Visual Studio will still compile and work correctly.

  • Windows API ヘッダー ファイル Winable.h は削除されました。The Windows API header file Winable.h has been removed. 代わりに Winuser.h をインクルードしてください。Include Winuser.h instead.

  • Windows API ライブラリ Rpcndr.lib は削除されました。The Windows API library Rpcndr.lib has been removed. 代わりに rpcrt4.lib とリンクしてください。Link with rpcrt4.lib instead.

CRTCRT

  • Windows 95、Windows 98、Windows Millennium Edition、および Windows NT 4.0 のサポートは削除されました。Support for Windows 95, Windows 98, Windows Millennium Edition, and Windows NT 4.0 has been removed.

  • 次のグローバル変数は削除されました。The following global variables have been removed:

    • _osplatform_osplatform

    • _osver_osver

    • _winmajor_winmajor

    • _winminor_winminor

    • _winver_winver

  • 次の関数は削除されました。The following functions have been removed. 代わりに Windows API 関数 GetVersion または GetVersionEx を使用してください。Use the Windows API functions GetVersion or GetVersionEx instead:

    • _get_osplatform_get_osplatform

    • _get_osver_get_osver

    • _get_winmajor_get_winmajor

    • _get_winminor_get_winminor

    • _get_winver_get_winver

  • SAL 注釈の構文は変更されました。The syntax for SAL Annotations has changed. 詳細については、「SAL 注釈」を参照してください。For more information, see SAL Annotations.

  • IEEE フィルターは SSE 4.1 命令セットをサポートするようになりました。The IEEE filter now supports the SSE 4.1 instruction set. 詳細については、「_fpieee_flt_fpieee_flt」を参照してください。For more information, see _fpieee_flt_fpieee_flt.

  • Visual Studio に付属する C ランタイム ライブラリは、システム DLL msvcrt.dll に依存しなくなりました。The C Run-Time Libraries that ship with Visual Studio are no longer dependent on the system DLL msvcrt.dll.

標準ライブラリStandard Library

  • Windows 95、Windows 98、Windows Millennium Edition、および Windows NT 4.0 のサポートは削除されました。Support for Windows 95, Windows 98, Windows Millennium Edition, and Windows NT 4.0 has been removed.

  • _HAS_ITERATOR_DEBUGGING を定義してデバッグ モードでコンパイルすると (Visual Studio 2010 以降は _ITERATOR_DEBUG_LEVEL に置き換えられます)、反復子が基礎となるコンテナーの境界を越えて増加または減少しようとしたときに、アプリケーションはアサートするようになりました。When compiling in debug mode with _HAS_ITERATOR_DEBUGGING defined (superseded by _ITERATOR_DEBUG_LEVEL after Visual Studio 2010), an application will now assert when an iterator attempts to increment or decrement past the bounds of the underlying container.

  • スタック クラスのメンバー変数 c は保護済みと宣言されるようになりました。The member variable c of the stack Class is now declared protected. 以前は、このメンバー変数はパブリックと宣言されていました。Previously, this member variable was declared public.

  • money_get::do_get の動作が変更されました。The behavior of money_get::do_get has changed. 以前は、frac_digits で呼び出されたよりも多くの小数点以下桁数で金額を解析すると、do_get はすべてを使用していました。Previously, when parsing a monetary amount with more fraction digits than are called for by frac_digits, do_get used to consume them all. 現在は、最高でも frac_digits 文字まで使用すると、do_get は解析を停止します。Now, do_get stops parsing after consuming at most frac_digits characters.

ATLATL

  • CRT に依存することなく ATL をビルドすることはできません。ATL can't be built without a dependency on CRT. 以前のバージョンの Visual Studio では、#define ATL_MIN_CRT を使用して、ATL プロジェクトの CRT への依存を最小限にすることができます。In earlier versions of Visual Studio, you could use #define ATL_MIN_CRT to make an ATL project minimally dependent on CRT. Visual Studio 2008 では、ATL_MIN_CRT が定義されているかどうかにかかわらず、すべての ATL プロジェクトの CRT への依存は最小限です。In Visual Studio 2008, all ATL projects are minimally dependent on CRT regardless of whether ATL_MIN_CRT is defined.

  • ATL サーバーのコードベースは、CodePlex の共有ソース プロジェクトとしてリリースされており、Visual Studio の一部としてはインストールされません。The ATL Server codebase has been released as a shared source project on CodePlex and isn't installed as part of Visual Studio. atlenc.h のクラスのデータ エンコードとデコード、および atlutil.h と atlpath のユーティリティ関数とクラスは残され、ATL ライブラリの一部になりました。Data encoding and decoding classes from atlenc.h and utility functions and classes from atlutil.h and atlpath.h have been kept and are now part of the ATL library. ATL サーバーに関連する一部のファイルは、Visual Studio に含まれなくなりました。Several files associated with ATL Server are no longer part of Visual Studio.

  • 一部の関数は DLL に含まれなくなりました。Some functions are no longer included in the DLL. これらの関数はインポート ライブラリに含まれています。They are still located in the import library. これは、関数を静的に使用するコードには影響がありません。This will not affect code that uses the functions statically. これらの関数を動的に使用するコードにのみ影響があります。It will affect only the code that uses these functions dynamically.

  • マクロ PROP_ENTRY と PROP_ENTRY_EX は非推奨になり、セキュリティ上の理由からマクロ PROP_ENTRY_TYPE と PROP_ENTRY_TYPE_EX に置き換えられました。The macros PROP_ENTRY and PROP_ENTRY_EX have been deprecated and replaced with the macros PROP_ENTRY_TYPE and PROP_ENTRY_TYPE_EX for security reasons.

ATL/MFC 共有クラスATL/MFC Shared Classes

  • CRT に依存することなく ATL をビルドすることはできません。ATL can't be built without a dependency on CRT. 以前のバージョンの Visual Studio では、#define ATL_MIN_CRT を使用して、ATL プロジェクトの CRT への依存を最小限にすることができます。In earlier versions of Visual Studio, you could use #define ATL_MIN_CRT to make an ATL project minimally dependent on CRT. Visual Studio 2008 では、ATL_MIN_CRT が定義されているかどうかにかかわらず、すべての ATL プロジェクトの CRT への依存は最小限です。In Visual Studio 2008, all ATL projects are minimally dependent on CRT regardless of whether ATL_MIN_CRT is defined.

  • ATL サーバーのコードベースは、CodePlex の共有ソース プロジェクトとしてリリースされており、Visual Studio の一部としてはインストールされません。The ATL Server codebase has been released as a shared source project on CodePlex and isn't installed as part of Visual Studio. atlenc.h のクラスのデータ エンコードとデコード、および atlutil.h と atlpath のユーティリティ関数とクラスは残され、ATL ライブラリの一部になりました。Data encoding and decoding classes from atlenc.h and utility functions and classes from atlutil.h and atlpath.h have been kept and are now part of the ATL library. ATL サーバーに関連する一部のファイルは、Visual Studio に含まれなくなりました。Several files associated with ATL Server are no longer part of Visual Studio.

  • 一部の関数は DLL に含まれなくなりました。Some functions are no longer included in the DLL. これらの関数はインポート ライブラリに含まれています。They are still located in the import library. これは、関数を静的に使用するコードには影響がありません。This will not affect code that uses the functions statically. これらの関数を動的に使用するコードにのみ影響があります。It will affect only the code that uses these functions dynamically.

MFCMFC

  • CTime クラス: CTime クラスは西暦 1900 年 1 月 1 日以降の日付を使用できるようになりました CTime Class: The CTime class now accepts dates starting from 1/1/1900 C.E. (以前は西暦 1970 年 1 月 1 日以降でした)。instead of 1/1/1970 C.E.

  • MFC ダイアログのコントロールのタブ オーダー: タブ オーダーに MFC ActiveX コントロールが挿入されている場合、MFC ダイアログに含まれる複数のコントロールは正しいタブ オーダーになりません。Tab order of controls in MFC dialogs: The correct tab order of multiple controls in an MFC dialog is disturbed if an MFC ActiveX control is inserted in the tab order. 今回の変更で、この問題は解決します。This change corrects that problem.

    たとえば、ActiveX コントロールといくつかの編集コントロールがある MFC ダイアログ アプリケーションを作成します。For example, create an MFC dialog application that has an ActiveX control and several edit controls. ActiveX コントロールを編集コントロールのタブ オーダーの中間に配置します。Position the ActiveX control in the middle of the tab order of the edit controls. アプリケーションを起動して、タブオーダーが ActiveX コントロールの後にある編集コントロールをクリックし、次に tab キーを押します。この変更を行う前に、タブオーダーの次の編集コントロールではなく、ActiveX コントロールの次の編集コントロールにフォーカスを移動します。Start the application, click an edit control whose tab order is after the ActiveX control, then tab. Prior to this change, the focus went to the edit control following the ActiveX control instead of the next edit control in the tab order.

  • CFileDialogクラス: クラスのカスタムテンプレート CFileDialog を Windows Vista に自動的に移植することはできません。CFileDialog Class: Custom templates for the CFileDialog class can't be automatically ported to Windows Vista. 使用することはできますが、Windows Vista スタイルのダイアログの機能や外観を追加することはできません。They are still usable, but will not have the additional functionality or looks of Windows Vista style dialogs.

  • CWnd クラスと CFrameWnd クラス: CWnd::GetMenuBarInfo メソッドは削除されました。CWnd Class and CFrameWnd Class: The CWnd::GetMenuBarInfo method was removed.

    CFrameWnd::GetMenuBarInfo メソッドは仮想メソッドではなくなりました。The CFrameWnd::GetMenuBarInfo method is now a non-virtual method. 詳細については、Windows SDK の GetMenuBarInfo 関数を参照してください。For more information, see GetMenuBarInfo Function in the Windows SDK.

  • MFC ISAPI のサポート: MFC は、Internet Server Application Programming Interface (ISAPI) を使用したアプリケーションのビルドをサポートしなくなりました。MFC ISAPI support: MFC no longer supports building applications with the Internet Server Application Programming Interface (ISAPI). ISAPI アプリケーションをビルドするには、ISAPI 拡張機能を直接呼び出してください。If you want to build an ISAPI application, call the ISAPI extensions directly.

  • 非推奨になった ANSI API: ANSI バージョンの一部の MFC メソッドは非推奨になりました。Deprecated ANSI APIs: The ANSI versions of several MFC methods are deprecated. 今後のアプリケーションでは、これらのメソッドの Unicode バージョンを使用してください。Use the Unicode versions of those methods in your future applications. 詳細については、「Windows Vista コモン コントロールの作成要件」を参照してください。For more information, see Build Requirements for Windows Vista Common Controls.

Visual Studio 2005 の重要な変更点Visual Studio 2005 Breaking Changes

CRTCRT

  • 多くの関数は非推奨になりました。Many functions have been deprecated. Deprecated CRT Functions」(非推奨の CRT 関数) を参照してください。See Deprecated CRT Functions.

  • 多くの関数はパラメーターを検証し、パラメーターが無効な場合は実行を停止するようになりました。Many functions now validate their parameters, halting execution if given invalid parameters. 無効なパラメーターを渡しているコードで、無効なパラメーターを無視するか単にエラー コードを返すだけの関数に依存しているコードの場合、この検証によってコードに障害を起こす可能性があります。This validation may break code that passes invalid parameters and relies on the function ignoring them or just returning an error code. Parameter Validation」(パラメーターの検証) を参照してください。See Parameter Validation.

  • ファイル記述子の値 -2 は、出力に stdoutstderr を使用できないことを示すために使用されるようになりました。たとえば、コンソール ウィンドウがない Windows アプリケーションで使用されます。The file descriptor value -2 is now used to indicate that stdout and stderr aren't available for output, for example, in a Windows application that has no console window. 以前に使用されていた値は -1 でした。The previous value used was -1. 詳細については、「_fileno」を参照してくださいFor more information, see _fileno.

  • シングルスレッドの CRT ライブラリ libc.lib と libcd.lib は削除されました。The single-threaded CRT libraries (libc.lib and libcd.lib) have been removed. マルチスレッドの CRT ライブラリを使用してください。Use the multi-threaded CRT libraries. /ML コンパイラ フラグはサポートされなくなりました。The /ML compiler flag is no longer supported. マルチスレッドのコードとシングルスレッドのコード間のパフォーマンスの違いが重要な問題になる場合に、一部の関数のロックなしバージョンが追加されました。Non-locking versions of some functions have been added in cases where the performance difference between the multithreaded code and the single-threaded code is potentially significant.

  • pow のオーバーロードである double pow(int, int) は、標準への準拠を改善するために削除されました。The overload of pow, double pow(int, int), was removed to better conform with the standard.

  • %n 書式指定子は、安全性に欠ける性質があるので、どの printf ファミリの関数でも既定でサポートされなくなりました。The %n format specifier is no longer supported by default in any of the printf family of functions because it's inherently insecure. %n が指定された場合、既定の動作は無効なパラメーター ハンドラーを呼び出すことです。If %n is encountered, the default behavior is to invoke the invalid parameter handler. %n のサポートを有効にするには、_set_printf_count_output を使用します (_get_printf_count_output も参照してください)。To enable %n support, use _set_printf_count_output (also see _get_printf_count_output).

  • sprintf は、符号付きゼロの負の符号を出力するようになりました。sprintf now prints the negative sign of a signed zero.

  • 標準への準拠のために swprintf は変更され、size パラメーターが必須になりました。swprintf has been changed to conform with the Standard; it now requires a size parameter. size パラメーターを指定しない swprintf の形式は非推奨になりました。The form of swprintf without a size parameter has been deprecated.

  • _set_security_error_handler は削除されました。_set_security_error_handler has been removed. その関数の呼び出しは削除してください。既定のハンドラーの方がはるかに安全にセキュリティ エラーを処理できます。Remove any calls to that function; the default handler is a much safer way of dealing with security errors.

  • time_t は 64 ビット値です (_USE_32BIT_TIME_T が定義されていない場合)。time_t is now a 64-bit value (unless _USE_32BIT_TIME_T is defined).

  • _spawn 関数、_wspawn 関数は、C 標準の規定に従い、成功時には errno が変更されません。The _spawn, _wspawn Functions now leave errno untouched on success, as specified by the C Standard.

  • RTC は既定でワイド文字を使用するようになりました。RTC now uses wide characters by default.

  • 浮動小数点制御ワードのサポート関数は、/CLR または /CLR:PURE を指定してコンパイルしたアプリケーションの場合に非推奨になりました。Floating-point control word support functions have been deprecated for applications compiled with /CLR or /CLR:PURE. 影響を受ける関数は _clear87_clearfp_control87_controlfp_fpreset_status87_statusfp です。The affected functions are _clear87, _clearfp, _control87, _controlfp, _fpreset, _status87, _statusfp. _CRT_MANAGED_FP_NO_DEPRECATE を定義して、非推奨の警告を無効にすることができます。ただし、マネージド コードでこれらの関数を使用することは予測不能でサポートされません。You can disable the deprecation warning by defining _CRT_MANAGED_FP_NO_DEPRECATE, but the use of these functions in managed code is unpredictable and unsupported.

  • 一部の関数は定数ポインターを返すようになりました。Some functions now return const pointers. 古い定数ではない動作は、_CONST_RETURN を定義して復元することができます。The old, non-const behavior can be reinstated by defining _CONST_RETURN. 影響を受ける関数は次のとおりです。The affected functions are

    • memchr、wmemchrmemchr, wmemchr

    • strchr、wcschr、_mbschr、_mbschr_lstrchr, wcschr, _mbschr, _mbschr_l

    • strpbrk、wcspbrk、_mbspbrk、_mbspbrk_lstrpbrk, wcspbrk, _mbspbrk, _mbspbrk_l

    • strrchr、wcsrchr、_mbsrchr、_mbsrchr_lstrrchr, wcsrchr, _mbsrchr, _mbsrchr_l

    • strstr、wcsstr、_mbsstr、_mbsstr_lstrstr, wcsstr, _mbsstr, _mbsstr_l

  • Setargv.obj または Wsetargv.obj とリンクするときに、コマンド ラインのワイルドカード文字を二重引用符で囲んでワイルドカード文字の展開を抑制できなくなりました。When linking with Setargv.obj or Wsetargv.obj, it's no longer possible to suppress the expansion of a wildcard character on the command line by enclosing it in double quotes. 詳細については、「ワイルドカード引数の展開」を参照してください。For more information, see Expanding Wildcard Arguments.

標準ライブラリ (2005)Standard Library (2005)

  • 例外クラス (ヘッダーにあり <exception> ます) が名前空間に移動されました stdThe exception class (located in the <exception> header) has been moved to the std namespace. 以前のバージョンでは、このクラスはグローバル名前空間に含まれていました。In previous versions, this class was in the global namespace. 例外クラスが見つからないというエラーを解決するには、次の using ステートメントをコードに追加します。using namespace std;To resolve any errors indicating that the exception class can't be found, add the following using statement to your code: using namespace std;

  • valarray::resize() を呼び出すと、valarray の内容は失われ、既定値で置き換えられます。When calling valarray::resize(), the contents of the valarray will be lost and will be replaced by default values. resize() メソッドは、ベクターのように動的に増加するのではなく、valarray を再初期化するためのものです。The resize() method is intended to reinitialize the valarray rather than grow it dynamically like a vector.

  • デバッグ反復子: デバッグ バージョンの C ランタイム ライブラリを使用してビルドし、反復子を正しく使用していないアプリケーションは、実行時にアサートが表示されるようになることがあります。Debug Iterators: Applications built with a debug version of the C-Runtime Library and which use iterators incorrectly might begin to see asserts at runtime. これらのアサートを無効にするには、_HAS_ITERATOR_DEBUGGING (Visual Studio 2010 以降は _ITERATOR_DEBUG_LEVEL に置き換えられます) を 0 に定義する必要があります。To disable these asserts, you must define _HAS_ITERATOR_DEBUGGING (superseded by _ITERATOR_DEBUG_LEVEL after Visual Studio 2010) to 0. 詳細については、「Debug Iterator Support」(反復子のデバッグのサポート) を参照してください。For more information, see Debug Iterator Support

Visual C++ .NET 2003 の互換性に影響する変更Visual C++ .NET 2003 Breaking Changes

コンパイラCompiler

  • 定義済みプリプロセッサ ディレクティブ (C2004) には閉じかっこが必須になりました。Closing parentheses now required for the defined preprocessor directive (C2004).

  • 明示的な特殊化では、プライマリ テンプレートからテンプレート パラメーターを検索できなくなりました (コンパイラ エラー C2146)。Explicit specializations no longer find template parameters from primary template (Compiler Error C2146).

  • 保護されたメンバー (n) には、(n) がメンバーであるクラス (A) から継承されたクラス (B) のメンバー関数経由でアクセスする必要があります (コンパイラ エラー C2247)。A protected member (n) can only be accessed through a member function of a class (B) that inherits from the class (A) of which it (n) is a member (Compiler Error C2247).

  • コンパイラのアクセシビリティ チェックが改善され、アクセスできない基底クラスが検出されるようになりました (コンパイラ エラー C2248)。Improved accessibility checks in compiler now detect inaccessible base classes (Compiler Error C2248).

  • デストラクターまたはコピー コンストラクターにアクセスできない場合、例外をキャッチできません (C2316)。An exception can't be caught if the destructor and/or copy constructor is inaccessible (C2316).

  • 関数に対するポインターの既定の引数は使用できなくなりました (コンパイラ エラー C2383)。Default arguments on pointers to functions no longer allowed (Compiler Error C2383).

  • 静的データ メンバーは派生クラスを使って初期化できません (コンパイラ エラー C2477)。A static data member can't be initialized via derived class (Compiler Error C2477).

  • の初期化が typedef 標準で許可されていないため、コンパイラエラー (コンパイラエラー C2513) が生成されるようになりました。The initialization of a typedef isn't allowed by the standard and now generates a compiler error (Compiler Error C2513).

  • bool は、適切な型 (コンパイラエラー C2632) になりました。bool is now a proper type (Compiler Error C2632).

  • オーバーロードされた演算子がある場合、UDC であいまいさが生じるようになりました (C2666)。A UDC can now create ambiguity with overloaded operators (C2666).

  • 多くの式が Null ポインター定数と見なされるようになりました (コンパイラ エラー C2668)。More expressions are now considered valid null pointer constants (Compiler Error C2668).

  • 以前にコンパイラが暗示していた位置に template<> の指定が必須になりました (コンパイラ エラー C2768)。template<> is now required in places where the compiler would previously imply it (Compiler Error C2768).

  • テンプレート クラスの特殊化で関数が既に明示的に特殊化されている場合、クラス外でのメンバー関数の明示的な特殊化は有効ではなくなりました (コンパイラ エラー C2910)。The explicit specialization of a member function outside the class isn't valid if the function has already been explicitly specialized via a template class specialization (Compiler Error C2910).

  • 浮動小数点の非型テンプレート パラメーターは使用できなくなりました (コンパイラ エラー C2993)。Floating point non-type template parameters are no longer allowed (Compiler Error C2993).

  • クラス テンプレートはテンプレート型引数として使用できなくなりました (C3206)。Class templates aren't allowed as template type arguments (C3206).

  • フレンド関数名は、含まれる名前空間に導入されなくなりました (コンパイラ エラー C3767)。Friend function names are no longer introduced into containing namespace (Compiler Error C3767).

  • コンパイラでは、マクロ内の余分なコンマが使用できなくなります (C4002)。The compiler will no longer accept extra commas in a macro (C4002).

  • 形式 () の初期化子で構築される POD 型のオブジェクトは既定初期化されます (C4345)。An object of POD type constructed with an initializer of the form () will be default-initialized (C4345).

  • 依存する名前を型として扱う場合、typename は必須になりました (コンパイラの警告 (レベル 1) C4346)。typename is now required if a dependent name is to be treated as a type (Compiler Warning (level 1) C4346).

  • 誤ってテンプレートの特殊化と見なされていた関数は、そのように見なされなくなりました (C4347)。Functions that were incorrectly considered template specializations are no longer considered so (C4347).

  • 静的データ メンバーは派生クラスを使って初期化できません (C4356)。Static data members can't be initialized via derived class (C4356).

  • 戻り値の型で使用する前に、クラス テンプレートの特殊化を定義する必要がなくなりました (コンパイラの警告 (レベル 3) C4686)。A class template specialization needs to be defined before it is used in a return type (Compiler Warning (level 3) C4686).

  • コンパイラは到達不能なコードをレポートするようになりました (C4702)。The compiler now reports unreachable code (C4702).

関連項目See also

Visual Studio の Visual C++ の新機能What's New for Visual C++ in Visual Studio