Microsoft Visual C++ (MSVC) is a compiler for the C, C++, C++/CLI and C++/CX programming languages by Microsoft. MSVC is proprietary software; it was originally a standalone product but later became a part of Visual Studio and made available in both trialware and freeware forms. It features tools for developing and debugging C++ code, especially code written for the Windows API, DirectX and .NET. Many applications require redistributable Visual C++ runtime library packages to function correctly. These packages are frequently installed separately from the applications they support, enabling multiple applications to use the package with only a single installation. These Visual C++ redistributable and runtime packages are mostly installed for standard libraries that many applications use.

History

The predecessor to Visual C++ was called Microsoft C/C++. There was also a Microsoft QuickC 2.5 and a Microsoft QuickC for Windows 1.0. The Visual C++ compiler is still known as Microsoft C/C++ and as of the release of Visual C++ 2015 Update 2, is on version 14.0.23918.0.

16-bit versions

Strictly 32-bit versions

32-bit and 64-bit versions

Internal version numbering

There are several different version numbers to consider when working with Visual C or C++. The oldest and most original of these is the compiler version number, which has been monotonically increased since the early Microsoft C compiler days. This is the version returned by running the command on its own without any options. By taking two digits after the decimal and dropping the decimal point, this also becomes the value of the C pre-processor macro:, and the CMake variable:. A longer version of the C macro is to make more finely-grained distinctions between builds of the compiler. An example of is 1933 to represent version 19.33 of the Microsoft C/C++ compiler, and of is 193331630. The Visual product version, such as "17.3.4", designates the version of Visual Studio with which version 19.33 of the compiler was packaged. Then there is the Microsoft Visual C/C++ Runtime Library version, e.g. "14.3". From this, one can also deduce the toolset version, which can be obtained by taking the first three digits of the runtime library version and dropping the decimal, e.g. "143". It includes the Visual C/C++ runtime library, as well as compilers, linkers, assemblers, other build tools, and matching libraries and header files. The following is a (scrapeable) table of the known correlated version numbers.

Compatibility

ABI

The Visual C++ compiler ABI has historically changed between major compiler releases. This is especially the case for STL containers, where container sizes have varied a lot between compiler releases. Microsoft therefore recommends against using C++ interfaces at module boundaries when one wants to enable client code compiled using a different compiler version. Instead of C++, Microsoft recommends using C or COM interfaces, which are designed to have a stable ABI between compiler releases. All 14.x MSVC releases have a stable ABI, and binaries built with these versions can be mixed in a forwards-compatible manner, noting the following restrictions:

C runtime libraries

Visual C++ ships with different versions of C runtime libraries. This means users can compile their code with any of the available libraries. However, this can cause some problems when using different components (DLLs, EXEs) in the same program. A typical example is a program using different libraries. The user should use the same C Run-Time for all the program's components unless the implications are understood. Microsoft recommends using the multithreaded, dynamic link library (/MD or /MDd compiler option) to avoid possible problems.

POSIX

Although Microsoft's CRT implements a large subset of POSIX interfaces, the Visual C++ compiler will emit a warning on every use of such functions by default. The rationale is that C and C++ standards require an underscore prefix before implementation-defined interfaces, so the use of these functions are non-standard. However, systems that are actually POSIX-compliant would not accept these underscored names, and it is more portable to just turn off the warning instead.

C

Although the product originated as an IDE for the C programming language, for many years the compiler's support for that language conformed only to the original edition of the C standard, dating from 1989, but not the C99 revision of the standard. There had been no plans to support C99 even in 2011, more than a decade after its publication. Visual C++ 2013 finally added support for various C99 features in its C mode (including designated initializers, compound literals, and the type), though it was still not complete. Visual C++ 2015 further improved the C99 support, with full support of the C99 Standard Library, except for features that require C99 language features not yet supported by the compiler. Most of the changes from the C11 revision of the standard were still not supported by Visual C++ 2017. For example, generic selections via the keyword are not supported by the compiler and result in a syntax error. The preprocessor was overhauled in 2018, with C11 in sight: "Full C11 conformance is on our roadmap, and updating the preprocessor is just the first step in that process. The C11 feature is not actually part of the preprocessor, so it has not yet been implemented. When implemented I expect the feature to work independently of if the traditional or updated preprocessor logic is used." support has been committed to MSVC as of February 2020. In September 2020, Microsoft announced C11 and C17 standards support in MSVC would arrive in version 16.8. This did not include optional features but Microsoft indicated that they were planning to add support for atomics and threads at a later date. In version 17.5, partial (since atomic locks are missing) and experimental (meaning hidden behind the compiler flag ) support for atomics was added and in version 17.8, support for threads was added, this time not behind a compiler flag.

C++

With default settings MSVC does not do two-phase name lookup which prevents it from flagging a wide range of invalid code. Most checks are deferred to template instantiation. More recent versions remedy this behavior, but it needs to be enabled by the command-line option.

Reception

Describing it as "excellent", BYTE in February 1989 approved of Microsoft C 5.1's OS/2 support, QuickC for interactive development, and CodeView debugger. Although Watcom C produced slightly faster code, the magazine said that developers "might still prefer Microsoft's friendlier and more powerful tools".