Some stats for this period:

• There are now 2,673 total ports available in the vcpkg curated registry. A port is a versioned recipe for building a package from source, such as a C or C++ library.
• 11 new ports were added to the curated registry.
• 188 ports were updated. As always, we validate each change to a port by building all other ports that depend on or are depended by the library that is being updated for our 15 main triplets.
• 59 community contributors made commits.
• The main vcpkg repo has over 7,100 forks and 25,600 stars on GitHub.

vcpkg changelog (2025.09.17 release)

• Added support for tvOS and watchOS target platforms (PR: Microsoft/vcpkg-tool#1747, thanks @wkornewald!).
• Added two new binary caching sources that interact with Azure Storage blob containers using the azcopy executable:
  • x-azcopy-sas,<url>,<sas>[,<rw>]: Intended as a drop-in replacement for azblob, it uses SAS tokens for authentication.
  • x-azcopy,<url>[,<rw>]: Intended for non-SAS authentication methods like Microsoft Entra ID; requires preloading credentials and/or the AZCOPY_AUTO_LOGIN_TYPE.
  • Internally, we use the azcopy copy --from-to BlobLocal {destination} --include-path {files} argument to download multiple files in a single azcopy job. This improves performance and brings it more in line with azblob, that uses a single curl invocation to download a batch of files. Upload happens one file at a time in the background.
  • (PR: Microsoft/vcpkg-tool#1738)
• Added a new option --dereference-symlinks to vcpkg export. This copies symlinks as regular files and directories in the exported results, which can be useful to continuous integration systems needing to restore vcpkg’s install tree (PR: Microsoft/vcpkg-tool#1705).
• Added new vcpkg.json property: configuration. This is an alias for the vcpkg-configuration property, allowing you to embed vcpkg configuration properties that would otherwise have been specified in a separate vcpkg-configuration.json file (PR: Microsoft/vcpkg-tool#1766).
• Added installed package files to SPDX SBOM files generated by vcpkg and removed repetition of relationships that is no longer present in v3 of the SPDX spec (PR: Microsoft/vcpkg-tool#1744, thanks @ekilmer!).
• vcpkg no longer restores the original “last updated” times for restored files during binary caching operations on Windows to resolve issues where a build tool is expecting headers and binaries to have similar last updated times but thinks the restored binaries are too old. This was already previously fixed on Linux systems (PR: Microsoft/vcpkg-tool#1750, thanks @autoantwort!).
• Fixed an issue where vcpkg was failing to detect conflicting installed files when the installed content has capital letters (PR: Microsoft/vcpkg-tool#1768).
• Other minor improvements and bug fixes.

Documentation changes

• Added documentation for configuration field in vcpkg.json files. (PR: Microsoft/vcpkg-docs#527).
• Added documentation for --dereference-symlinks option for vcpkg export (PR: Microsoft/vcpkg-docs#524).
• Added documentation for x-azcopy and x-azcopy-sas binary caching sources (PR: Microsoft/vcpkg-docs#511).

If you have any suggestions for our documentation, please submit an issue in our GitHub repo or see the box at the bottom of a particular article.

Total ports available for tested triplets

While vcpkg supports a much larger variety of target platforms and architectures (as community triplets), the list above is validated exhaustively to ensure updated ports don’t break other ports in the catalog.

Thank you to our contributors

vcpkg couldn’t be where it is today without contributions from our open-source community. Thank you for your continued support! The following people contributed to the vcpkg, vcpkg-tool, or vcpkg-docs repos in this release (listed by commit author or GitHub username):

Learn more

You can find the main release notes on GitHub. Recent updates to the vcpkg tool can be viewed on the vcpkg-tool Releases page. To contribute to vcpkg documentation, visit the vcpkg-docs repo. If you’re new to vcpkg or curious about how a package manager can make your life easier as a C/C++ developer, check out the vcpkg website – vcpkg.io.

If you would like to contribute to vcpkg and its library catalog, or want to give us feedback on anything, check out our GitHub repo. Please report bugs or request updates to ports in our issue tracker or join more general discussion in our discussion forum.

The post What’s New in vcpkg (September 2025) appeared first on C++ Team Blog.

In the below discussion, .NET Framework refers to the older version of the Microsoft Common Language Runtime, also known as “Desktop Framework” (versions 4.0 through 4.8.x) while .NET  refers to versions .NET Core 3.1, .NET 5 and later.

The overload resolution behavior specified by the C++/CLI ECMA-372 Standard for overloads involving parameter arrays results in surprising behavior in some instances. This problem has manifested with recent versions of .NET, which added parameter array overloads to some commonly used classes, resulting in overload resolution which is surprising, even counterintuitive, and results in broken customer code when it is ported from .NET Framework to .NET. This article explains the problem and the solution adopted by the MSVC compiler to solve it.

Recap of Parameter Array Overload Resolution Rules

ECMA-372 section 14.6 details the rules governing overload resolution where parameter arrays are involved. The method to resolve overloads is that for a given parameter-array overload such as

    void f(T1 arg1, T2 arg2, <...>, Tm argm, ...array<T>^ arr);

and a corresponding call

    f(var1, var2, <...>, varm, val1, val2, <...>, valn);

a new function overload is synthesized, where the parameter array arr is replaced with parameters corresponding to the types of the formal arguments val1, val2 ... valn. Then, overload resolution is performed as usual with the additional requirement that such synthesized overloads have lower cost than a C-style variadic function (i.e., those using ... as the last argument) but higher cost than non-synthesized overloads. This requirement is in fact the cause of surprising behavior described below.

Customer Reports Previously Working Code is Broken

In .NET Framework, the String class has these methods (type names are from namespace System):

      Split(...array<Char>^);               // 1 (parameter array overload)   
      // other Split overloads not of interest

Given a function call such as:

      str->Split(L'a', L'b');               // 2

the Split overload (2) with the parameter array argument is the only one that matches. When this same code is compiled against .NET, a customer found that a different overload is instead chosen. The reason is subtle, surprising and a combination of questionable overload resolution rules in ECMA-372 and changes to the String class in .NET.

The difference between .NET Framework’s version of String and .NET’s version is that .NET added an additional overload, leading to this set of overloads:

      Split(Char, Int32, StringSplitOptions = StringSplitOptions::None); // 3
      Split(...array<Char>^);                                            // 4          

Now faced with the same function call (2) above, we see that both overloads are viable because C++ has an implicit Char (aka wchar_t) to Int32 (aka int) conversion, and the third parameter of (3) has a default argument. Due to the rule in ECMA-372/14.6, the parameter array overload (4) is deemed to have a higher cost and overload (3) is chosen, even though the arguments match the parameters exactly for overload (4). This is clearly not what the user wanted.

Microsoft C++ Solution

After discussion in the team, we noticed that there is a telling comment in ECMA-372/14.6 regarding preferring non-synthesized to synthesized overloads:

“[Note: This is similar to the tiebreaker rules for template functions and non-template functions in the C++ Standard (§13.3.3). end note]”

While the tie-breaking rule in ISO C++ does indeed exist, it comes into play only after overload resolution is done and the choice is between two overloads, one a generated function and one a non-template function. It looked like the ECMA-372 rule for choosing non-synthesized over synthesized was poorly formulated as it assigned the latter a higher cost regardless of the costs of the conversion sequences of the arguments.

In ISO C++, an analogous example would be:

    template<typename T>
    void Split(T, T);               // 5
    void Split(wchar_t, int);       // 6

The function call Split(L’a’, L’b’) will resolve to overload (5) since the arguments match exactly while one of the arguments of (6) requires a standard integral conversion. Hence, there is no need to use the tie-breaking rule at all. Were both formal arguments of (6) of type wchar_t, the tie-breaking rule would indeed come into play and choose (6) instead of giving an ambiguity error.

It became clear that ECMA-372/14.6 should have said if there is an ambiguity between two remaining overloads, one a synthesized parameter array overload, and one a non-synthesized overload, overload resolution would choose the non-synthesized one. We decided to implement this updated interpretation but there was a problem: what to do about the code currently compiling and working correctly with the older rules?

The risk of breaking older code was too great if we went unconditionally with the new rules, so we added two mechanisms to control this behavior at the compilation unit level, and whenever needed, at the function-call level.

First, we introduced new driver switches:

In addition, the below existing driver switches were changed to imply these corresponding modes:

In plain language, for compilations targeting .NET Framework, we maintain the old behavior, while for compilations targeting .NET, the new behavior is the default.

To allow fine-grained control over the parameter array overload resolution mode at the function-call level, we provide a new pragma, ecma_paramarray, which can be used thus:

    #pragma ecma_paramarray(push, on)
        // Normally calls Split(Char, int32, StringSplitOptions = None) and
        // not Split(...array<Char>^) under /clr:netcore but this is
        // reverted back to the old behavior under the pragma.
        auto r = s->Split(L'a', L'b'); 
    #pragma ecma_paramarray(pop)

This pragma overrides any ambient mode for handling parameter array overload resolution, whether it comes from a prior pragma use or from the translation unit’s ambient mode.

To warn about changed behavior in overload resolution, a new warning C5306 has been implemented. Consider compiling the below under /clr:netcore:

int main()
{
    System::String^ s = "Now is the time+for all good men|to come to the aid of the party";
    auto strings = s->Split(L'|', L'+');  // Split(params char[]), not Split(char, int, System.StringSplitOptions = 0)
}

This produces the diagnostic:

    auto strings = s->Split(L'|', L'+');  // Split(params char[]), not Split(char, int, System.StringSplitOptions = 0)
                      ^
w.cpp(4,23): warning C5306: parameter array behavior change: overload 'System::String::Split' resolved to 'array<System::String ^> ^System::String::Split(...array<wchar_t> ^)'; previously, it would have resolved to 'array<System::String ^> ^System::String::Split(wchar_t,int,System::StringSplitOptions)'. Use /clr:ECMAParamArray to revert to old behavior

In addition, missing the L prefix for arguments can also produce surprising results in overload resolution with the new parameter array overload rules. A new warning C5307 was implemented to warn about this:

int main()
{
    System::String^ s = "abc def\tghi";
    // Resolves to Split(System.Char, System.Int32, System.StringSplitOptions = 0) but should warn with C5307
    auto arrs = s->Split(' ', '\t');  // Should be Split(L' ', L'\t').
}

produces

    auto arrs = s->Split(' ', '\t');  // Should be Split(L' ', L'\t').
                   ^
w.cpp(4,20): warning C5307: 'array<System::String ^> ^System::String::Split(wchar_t,int,System::StringSplitOptions)':
argument (2) converted from 'char' to 'int'. Missing 'L' encoding-prefix for character literal?

Conclusion

We would be happy to hear back from you if you have encountered problems in this area and how you solved them, and if the new way of handling parameter array overloads has helped you or hindered you.

The post Fixing Overload Resolution For Parameter Arrays in C++/CLI appeared first on C++ Team Blog.

It’s that time of year again! We are excited to see you all at CppCon this year, where we’ll once again be delivering a variety of presentations, from the latest advancements in debugging technology to extensibility frameworks for AI agents. See the end of this post for a listing of all of the sessions involving Microsoft staff. And yes, there’ll be plenty of information on the freshly announced Visual Studio 2026.

We’ll also have a booth through the first four days of the conference. Come on by and let us know what matters to you or ask any burning questions you may have regarding C++ at Microsoft. We will be well stocked with our most popular swag, so come on by and have a chat with us. There may even be appearances by speakers in case you didn’t get a chance to ask that all important question after their session.

Our annual survey is now open and will be available all week throughout the conference. It’s super lightweight, and upon completion, CppCon attendees will be entered into a raffle for one of four great prizes. You do have to be onsite for the daily drawing to win (see official rules here), but even if you aren’t going to be at the conference, you can still complete the survey to let us know what you think of our C++ products. New this year on the survey is an option to select a dedicated time to talk with Microsoft staff about the topics you care about. So, if you don’t want to lose your voice in a crowded expo hall you can find that right time that fits into your busy schedule.

Try out Visual Studio 2026 Insiders – Get Started Here

Visual Studio 2026 and MSVC Build Tools v14.50 Preview are already available on the Insiders Channel (which replaces the previous Visual Studio 2022 Preview channel), with a Stable Channel going live later in 2025. We want to hear from you at CppCon about your experiences with Visual Studio 2026 Insiders, so give it a spin and come chat with us about your experiences.

Talks from Microsoft employees (and friends)

Monday 15th​

• Building Secure C++ Applications: A Practical End-to-End Approach, by Chandranath Bhattacharyya & Bharat Kumar

Tuesday​ 16th​

• What’s New for Visual Studio Code: CMake Improvements and GitHub Copilot Agents, by Alexandra Kemper
• What’s New in Visual Studio for C++ Developers in 2025, by David Li and Augustin Popa
• Back to Basics: Code Review, by Chandranath Bhattacharyya and Kathleen Baker

​Wednesday 17th

• Connecting C++ Tools to AI Agents Using the Model Context Protocol (MCP), by Ben McMorran
• LLMs in the Trenches: Boosting System Programming with AI, by Ion Todirel
• Welcome to v1.0 of the meta::[[verse]]!, by Inbal Levi
•  C++ Performance Tips: Cutting Down on Unnecessary Objects, by Prithvi Okade and Kathleen Baker

Thursday 18th​​

• MSVC C++ Dynamic Debugging: How We Enabled Full Debuggability of Optimized Code, by Eric Brumer
• It’s Dangerous to Go Alone: A Game Developer Tutorial, by Michael Price

Friday 19th​​

• Reflection-based JSON in C++ at Gigabytes per Second, by Daniel Lemire and Francisco Geiman Thiesen
• Duck-Tape Chronicles: Rust/C++ Interop, by Victor Ciura

The post Microsoft C++ Team at CppCon 2025 appeared first on C++ Team Blog.

It has been some time since we have provided an update on MSVC progress, and this one comes with the latest major update to our IDE: Visual Studio 2026 version 18.0. This version of Visual Studio ships with the MSVC Build Tools version 14.50, which includes version 19.50 of the MSVC compiler. You can try out the improvements by downloading the Insiders release. Also, if you want to track updates in the Standard Library, check out the STL Changelog, which is regularly updated. Let’s jump right into the updates!

C++23 Features

As C++ standards progress in MSVC, you can follow along using the cppreference compiler support table and help us identify what we should be working on next!

• P0849R8 (auto(x): decay-copy in the language)

// Prior to P0849R8:
void pop_front_alike(auto& x) {
    using T = std::decay_t<decltype(x.front())>;
    std::erase(x, T(x.front()));
}

// After P0849R8:
void pop_front_alike(auto& x) {
    std::erase(x, auto(x.front()));
}

• P2437R1 Implement C++23 #warning

// Valid prior to C++23.
#error bad configuration...
// Valid after C++23.
#warning configuration deprecated...

• CWG Issue 2586 (Explicit object parameter for assignment and comparison)

struct S {
  S& operator=(this S&, const S&) = default; // Valid after CWG2586.
  auto operator<=>(this const S&, const S&) = default; // Valid after CWG2586.
};

• P2280R4, allowing references to unknown values during constant evaluation

template <typename T, size_t N>
constexpr size_t array_size(T (&)[N]) {
    return N;
}

void check(int const (&param)[3]) {
    constexpr auto s2 = array_size(param); // Previously ill-formed, now accepted as a constant expression after P2280R4.
}

Smaller Conformance Updates

• • CWG2635 – Constrained structured bindings.
  • CWG2465 (Coroutine parameters passed to a promise constructor)
  • P2360R0 which extends the definition of an init-statement to allow an alias-declaration
  • CWG2496 – ref-qualifiers and virtual overriding.
  • CWG2506: Structured bindings and array cv-qualifiers.
  • CWG2507 (default arguments for operator[]).
  • CWG2585: No change required to behavior.
  • P2290R3 C++23 Hex/oct delimited escape sequence support in string literals.
  • CWG2521 which deprecates ‘operator string-literal identifier’.
  • CWG2528 which relaxes conversion rules for the spaceship operator.
  • P2797R0: Proposed resolution for CWG2692 Static and explicit object member functions with the same parameter-type-lists.
  • P2266R3 Simpler implicit move.

• Implement a warning to notify of the enum type change caused by /Zc:enumTypes.

Compiler Improvements in v14.50

C++/CLI

• Fix ICE on use of ‘auto’ in member declarations in C++/CLI managed types
  • static constexpr causes C++/CLI compiler crash
  • Compiler crashes: A managed type cannot have any friend functions/classes/interfaces
• Fix crash in compiler in C++/CLI code using ref-types on stack
  • cl.exe terminates with error code -529706956
• Visual Studio 17.12 introduced multiple errors while building managed C++ code in an MFC application

Diagnostics

• Fix an incorrect diagnostic about implicit enum type conversions in C even when the code explicitly converts the expression
  • “warning C5287: operands are different enum types” even with an explicit cast

constexpr

• Fixes several errors involving virtual function calls at compile-time.
  • MSVC erroneously claims the return value of a virtual constexpr function-call operator is not a constant expression
  • C++20 constexpr virtual polymorphism is broken in MSVC but works in ClangCL and intellisense
  • Virtual constexpr function did not evaluate to a constant
  • Unable to use virtual function in constexpr expression
• constexpr should reject overflow from addition and left shifting of constants
  • Signed overflow in core constant expression should not be allowed in all cases
• Fix scenarios where constructors should be made implicitly constexpr
  • Multiple constexpr bugs (including regresions)
• Fixes scenario when initializing a constexpr variable with a consteval call
  • Multiple constexpr bugs (including regresions)
• Fix an issue with constexpr static data members and the CRTP.
  • CRTP in MSVC 19.24 not seeing variable
  • Static constexpr member of CRTP base class not seen
• Fixes a bug related to evaluating destructors of constant objects too early; objects appeared at runtime to be in their destroyed state.
  • MSVC 14.37-40 forces my global std::string to be constinit; constinit strings don’t survive intact
• Fix an issue with constexpr lambda captures and guaranteed copy elision with a compiler generated call to memset.
  • Lambda in a function template requests capturing a constexpr variable which is not odr-used
• Allow consteval constructor calls as argument of direct-initialization.
  • MSVC Fails to compile list and direct initialization in C++20 when member constructor is consteval
• Fixed an issue where calling certain consteval functions in an if consteval would sometimes produce a compiler error.
  • The consteval function is not an immediate function under if consteval
• Allow constexpr references to be initialized with derived class rvalue.
  • Downcasting constexpr instance with static_cast not valid in constant expression
• wrong code bug in constexpr evaluation

C++ Modules

• Fix bug with importing friend declaration where the class-head-name was in a particular qualified-id form, encountered in nlohmann/json library.
  • nlohmann/json does not compile as C++20 module
• Fix compiler crash when using-declarations are used from a specialization inside a module.
  • Internal compiler error when using “using” declaration with template base class in module fragments
• Fix an issue that std::expected can’t be specialized in some cases when imported from a module.
  • C1907 modules, constexpr and std::expected
• Fixed an issue where functions using types from a named module would sometimes not execute properly or cause linker failures.
  • Compiler uses non-exported class definition from wrong module (C++20)
• Fix issue when importing a constexpr function with static local variables
  • ICE when calling imported function that returns local static container data
• Fixed an issue where the compiler would sometimes not respect a #pragma warning(disable:...) when the pragma appeared in a module or header unit.
  • #pragma warning(disable) not working in nested headers used with header units
• Fixed various issues preventing Unreal Engine 5 from building with header units.
  • Unreal does not build with header units enabled
• C++ modules compiler error: Base class undefined
• C++20 modules + boost::asio still being weird
• C++20 modules: specialzations in the global module fragment are discarded even if they are decl-rechable

Conformance

• Add support for ‘[[maybe_unused]]’ on labels and fix an issue where warning C4102 (unreferenced label) was being emitted when the only reference was from a discarded branch of an if-constexpr statement.
  • “unreferenced label” when ref hidden by “if constexpr”
• Diagnose ill-formed friend explicit specializations that were incorrectly accepted in C++20 or later.
  • Defining explicit function template specialization in friend declaration is wrongly permitted
• Fix an issue with the compiler allowing specifiers (other than type-specifiers) as part of a type-id
  • [accepts invalid] cl will accept constexpr template arguments
• Add a switch, ‘/Zc:enumEncoding’, to correctly encode the use of an enumeration as a non-type template parameter.
  • Overload resolution fails for enum non-type template parameters
• Fix an issue in which the compiler did not issue a diagnostic if a user did not prepend a dependent template-id with the ‘template’ keyword.
  • No diagnostic for missing .template in dependent names
• Fix an issue with the compiler allowing specifiers (other than type-specifiers) as part of a type-id
  • [accepts invalid] cl will accept constexpr template arguments

Reliability

• Fix an ICE when explicitly instantiating a class template which has friend functions.
  • Internal compiler error (ICE) on explicit class instantiation new to VS 2022 17.14
• Fix an ICE involving explicit variable template instantiations when PCH files are used.
  • C++ explicit variable template instantiation causes internal compiler error when using precompiled header
• Fix a compiler crash involving deep nesting of aggregates, non-aggregates, and initializer lists
  • Internal Compiler Error Found in MSVC 14.44.35207
• Fix an issue with nested generic lambdas and an issue with using ‘template’ in a qualified-id
  • VS 17.14 Preview 3.0: ICE: error C1001: Internal compiler error.
  • 17.14 Preview 3 Internal compiler error
• Fixes internal compiler error when elaborating a struct with the same name as overloaded member functions
  • Template Internal Compiler Error
• Fixed a logic error that caused an exponential growth in memory usage during type deduction if a class type had a lot of base classes
  • VS 2022 C++ compiler uses nearly 200x as much memory as VS 2019 compiler
• Fix an issue with the IL we generate for a temporary that it bound to a non-static data member of reference type.
  • CL.exe crashes with Access Violation on specific code involving references
• Fix a compiler ICE when the nested lambda inside a generic lambda references a qualified name.
  • VS 17.14 ICE with a very particular function template
• Fixed an ICE after error when the compiler saw an if constexpr with empty condition.
  • Internal compiler error parsing invalid if constexpr
• Fix a compiler crash associated with initializing a bit field.
  • Internal compiler error in VS2022 17.10+
• Fix an issue with the compiler complaining about an ill-formed pure-specifier within a function template
  • Erroneous reporting of C5288 with class defined in function template in MSVC 14.44.35207
• Fix a compiler ICE when the nested lambda inside a generic lambda references a captured variable.
  • ICE with nested std::visit + lambda captures
• Fix crash when comma missing between designated initializers
  • Internal compiler error with designated initializer in lambda
• Fixes a compiler crash with initialization of aggregates involving commas and initializer lists.
  • Internal Compiler Error Found in MSVC 14.44.35207
• Fix an issue with lambdas and non-type template parameters whose type is a pointer-to-member.
  • Internal Compiler Error (ICE) on function returning closure object
• Correct bad code generation for certain templated conversion operators
  • Wrong code generation in use of templated conversion operator with explicit object parameter
• Fix an internal compiler error during initialization of nested aggregates with initializer lists
  • Internal Compiler Error Found in MSVC 14.44.35207
• ICE when trying to access not captured pointer in lambda
• fatal error C1001: Internal compiler error.

Correctness

• Fix an issue with exception handling and unions; and an issue with the handling of an rvalue reference in the context of a lambda.
  • Internal compiler error when compiling C++17 code using union and std::array
  • When using a lambda as a template argument for a callback, the reference is not correctly bound.
• Fix an issue when explicit instantiation sometimes picks the wrong overload which has a requires clause.
  • Overload resolution for constrained function templates confused by explicit instantiation
• Correct some semantic issues with noexcept specifiers and compile errors for some noexcept specifiers on member functions.
  • noexcept for some reason work with type
  • noexcept doesn’t wants to work with operator type cast
  • [C++] Post-increment operator cannot refer to this pointer in noexcept specifier
• Fix an issue with phase-1 name binding in a non-static data member initializer
  • Wrong context for class field initializer
• Fix an incorrect value category for expressions involving indirections and arrays.
  • cl Preview fails to properly determine assignment of a prvalue
• Fix a syntax error when parsing certain template-ids in alias declarations inside some templates.
  • Source code parsing error in boost.parser in 17.14 Preview
• Fix an issue with partial ordering and template parameter objects
  • Template Specialization is not selected when passing out-of-line Lambda NTTP
• Fix a bad error C2355 on ‘this’ in a local class declaration.
  • C2355 is wrongly triggered when local class is defined in a static member function
• Fix an issue with the re-declaration of constexpr variables and an issue with parsing a bit-field width within a partial specialization of a class template.
  • A C1001 error occurs in VS17.14
  • Code does not compile with MSVC
• Fix an issue causing __declspec(no_sanitize_address) to be ignored on lambdas and forward-declared functions.
  • Address Sanitizer declspecs/attributes do not behave consistently across compilers
• Fix incorrect point of instantiation when an inline static data member has a class template specialization type.
  • static inline atomic and another atomic generate warning C4744 in Release configuration
• Fix an issue when a static operator() was also an abbreviated function template.
  • Call to static operator() is elided
• Fix an issue with no_unique_address and class types with common subobjects.
  • [[[msvc::no_unique_address]] incorrectly optimizes mixed structs with leading nested empty struct](https://developercommunity.visualstudio.com/t/msvc::no_unique_address-fails-to-opt/10892814)
• Fix an issue with template template parameters and default template arguments
  • VS2022 VC++ default template parameter derivation error causes the result to be inconsistent with expectations
• Fix incorrect resolution of a name referring to the enclosing class template.
  • MSVC Fails to compile friend function template whose template constraint (C++20) contains the enclosing class template
• Fix an issue causing error C2106 on certain member-access expressions that should be lvalues.
  • After updating VS2022 to 17.14 C++ compiler is giving me an error about lvalue and ending up with ICE (open source code)
• Fixed an issue where decltype would sometimes return the wrong type when used with ternary expressions.
  • conditional operator gives wrong result type if both operands are static_cast to prvalue pointer type
• Fix 1) an issue with C++23 multi-dimensional array indexing; 2) an issue with allowing ‘[[maybe_unused]]’ on a label; and 3) an issue with the compiler being too eager to instantiate a specialization of a function template.
  • Multidimensional operator[] with /Wall reports bogus warning C4548
  • Discarded statement instantiated in a generic lambda
• Fix an issue with C4100 (unreferenced parameter) and abbreviated function template; and an issue with a missing warning for using a comma operator in subscript expression
  • Bogus C4100 “unreferenced formal parameter” warning with if constexpr in static member function template of a class template
• Fix spurious unreferenced variable warning for OpenMP private loop variable.
  • Incorrect C4101 OpenMP compiler warning in 17.8.0
• Fix issues with ‘std::bit_cast’, integral non-type template parameters and instantiation of variable templates.
  • __builtin_bit_cast Internal compiler error
  • Issue in specific conditions with modulo operator in variadic template with “/permissive-” after version 19.32.
• Fix spurious warning C4193 when compiling some preprocessed files
  • Incorrect C4193 with /std:c++20
• Fix a missing error when aggregate initialization is incorrectly used during class template argument deduction.
  • Deduction of class template arguments picks up wrong constructor
• Fix determination of value category for certain kinds of expressions involving a sub-expression that is a conditional expression.
  • Class member’s array’s element is not an l-value in a ternary expression
• Fix an issue with an elaborated class-specifier in a template argument list
  • [Unreal Engine] Template compile error regression with msvc 14.42
• Fix an issue with operator binding and an issue with binding local class types.
  • [Unreal Engine] Template compile error with msvc 14.44
• Fix a couple of issue related to using enum declarations.
  • using enum c++ 20 doesnt supported as well
• MSVC does not compile a function type with multiple parentheses
• Defining class method outside the class, with concept
• Variable Declaration Allowed Inside Switch Case Without Scoping Operator
• No warning C4706 for assignment to std::unqiue_ptr used as a condition
• VS 17.14. “if constexpr (requires ” doesn’t work correctly
• Incorrect overload resolution for static operator()
• Lvalue-to-rvalue conversion rules for std::nullptr_t are violated
• Error message depends on unused parameter pack
• In-class initialization of pointer-to-member + virtual function make MSVC to compile incorrectly
• MSVC Compiler Bug: requires Constraint Fails to Remove Non-Matching Template Candidates, Leading to Compilation Error
• Regression: c++ compilation failure in code generated by Qt’s meta object compiler
• Rejects valid pack expansion in base specifier in lambda body

Correctness (C compiler)

• In C23, don’t decay functions to function pointers when used as an argument to typeof
  • typeof not working with function types

Closing

As always, we welcome your feedback. Feel free to send any comments through e-mail at visualcpp@microsoft.com, through Twitter @visualc, or through BlueSky @msftcpp.bsky.social. Also, feel free to follow Cameron DaCamara on Twitter @starfreakclone.

If you encounter other problems with MSVC in Visual Studio 2026 please let us know via the Report a Problem option, either from the installer or the Visual Studio IDE itself. For suggestions or bug reports, let us know through Developer Community.

The post C++ Language Updates in MSVC Build Tools v14.50 appeared first on C++ Team Blog.

Visual Studio 2026 features a fresh UI, faster performance, and improved developer productivity with advanced AI integration.

For more details on what’s new, check out the official announcement on the Visual Studio Blog!

We would love your feedback – try out our Insiders release of Visual Studio 2026 today! If you run into any issues, you can report them to Visual Studio Developer Community from the IDE by navigating to Help > Send Feedback > Report a Problem.

The post Visual Studio 2026 Insiders is here! appeared first on C++ Team Blog.

Some stats for this period:

• There are now 2,666 total ports available in the vcpkg curated registry. A port is a versioned recipe for building a package from source, such as a C or C++ library.
• 14 new ports were added to the curated registry.
• 240 ports were updated. As always, we validate each change to a port by building all other ports that depend on or are depended by the library that is being updated for our 15 main triplets.
• 86 community contributors made commits.
• The main vcpkg repo has over 7,000 forks and 25,500 stars on GitHub.

GitHub Dependabot support for vcpkg

Earlier this month, we announced GitHub Dependabot support for vcpkg. This allows GitHub users to receive automated PRs to upgrade their vcpkg versioning baselines. Since that announcement, the automated PRs have been updated to include information about the vcpkg release being upgraded to, including port counts per triplet, as well as a list of impacted ports and their original vs. new versions. Here is an example of one of the new PRs.

vcpkg changelog (2025.08.27 release)

No tool updates as of 2025.08.27. More tool updates will be included in next month’s release.

Documentation changes

• Added documentation covering Dependabot support for vcpkg (PR: Microsoft/vcpkg-docs#512, thanks @JamieMagee!).
• Other minor documentation fixes.

If you have any suggestions for our documentation, please submit an issue in our GitHub repo or see the box at the bottom of a particular article.

Total ports available for tested triplets

While vcpkg supports a much larger variety of target platforms and architectures (as community triplets), the list above is validated exhaustively to ensure updated ports don’t break other ports in the catalog.

Thank you to our contributors

vcpkg couldn’t be where it is today without contributions from our open-source community. Thank you for your continued support! The following people contributed to the vcpkg, vcpkg-tool, or vcpkg-docs repos in this release (listed by commit author or GitHub username):

Learn more

You can find the main release notes on GitHub. Recent updates to the vcpkg tool can be viewed on the vcpkg-tool Releases page. To contribute to vcpkg documentation, visit the vcpkg-docs repo. If you’re new to vcpkg or curious about how a package manager can make your life easier as a C/C++ developer, check out the vcpkg website – vcpkg.io.

If you would like to contribute to vcpkg and its library catalog, or want to give us feedback on anything, check out our GitHub repo. Please report bugs or request updates to ports in our issue tracker or join more general discussion in our discussion forum.

The post What’s New in vcpkg (August 2025) appeared first on C++ Team Blog.

A special thank you to @SidneyCogdill for his outstanding contributions, especially for bringing support for C++20 modules to Proxy and driving major‑version compatibility efforts. His work has made the library even more accessible and future‑proof.

What is Proxy?

Proxy is a header-only, cross-platform C++20 library that lets you write polymorphic code without the pain of inheritance or the limitations of traditional virtual functions. Proxy enables you to:

• Write code that is portable, non-intrusive, and easy to maintain
• Manage object lifetimes flexibly, with or without ownership
• Achieve performance that rivals or exceeds hand-written code
• Compose abstractions from any expression: member functions, free functions, operators, conversions, and more

If you’re new to Proxy, check out our GitHub repository and our previous announcements: Announcing the Proxy 3 Library for Dynamic Polymorphism and Analyzing the Performance of the “Proxy” Library.

New Website: Your One-Stop Reference

We’ve launched a new documentation website, built with MkDocs, to help you find everything you need about Proxy. The new site offers improved navigation, a unified FAQ, and a clear structure for all features and APIs. Explore the documentation and discover how easy it is to get started!

Try Proxy Instantly in Compiler Explorer

You can now experiment with Proxy directly in your browser using Compiler Explorer! Write, run, and inspect Proxy code without any setup. Just click on “Libraries” and search for “proxy” in Compiler Explorer or use a shared link from our examples to get started. It’s a great way to see Proxy in action and share your findings with others.

What’s New in Proxy 4?

Skills: Composable Facade Capabilities

Let’s see how easy it is to add formatting support to your types (run in Compiler Explorer):

#include <format>
#include <proxy/proxy.h>

struct Formattable : pro::facade_builder
    ::add_skill<pro::skills::format>
    ::build {};

int main() {
  pro::proxy<Formattable> p = pro::make_proxy<Formattable>(123);
  std::cout << std::format("{}\n", *p); // Prints "123"
}

Skills are reusable building blocks that let you add powerful capabilities to your facades with a single line:

• skills::format and skills::wformat: Enable standard C++ formatting for your proxies. This was never possible with virtual functions or earlier Proxy versions.
• skills::fmt_format and skills::fmt_wformat: Bring full {fmt} library support to your proxies, letting you use advanced formatting features with zero boilerplate.
• skills::rtti: Add runtime type information and safe casting to your proxies.
• skills::as_view and skills::as_weak: Allow seamless conversion to non-owning or weak proxies, making your code safer and more expressive.
• skills::slim: Restrict your proxy to pointer-sized storage for maximum efficiency.

Skills are easy to compose and extend. You can also author internal, domain‑specific skills to capture patterns (logging, metrics hooks, validation, instrumentation) so teams reuse a single, well-reviewed definition instead of duplicating conventions. This improves consistency and long‑term maintainability. See the skills documentation for more.

Easy Borrowing and Weak References

Proxy 4 introduces convenient aliases for non-owning and weak references: proxy_view and weak_proxy. These are built on top of the core proxy concept, making it easier to express borrowing and weak ownership patterns in your code. For example, you can use proxy_view to safely borrow an object without taking ownership, or weak_proxy to create a weak reference that can be locked when needed. See the proxy_view documentation and weak_proxy documentation for details.

Shared Ownership Made Simple

With the new make_proxy_shared and allocate_proxy_shared APIs, you can create shared and weak proxies efficiently, without the overhead of std::shared_ptr. These APIs use compact internal pointer types, ensuring high performance and low memory usage. Learn more in the make_proxy_shared documentation and allocate_proxy_shared documentation.

Smarter Dispatch and Conversion

• weak_dispatch lets you define fallback behavior for missing conventions, so your code can handle incomplete types gracefully.
• Conversion dispatches (explicit_conversion_dispatch, implicit_conversion_dispatch) are now easier to use and provide clearer error messages.
• The new proxiable_target and inplace_proxiable_target concepts make it clear which target types can be used with a given facade, helping you avoid surprises and write safer code.

Recursive Facade Patterns Made Easy

Proxy 4 introduces facade_aware_overload_t, which lets you define recursive conventions that refer to the facade itself without forcing early instantiation. This is especially useful for operator chaining patterns (like arithmetic or concatenation) that return new proxy objects of the same facade. Example:

#include <format>
#include <iostream>
#include <proxy/proxy.h>

template <class F>
using BinaryOverload =
    pro::proxy<F>(const pro::proxy_indirect_accessor<F>& rhs) const;

template <class T, pro::facade F>
pro::proxy<F> operator+(const T& value,
                        const pro::proxy_indirect_accessor<F>& rhs)
  requires(!std::is_same_v<T, pro::proxy_indirect_accessor<F>>)
{
  return pro::make_proxy<F, T>(value + proxy_cast<const T&>(rhs));
}

struct Addable
    : pro::facade_builder              // Compose capabilities
      ::add_skill<pro::skills::rtti>   // RTTI support
      ::add_skill<pro::skills::format> // Formatting support
      ::add_convention<pro::operator_dispatch<"+">,
                       pro::facade_aware_overload_t<BinaryOverload>> // Recursive operator
      ::build {};

int main() {
  pro::proxy<Addable> p1 = pro::make_proxy<Addable>(1);
  pro::proxy<Addable> p2 = pro::make_proxy<Addable>(2);
  pro::proxy<Addable> p3 = *p1 + *p2; // Uses facade-aware overload
  std::cout << std::format("{}\n", *p3); // Prints "3"
}

See the facade_aware_overload_t documentation for details.

Quality Improvements for Everyone

• Bitwise Trivially Relocatable: Proxy now supports types that can be moved with memcpy, enabling faster moves and assignments by default. This means better performance and less boilerplate for you. See the is_bitwise_trivially_relocatable documentation for more details.
• C++20 Modules Support: Thanks to @SidneyCogdill, Proxy now ships with .ixx files for blazing-fast builds and better IDE support.
• Diagnostics: Error messages are now much clearer and more actionable, helping you quickly understand and fix issues in your code.
• Debugging Experience: Proxy 4 generates better debugging symbols, making it easier to inspect proxies in your debugger and understand what’s happening under the hood.
• Accessibility Authoring: It’s now easier to expose reflection and dispatch capabilities in your facades, with less boilerplate and more flexibility.
• Code Generation: Proxy 4 refines the call path for indirect dispatch, reducing the number of instructions around indirect calls.
• Compiler Support: NVIDIA HPC is newly added to our supported toolchains. Proxy 4 passes tests on the latest GCC, Clang, MSVC, and NVIDIA HPC compilers. We’re committed to keeping Proxy working with these compilers going forward, including freestanding environments. See the README for minimum versions and flags.

Major Version Compatibility

Upgrading a small component is usually straightforward, but migrating a monorepo or multi-module product can be challenging. Follow the guidelines below:

1. Minor or patch upgrades (e.g. 3.3.0 → 3.4.0) All 3.x.y releases preserve API/ABI compatibility, so different parts of the program may safely depend on different 3.x.y versions. No special action is required.
2. Major upgrades (e.g. 3.4.0 → 4.0.0)
   • If your current version is earlier than 3.4.0, migrate to 3.4.0 first.
   • Starting with 3.4.0, each major release is placed in a versioned inline namespace (pro::v3, pro::v4, …).  When a translation unit sees multiple majors, qualify the namespace explicitly:

     pro::v3::foo(); // Proxy 3 API
     pro::v4::foo(); // Proxy 4 API

     The newest release re-exports its namespace as the inline (default) namespace, so unqualified calls (pro::foo()) resolve to the latest version once the migration is complete.

   • The macros also have major-qualified aliases, e.g. PRO4_DEF_MEM_DISPATCH. Use these forms whenever headers from multiple majors are included in the same translation unit.
   • Upgrade subsystems incrementally, module-by-module or DLL-by-DLL. When every target depends only on the new major, drop the old include path and remove the previous version from your build.

These rules let old and new code coexist during the transition while keeping ODR violations at bay.

Other Notable Changes

• The macro PRO_DEF_WEAK_DISPATCH has been removed in favor of the more flexible weak_dispatch class.
• The class proxiable_ptr_constraints has been merged into the ProFacade requirements for simplicity.
• The function template access_proxy is now shadowed by proxy_invoke and proxy_reflect.
• The ProFacade and ProDispatch requirements have been revised for clarity and consistency.

Summary

Proxy 4 builds on a mature foundation introduced and proven in Proxy 3, and adds focused refinements rather than reinventing the model.

Core capabilities (established in Proxy 3 and still central in day‑to‑day use):

• Expression‑based polymorphism: define a facade once, make virtually any expression (member calls, free calls, operators, explicit/implicit conversions) polymorphic.
• Flexible creation: make_proxy (inline where possible), allocate_proxy (custom allocators), raw pointer attachment, unique ownership, and composition of abstractions via add_convention / add_reflection / add_facade.
• Lifetime versatility in a single proxy type: same facade supports non‑owning, unique, inline, or externally managed objects transparently.
• Overload resolution & reflection support for concise, generic call sites.

Targeted Proxy 4 refinements:

• Ergonomic aliases for borrowing / weak observation (proxy_view, weak_proxy) built atop the existing core.
• Skill-based composition (formatting, RTTI, view/weak conversion, slim layout, {fmt} integration) to replace repetitive convention boilerplate.
• New shared/weak creation helpers (make_proxy_shared, allocate_proxy_shared) complement (not replace) the more frequently used make_proxy / allocate_proxy paths.
• Concepts (proxiable_target, inplace_proxiable_target) clarify when a type can be used with make_proxy versus make_proxy_inplace, giving earlier, sharper diagnostics instead of template noise.
• facade_aware_overload_t enables recursive facade/operator definitions (e.g. arithmetic that returns the same facade) without forcing premature instantiation.
• weak_dispatch for graceful fallback when some contained types omit a convention.
• Improved diagnostics, relocation optimizations (is_bitwise_trivially_relocatable), module support, and leaner code generation.

Questions and feedback are welcome! If you find something unclear, a bug, or a documentation gap, feel free to open an issue or submit a PR.

The post Announcing Proxy 4: The Next Leap in C++ Polymorphism appeared first on C++ Team Blog.

What does this mean for your projects?

For C++ developers managing dependencies through vcpkg, this integration eliminates a critical gap in the DevSecOps pipeline. Dependabot will automatically scan your vcpkg.json manifests, monitor for updates, and create pull requests when new versions become available. This matches the automation capabilities enjoyed by other language ecosystems like JavaScript and Python.

Unlike most package managers, vcpkg uses a “baseline” system that’s particularly well-suited to C++’s complexity. Instead of updating individual packages piecemeal, Dependabot advances your entire baseline to a newer snapshot where all libraries have been tested together.

Think of it this way: rather than updating curl and leaving OpenSSL at an older version, which might cause compatibility issues, the baseline update moves you to a curated set where curl, OpenSSL, and all your other dependencies are known to work together. This approach prevents the ABI (Application Binary Interface) incompatibilities and version conflicts that plague C++ projects when libraries compiled with different settings try to interact.

A single change updates all unpinned dependencies to versions that vcpkg maintainers have verified work together. You can still pin specific libraries using version>= constraints or overrides when needed. See vcpkg’s versioning documentation for more details.

Configuration and implementation

Setting up Dependabot for vcpkg follows the same pattern as other supported ecosystems. Add the following configuration to your .github/dependabot.yml file:

version: 2
updates:
- package-ecosystem: "vcpkg"
  directory: "/" # The location of your vcpkg.json
  schedule:
    interval: "weekly"

The configuration supports all standard Dependabot options, including custom schedules, cooldown periods, and custom commit messages.

See it in action

For a practical demonstration, check out this example repository that showcases Dependabot updating vcpkg dependencies. The repository includes a vcpkg.json manifest with a builtin-baseline field that Dependabot automatically updates to the latest vcpkg port repository commit. You can examine the pull requests to see what Dependabot does when updates are available.

Maintenance benefits

The integration brings modern dependency management practices to C++ development, ensuring libraries stay current with minimal manual effort. Regular dependency updates prevent the accumulation of technical debt that occurs when libraries fall behind multiple major versions. With Dependabot handling the routine work of checking for updates, developers can focus on feature development while maintaining a healthy dependency tree.

Try out the experience

Automated dependency management reduces maintenance overhead and helps prevent security issues from outdated packages. By implementing Dependabot for vcpkg, you can maintain current dependencies without dedicating significant manual effort to the task.

Take the first step today: add the Dependabot configuration file to your repository and let automated dependency management transform how your team handles C++ package updates.

Learn more

• Dependabot version updates now support vcpkg – GitHub Changelog
• Report issues or get help with Dependabot for vcpkg
• Example repository with a vcpkg Dependabot PR
• Dependabot options reference
• vcpkg manifest mode
• vcpkg versioning concepts
• Dependabot support for vcpkg

The post Dependabot support for vcpkg appeared first on C++ Team Blog.

Some stats for this period:

• There are now 2,653 total ports available in the vcpkg curated registry. A port is a versioned recipe for building a package from source, such as a C or C++ library.
• 34 new ports were added to the curated registry.
• 282 ports were updated. As always, we validate each change to a port by building all other ports that depend on or are depended by the library that is being updated for our 15 main triplets.
• 101 community contributors made commits.
• The main vcpkg repo has over 7,000 forks and 25,300 stars on GitHub.

vcpkg changelog (2025.07.25 release)

The following notable changes were made in this release:

• Added new vcpkg command license-report, which prints the SPDX licenses from the Software Bill of Materials (SBOMs) of all installed packages. In addition, SPDX licenses now also get printed for packages being installed via classic mode vcpkg install <port names> (PR: Microsoft/vcpkg-tool#1514).
• Binary cache restore optimization: Now decompressing zip files ordered by size, resulting in time savings of up to 14% (PR: Microsoft/vcpkg-tool#1715, thanks @autoantwort!).
• vcpkg now uses azcopy to upload large artifacts for binary caching, which enables binary cache entries > 5GB in size (PRs: Microsoft/vcpkg-tool#1679, Microsoft/vcpkg-tool#1717, thanks @dg0yt!).
• Added support for visionOS as an available target platform for vcpkg builds (PR: Microsoft/vcpkg-tool#1681, thanks @colincornaby!).
• Added support for building and using vcpkg on Solaris and illumos systems (PR: Microsoft/vcpkg-tool#1684, thanks @trisk!).
• Other minor bug fixes and internal feature improvements.

Documentation changes

• Minor documentation fixes (thanks @bgilbert and @ impugachev!).

If you have any suggestions for our documentation, please submit an issue in our GitHub repo or see the box at the bottom of a particular article.

Total ports available for tested triplets

While vcpkg supports a much larger variety of target platforms and architectures (as community triplets), the list above is validated exhaustively to ensure updated ports don’t break other ports in the catalog.

Thank you to our contributors

vcpkg couldn’t be where it is today without contributions from our open-source community. Thank you for your continued support! The following people contributed to the vcpkg, vcpkg-tool, or vcpkg-docs repos in this release (listed by commit author or GitHub username):

Learn more

You can find the main release notes on GitHub. Recent updates to the vcpkg tool can be viewed on the vcpkg-tool Releases page. To contribute to vcpkg documentation, visit the vcpkg-docs repo. If you’re new to vcpkg or curious about how a package manager can make your life easier as a C/C++ developer, check out the vcpkg website – vcpkg.io.

If you would like to contribute to vcpkg and its library catalog, or want to give us feedback on anything, check out our GitHub repo. Please report bugs or request updates to ports in our issue tracker or join more general discussion in our discussion forum.

The post What’s New in vcpkg (July 2025) appeared first on C++ Team Blog.

GitHub Copilot now supports Next Edit Suggestions (or NES for short) to predict the next edits to come. NES in GitHub Copilot helps you stay in flow by not only helping predict where you’ll need to make updates, but also what you’ll need to change next.

Example: Converting C code to C++

At Microsoft Build, we showed how NES can dynamically update C++ code, including an example of updating code syntax that was using C functions to use the C++ Standard Template Library (STL).

For example, when updating code that reads from stdin from C-style code that uses raw character arrays to C++ code that uses the std::string type, NES predicts and suggests updates across all applicable areas near the cursor. NES replaces calls to fgets with calls to std::getline and replaces atoi with the C++ std::stoi, which has better error handling.

You can then review and make any relevant updates – for example, in this case, any other areas that call on strings.

Next Edit Suggestions is now available in both Visual Studio and VS Code.  As you try out NES, we’d love to hear your feedback. Share your feedback on Developer Community for Visual Studio or on GitHub for VS Code to help shape what’s next and how we can improve. If NES streamlines your workflow or saves you time, let us know – drop a comment or email us at visualcpp@microsoft.com. We’re excited to see how you’re using NES for C++!

Agent Mode and other new Copilot features

GitHub Copilot is evolving beyond typical code completion, with features like Next Edit Suggestions, Agent Mode, and MCP transforming how developers interact with AI. The Visual Studio session at Build not only showcased NES in action, but also Agent Mode and MCP and how they each revolutionize the traditional Copilot interfaces. While NES predicts your next code edits in the editor, agent mode can work as an iterative AI assistant that understands your intent to provide dynamic edits and information.

To learn more about the C++ NES use cases detailed above and these other new features available for developers in Visual Studio, watch “Top GitHub Copilot features you missed in Visual Studio 2022”.

What do you think?

Try out the latest Copilot features for your C++ workflows today. To access these updates to Copilot, you’ll need an active GitHub Copilot subscription and the latest version of Visual Studio.

Our team is working hard on improving C++ integrations with Copilot, so please let us know any other enhancements you’d like to see. Share your thoughts with us on Developer Community for Visual Studio or on GitHub for VS Code to help shape what’s next and how we can improve. You can also reach us via email at visualcpp@microsoft.com, via X at @VisualC, or via Bluesky at @msftcpp.bsky.social.

The post Dynamically Update C++ syntax using Next Edit Suggestions appeared first on C++ Team Blog.