Managed code

Terminology

The distinction between managed and unmanaged code is prevalent and only relevant when developing applications that interact with CLR implementations. Since many^[which?] older programming languages have been ported to the CLR, the differentiation is needed to identify managed code, especially in a mixed setup. In this context, code that does not rely on the CLR is termed "unmanaged".

A source of confusion was created when Microsoft started connecting the .NET Framework with C++, and the choice of how to name the Managed Extensions for C++. It was first named Managed C++ and then renamed to C++/CLI. The creator of the C++ programming language and member of the C++ standards committee, Bjarne Stroustrup, even commented on this issue, "On the difficult and controversial question of what the CLI binding/extensions to C++ is to be called, I prefer C++/CLI as a shorthand for "The CLI extensions to ISO C++". Keeping C++ as part of the name reminds people what is the base language and will help keep C++ a proper subset of C++ with the C++/CLI extensions."^[1]

Uses

The Microsoft Visual C++ compiler can produce both managed code, running under CLR, or unmanaged binaries, running directly on Windows.^[2]

Benefits of using managed code include programmer convenience (by increasing the level of abstraction, creating smaller models) and enhanced security guarantees, depending on the platform (including the VM implementation). There are many historical examples of code running on virtual machines, such as the language UCSD Pascal using p-code, and the operating system Inferno from Bell Labs using the Dis virtual machine. Java popularized this approach with its bytecode executed by the Java virtual machine.

Google also mention Java and Kotlin are managed code in their Android NDK JNI documents ^[3][4]

References

External links

• Microsoft Research OS written in managed C# code, Channel 9