Update dotnet-programming-with-cpp-cli-visual-cpp.md #1
Conversation
|
/cc @tgani-msft |
|
Sorry about the delay @AaronRobinsonMSFT, will get to this today. |
| > [!IMPORTANT] | ||
| > C++/CLI is a technology designed during the early years of .NET (2005–2010) and remains supported for compatibility purposes. It is best suited for existing codebases, particularly those being brought forward from the .NET Framework to .NET Core, or for maintaining large legacy systems that are unlikely to evolve beyond the .NET Framework. | ||
| > | ||
| > While C++/CLI is reliable and robust, no new feature work is planned beyond what’s necessary to ensure continued functionality. Developers should be aware that using C++/CLI pessimizes both C++ and .NET languages, as it is constrained by the language features and APIs available at the time of its design—prior to ISO C++11 and .NET Core. |
There was a problem hiding this comment.
A more accurate wording may be: [C++/CLI] (https://ecma-international.org/publications-and-standards/standards/ecma-372] was designed around C++11 and its ECMA standard has not been updated to keep up with newer C++ standards like C++20 and C++23. Practically, this means that newer C++ features like concepts, coroutines and modules do not work with managed types and even for native types, the result may be mixed mode binaries where the newer features are compiled to native code. For details, see this blog article by the MSVC team.
There was a problem hiding this comment.
was designed around C++11
@tgani-msft Are you sure about this date? C++/CLI was defined in 2005, long before C++11 was formalized. I accept there was likely some overlap with things, but was C++/CLI reevaluated to ensure comformance to the C++11 memory or threading model? The fact that it does work with C++11 types in many cases, move semantics, doesn't mean that it was designed for that. If I recall, we did need to go in and add support for C++11 when it was released, particularly around move semantics. The fact that it works seems akin to what is done for C++20 and C++23, it compiles and functions, but the language was not defined during C++11 and issue could arise in practice.
There was a problem hiding this comment.
You are correct, the ECMA standard predates C++11 by many years. While some C++/CLI features made it into C++11 (nullptr, enum class), it was based mostly on C++98, so you can say that instead. C++11 standardization took many years so the C++/CLI and C++11 standards were being developed in parallel, but the ECMA standard was released first. We did work to implement C++11 features like inline namespaces and '&&' types (move ctor support is an example) but the principle observed from the very start was that the managed and native type universes are kept separate as much as possible. The point I'm trying to make is that for compilation of ISO C++ constructs, we either compile them to managed code, or to native code and call via interop. That strategy is going to continue for the foreseeable future.
Discussion point