GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

No menu could be recovered. Follow the blue links in the page.

This view

  • Original page
  • New address

GeezerVison is showing www.visualcplusdotnet.com — An introduction to the C++/CLI (C++ .NET) and the MSIL/CIL bytecode used in the .NET programming

< Index #1 | Index # 2 | C++ .Net Not So New Keywords >

 

 

Unmanaged, Managed Extensions for C++, Managed and .Net Framework

 

 

In this module you will acquire knowledge about the .Net Framework. Try to understand the new terms used such as Unmanaged, Managed, Managed Extension for C++, CIL, CLI, MSIL etc. The topics that available are:

  1. Introduction

  2. C++/CLI (Microsoft Extension to the Standard C++)

  3. The MSIL/CIL Bytecode

 

Introduction

 

A managed code is an application program (such as C# program) that is executed within a runtime engine (such as .Net framework and Java Virtual Machine (JVM)) installed in the same machine. The application cannot run without it. The runtime environment provides the general library of software routines that the program uses and typically performs memory management, garbage collection and etc. It may also provide just-in-time (JIT) conversion from source code to executable code or from an intermediate language to executable code. Java’s JVM and .NET's Common Language Runtime (CLR) are examples of runtime engines. In simple words a managed code means the code can be managed in the aspects such as type safety and memory management. The unmanaged code is an executable program that runs by itself, launched from the operating system, the program calls upon and uses the software routines in the operating system, but does not require another software system to be used. C/C++ programs compiled into machine language for a particular platform and Assembly language programs that have been assembled into machine language are examples of unmanaged code.

Before this we just have C/C++ code that is unmanaged. Managed Extensions for C++ (or just Managed C++) are extensions to the Visual C++ compiler and language to allow them to create .NET code and enable access to the functionality of the .NET Framework. They include a set of Keywords and Attributes to extend the C++ language to work with, and generate, managed code. There are also some additional Pragmas, Pre-processor Directives, and Options for the compiler, as well as some Linker options. If you notice the Managed Extension of C++ uses C++ keywords and syntax, but they follow .NET rules for types and facilities.

Managed Extensions for C++ is Microsoft's set of deviations from C++, including grammatical and syntactic extensions, keywords and attributes, to bring the C++ syntax and language to the .NET Framework. Managed C++ is not a complete standalone, or fully fledged programming language. These extensions allow C++ code to be targeted to the Common Language Runtime (CLR) in the form of managed code as well as continue to inter-operate with native code (unmanaged). The compiler that comes together with this feature is starting with Visual C++ .Net 2003.

For specific definition, "Managed" refers to that it is run in, or managed by, the .NET virtual machine that functions as a sandbox for enhanced security in the form of more runtime checks, such as buffer overrun checks. Additionally, applications written in Managed C++ compile to MSIL - Microsoft Intermediate Language - and not directly to native CPU instructions like regular C++ applications do.

Managed C++ code can inter-operate with any other (managed) language that also targeted for the CLR such as C# and Visual Basic .NET as well as make use of features provided by the CLR such as garbage collection. This means Managed C++ occupies a unique position in the gallery of .NET languages. It is the only language that can communicate directly with .NET languages (such as C#, VB.NET) and native C++. The other .NET languages can only communicate with C++ code via PInvoke or COM, rather slow and inefficient methods. So we have C++ code (unmanaged), Managed C++ (managed) and C++ .Net (and other .Net languages such as VB .Net and C# -managed). But since Managed C++ can communicate directly in both managed and unmanaged contexts, it is often used as a "bridge". This story can be described in the following Figure.

 

.Net framework, managed, unmanaged and Managed extension for C++

 

C++/CLI

 

The Managed C++ extensions were significantly revised to clarify and simplify syntax and expand functionality to include managed generics. These new extensions were designated C++/CLI and included in Microsoft Visual Studio 2005. C++/CLI (Common Language Infrastructure) is the newer language specification that superseded Managed Extensions for C++. Completely reviewed to simplify the older Managed C++ syntax, it provides much more clarity over code readability than Managed C++. Like Microsoft C# (ECMA-334), C++/CLI is standardized by European Computer Manufacturers Association (ECMA-372) and ISO/IEC . It is currently only available on Visual C++ 2005. Common Language Runtime (CLR) is the name chosen by Microsoft for the virtual machine component of their .NET initiative. It is Microsoft's implementation of the Common Language Infrastructure (CLI) standard, which defines an execution environment for program code. The CLR runs a form of bytecode called the Common Intermediate Language (CIL, Microsoft version is MSIL). The CLR runs on Microsoft Windows operating systems.

 

MSIL/CIL

 

In general, Common Intermediate Language (CIL) is the lowest-level human-readable programming language in the Common Language Infrastructure and in the .NET Framework. Languages which target the .NET Framework for example, compile to CIL, which is assembled into bytecode. CIL resembles an object oriented assembly language, and is entirely stack-based. It is executed by a virtual machine. The primary .NET languages are C#, Visual Basic .NET and Managed C++. CIL was originally known as Microsoft Intermediate Language (MSIL). Due to standardization of C# and the Common Language Infrastructure, the bytecode is now officially known as CIL. CIL is still often referred to as MSIL, however, and has been backronymed to mean Machine Symbolic Intermediate Language. This is especially true of longtime veterans of the .NET languages (Microsoft changed to Machine).

Microsoft Intermediate Language (MSIL) is a byte-code that Microsoft .NET technology uses to accomplish platform independence and runtime safety seems similar to the already matured Java. During compilation of .NET programming languages, the source code is translated into MSIL code rather than machine-specific object code as done previously in C/C++. MSIL is a CPU and platform independent instruction set that can be executed in any environment supporting the .NET framework. MSIL code is verified for safety during runtime, providing better security and reliability than natively compiled binaries.

.Net framework components in layered architecture seen vertically

 

See all the Hello World example in various programming languages at Wiki that include the CLI.

For your Visual C++ Express Edition 2005 and Visual C++ .Net 2005, click your Project menu → your_project_name Properties... → Configuration Properties → the General link. By default /clr compiler option (Common Language Runtime support) is shown below.

 

Common language runtime, clr options in project property page for VC++ 2005

 

For Visual C++ .Net 2003, click Project menu → your_project_name Properties... → Configuration Properties menu → General folder → Use Managed Extensions setting. Clearly VC++ 2003 uses Managed C++.

 

 

 

 

 

Common language runtime, clr options in project property page for VC++ 2003

 

In VC++ 2005 EE, functions are managed by default when /clr compiler option is used. The compiler ignores the managed and unmanaged pragmas if /clr is not used in the compilation. Each implementation of C and C++ supports some features unique to its host machine or operating system. Some programs, for instance, need to exercise precise control over the memory areas where data is placed or to control the way certain functions receive parameters. The #pragma directives offer a way for each compiler to offer machine- and operating system-specific features while retaining overall compatibility with the C and C++ languages. Pragmas are machine- or operating system-specific by definition, and are usually different for every compiler. Pragmas can be used in conditional statements, to provide new preprocessor functionality, or to provide implementation-defined information to the compiler. For .NET Programming, Visual C++ supports the creation of the following distinct types of components and applications (this is more visible if you compile through the command line). There will be more support when the .Net Framework is updated (now we have version 1.0, 1.1 (SP1), 2.0 SP2 and 3.5 (also include for Linux and Mac OS (SP1). Also available the .Net Compact Framework 2.0 SP1). The following Table gives brief description regarding /clr options.

 

clr option

Description

mixed (compiled with /clr)

Contains both unmanaged and managed parts, making it possible for them to use .NET features, but still contain unmanaged code. Creates metadata for your application that can be consumed by other CLR applications, and allows your application to consume types and data in the metadata of other CLR components.

pure - (compiled with /clr:pure)

Produces an MSIL-only output file with no native executable code, although it can contain native types compiled to MSIL. Can contain both native and managed data types, but only managed functions.

verifiable - (compiled with /clr:safe )

Produces an MSIL-only (no native executable code) and verifiable output file. /clr:safe enables verification diagnostics. Generates verifiable assemblies, like those written in Visual Basic and C#, conforming to requirements that allow the common language runtime (CLR) to guarantee that the code does not violate current security settings.

old syntax – (compiled with /clr:oldSyntax)

Enables Managed Extensions for C++ syntax, the original Visual C++ syntax for CLR programming.

Managed Extensions for C++ syntax is deprecated in Microsoft Visual C++ 2005, You should only use /clr:oldSyntax if you are maintaining a Visual C++ application that uses Managed Extensions for C++. If you are developing a new application, use the updated syntax.

 

Table 1

 

 

 

< Index #1 | Index # 2 | C++ .Net Not So New Keywords >

You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.