Created by Microsoft as the foundation of its .NET technology, the Common Language Infrastructure (CLI) is an ECMA standar开发者_如何转开发d (ECMA-335) that allows applications to be written in a variety of high-level programming languages and executed in different system environments. Programming languages that conform to the CLI have access to the same base class library and are capable of being compiled into the same intermediate language (IL) and metadata. IL is then further compiled into native code particular to a specific architecture.
Because of this intermediate step, applications do not have to be rewritten from scratch. Their IL only needs to be further compiled into a system's native code.
What exactly is meant by the system environments?
Additionally, while studying Ivor Horton's Beginning Visual C++ 2008, I noticed that he stated that there are fundamentally different kinds of C++ applications can be developed with Visual C++ 2008. These are:
Applications which execute natively on one's computer, which he referred to as native C++ programs. Native C++ programs are written in the version of C++ that is defined by the ISO/ANSI language standard.
Application can also be written to run under the control of the CLR in an extended version of C++, called C++/CLI. These programs were referred to as CLR programs, or C++/CLI programs.
So what is meant by native C++ programs and CLR programs? What's the difference between them? Thanks for any expert's help.
"System environments" means things like Linux, Windows x86, Windows x64, etc. Notice how they use the term "architecture" interchangeably at the end of the paragraph.
A native C++ program is one where you take standard (ANSI/ISO) C++ and you compile it into a .exe. Usually you will be compiling this for a specific environment, e.g. Windows x86, in which case it could not run under Linux and would run under the WoW64 emulation layer on Windows x64. Notably, this code runs directly on the machine.
C++/CLI is a different programming language than standard C++. It, just like C# or VB.NET, runs on top of Microsoft's Common Language Interface. This means it has access to all those nice things in the paragraph you quoted, like the base class library and compilation to IL which allows it to be run on different architectures. But, just like C# and VB.NET, it does not run natively on the machine. It requires the installation of the .NET Framework; part of the .NET Framework's job is translating C++/CLI programs into native programs, which means they have much less direct access to the machine.
I am getting a bit rusty and cannot recall when exactly the word "native" popped up into the common parlance. I believe it was massively used by designers of environments destined to simplify programming running on the top of other ones designed to offer optimal access to system resources with limited focus on the programming style. Which is one may change with the time, as native also may be referred some assembler code invoked from a high level language used to program an embedded system. This is why I avoid using such concepts as operating system as even CLI/CLR despite the common fad may be implemented on Linux (Mono) or on bare silicon with no OS support (.NET Micro).
In such a context the standard C++ follows the native approach and is quite tolerant on which hardware or OS (or no OS) it runs as long as it is possible to provide a compiler and the standard library for that. The standard C++ code may be easily recompiled for any such platform as far a C++ compiler exists for it.
To be referred as C++/CLI the C++ dialect implementation needs CLI/CLR support and of course a CLI platform being present but the code may be ported without recompilation using CIL and use a standard, sophisticated library and utilities. However the initial requirements are higher than in the case of the standard C++ which can play in this case the role of the native environment.
精彩评论