0
votes

Hi im on the process of learning c++/cli and to this end reading the book expert c++/cli. in the book the author states "The compiler option /clr:pure still allows you to compile existing C++ code to managed code (source code compatibility)". does this mean existing native codes where objects that are being initialized in the CRT heap can be recompiled using /clr:pure ?

UPDATE 1: For example Can Class B compiled with /clr:pure?.

Class A {

 Public :
 A()
 {

 }

 ~A()
 {

 }

 void Foo()
 {
 }

};


Class B {

 Public :

 A* test;

 B()
 {
   test = new A();
   test->Foo();
 }

 ~B()
 {
   delete test;
 }

};

MSDN states that

Pure assemblies (compiled with /clr:pure) can contain both native and managed data types, but only managed functions

and

/clr:pure

Produces a Microsoft Intermediate Language (MSIL)-only output file that has no native executable code. However, it can contain native types compiled to MSIL.

From my understanding ( i may be wrong here) test = new A(); produces native code thus cannot be compiled with /clr:pure. If I am wrong can any one give me a example of

  1. A native function (as MSDN states only managed functions are allowed)
  2. An example of a class that can be compiled with a /clr and not with /clr:pure

Thanks

1
Classes don't get initialized, objects do. Provide an example of the native code you're talking about.Ben Voigt
@BenVoigt Sorry for my mistake. I have corrected it as well as posted a simple code sampleuser119020
When /clr:pure is in effect, all functions are managed. Note that you're still using native library calls -- with /clr:pure those will be performed using p/invoke instead of IJW C++ interop.Ben Voigt

1 Answers

4
votes

Sure, that's possible, any C++03 compliant C++ code can be translated to MSIL and jitted to machine code at runtime.

It is however a fairly meaningless thing to do, you don't get verifiable code out of it. The program is just as "unsafe" as it is in native C++, pointers are still pointers that corrupt memory like they always did. And you won't get the garbage collector love. The only goody you get is architecture independence. What is subtracted most of all is the compile-time optimizer. The MSIL gets optimized but that is done with the practical constraints of having little time to spend on it at runtime, it cannot do nearly as good a job. Add stuff like auto-vectorization and auto-parallelization on the wanted-list.

Using /clr:pure and /clr:safe only made sense back in 2005, Stanley Lippman et al worked on making C++ a first class citizen in the managed .NET world. That didn't pan out that way, not in the least because everybody quit when they were done, the language is now posited as an interop language. It is very good at that. These options are on top of the deprecated list, only plain /clr will have a future.