spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

For .NET Programming, C++ supports the creation of three distinct types of components and applications: mixed, pure, and verifiable. All three are available through the /clr (Common Language Runtime Compilation) compiler option. Depending on the sub-setting used, the resulting assembly (.exe or DLL) has distinct qualities, abilities, and restrictions. This topic discusses the merits of each type.

Mixed (/clr)
Mixed assemblies (compiled with /clr), contain both unmanaged and managed parts, making it possible for them to use .NET features, but still contain unmanaged code. This allows applications and components to be updated to use .NET features without requiring that the entire project be rewritten. Using C++ to mix managed and unmanaged code in this fashion is called C++ Interop. For more information, see Mixed Assemblies and Native and .NET Interoperability.

Pure (/clr:pure)
Whereas mixed assemblies (compiled with /clr) excel at interfacing with unmanaged code, pure assemblies excel at interfacing with .NET code. Pure assemblies (compiled with /clr:pure) can contain both native and managed data types, but only managed functions. Like mixed assemblies, pure assemblies allow interop with native DLLs through P/Invoke (see Using PInvoke in C++), but the C++ Interop features described in Using C++ Interop Features are not available for pure assembiles. Moreover, pure assemblies cannot export functions that are callable from native functions. This is because the entry points in a pure assembly use the __clrcall calling convention, which native functions cannot invoke. For guidance on porting code to pure MSIL compilation, see How to: Migrate to /clr:pure.

Advantages of /clr:pure
Better Performance: Because pure assemblies contain only MSIL, there are no native functions, and therefore no managed/unmanaged transitions are necessary. (Function calls made through P/Invoke are an exception to this rule.)


AppDomain Awareness: Managed functions and CLR data types and exist inside Application Domains, which affects their visibility and accessibility. Pure assemblies are domain-aware (__declspec(appdomain) is implied for each type) so accessing their types and functionality from other .NET components is easier and safer. As a result, pure assemblies interoperate more easily with other .NET components than mixed assemblies.


Non-disk loading: Pure assemblies can be loaded in-memory and even streamed. This is essential for using .NET assemblies as stored procedures. This differs from mixed assemblies, which, due to a dependency on the Windows loading mechanisms, must exist on disk in order to execute.


Reflection: Because mixed assemblies must be loaded the Windows loading system, and multiple executables cannot be loaded into the same process, using reflection (the programmatic discovery and/or creation and invocation of types in external assemblies) on mixed assemblies is limited. For example, it is not possible to reflect over mixed executables. In contrast, pure assemblies provide full reflection support.


Host Controllability: Because pure assemblies contain only MSIL, they behave more predictably and flexibly than their mixed counterparts when used in applications that host the CLR and modify its default behavior.


Limitations of /clr:pure
This section covers features and functionalities that are not supported by /clr:pure in this release for Visual Studio .NET.

Pure assemblies cannot be called by unmanaged functions. Therefore pure assemblies cannot implement COM interfaces or expose native callbacks. Pure assemblies cannot export functions via __declspec(dllexport) or .DEF files nor can they import functions via __declspec(dllimport), as these mechanisms are require unmanaged code. Functions in a native module can be called from a pure assembly, but pure assemblies cannot expose native-callable functions, so exposing functionality in a pure assembly must be done through managed functions in a mixed assembly. See How to: Migrate to /clr:pure for more information.


ATL and MFC libraries are not supported by pure mode compilation in Visual C++ 2005.


Pure netmodules are not accepted as input to the C++ linker. For C++, this is a minor problem, since pure OBJ files are accepted by the linker, and OBJ files contain a superset of information contained in netmodules.


Global (per AppDomain) data is not supported in pure assemblies


Compiler COM support (#import) is not supported, as this would introduce unmanaged instructions into the pure assembly.


Floating point options for alignment and exception-handling are not adjustable for pure assemblies. As a result, __declspec(align) cannot be used. This renders some header files, such as fpieee.h, incompatible with /clr:pure.



Verifiable (/clr:safe)
The /clr:safe compiler switch generates .NET-enabled assemblies and applications like those written in Visual Basic and C#. These assemblies conform to requirements that allow the common language runtime (CLR) to guarantee that the code does not violate current security settings and--that if the code fails--it does so gracefully. Verifiable components allow the CLR, at run time, to determine if the code safely satisfies the security restrictions currently in effect. For example, if the current security settings prohibit the component from writing to disk, the CLR can determine whether a given verifiable component meets this criterion before executing any of the code. There is no CRT support for verifiable assemblies. (CRT support is available to pure assemblies through a Pure MSIL version of the C Runtime library.)

Verifiable assemblies offer these advantages over pure and mixed assemblies:

Increased security.


Some situations require it (SQL components, for example).


Future versions of Windows will increasingly require components and applications to be verifiable.


The downside is that no interop features are available. Verifiable assemblies cannot contain any unmanaged functions or native data types, even if they are not referenced by the managed code.

For more information about verifiable assemblies, see:

How to: Migrate to /clr:safe


How to: Create Verifiable C++ Projects


Using Verifiable Assemblies with SQL Server


Note: Despite the use of the word "safe", compiling applications and components with /clr:safe does not mean that they are bug free; it just means that the CLR can verify the security settings at run time.

Note: Regardless of assembly type, calls made from managed assemblies to native DLLs via P/Invoke will compile, but may fail at runtime depending on the security settings in effect.

Zitat von »"bassdscho"«

wo hast du denn dein SDK her? ich hätte auch gerne das wo überall auch c++ beispiele dabei sind.