i'm not totally clear with some concepts about managed and unmanaged code.
I'm asking myself some questions, i hope you can answer to one or maybe more ... :
- I've a MFC application, I want to use the dotnet framework by switching to /clr compilation mode and some code line like this :
StreamReader ^ sr = gcnew StreamReader("file.txt");
String ^ myText = sr->ReadToEnd();
Is my application in CLR, or only the call to the framework what is managed / unmanaged
- - I've a winforms application, compiling with /clr:pure , i'm calling such a function :
int add (int a, int b)= gcnew StreamReader("file.txt");
{
return a+b);
}
Is this functions moved to CLR too is this function managed / unmanaged - In addition, in this winform application with /clr:pure, i'm creating a class without the ref keyword, is this class unmanaged moved to clr anyway
- I'm creating a winforms application. I want to use a unmanaged class (without the ref keyword), between #pragma unmanaged and #pragma managed .
#pragma unmanaged
public class CMyClass
{
public:
CMyClass(void);
bool myFunction();
~CMyNetSend(void);
};
#pragma managed
- Is this class unmanaged Is it in the CLR Was it useful to use this pragma or would have been enough to only not use the ref keyword
Thanks a lot in advance for explaning me this better
Best regards,
What is managed, unmanaged ?
Daniele Balducci
Those two lines use an unmanaged type as well as an unmanaged API call. But in /clr compilation mode, the compiler would generate MSIL (instead of machine code).
So, even when you use non-CLI types, they still end up as MSIL.
But when you write code, you needn't think too much about the resulting code (in fact under certain cases, MSIL cannot be generated and the compiler generates machine code directly). You can think of non-CLI types as unmanaged classes.
Phil Clewes
Hi, Nicolas. I'll try to help clarify things. You ask about "Moving to CLR" a couple times: this doesn't make a lot of sense to me, but I'll try to help you get the right mental model about managed code. CLR is not a space where your apps live. CLR is the ability for your C++/CLI application to interact with the .NET runtime--letting it "manage" (garbage-collect) the memory of your objects in particular (and other things of course).
If you use the /clr (assume not pure) switch, your C++/CLI application can contain a mixture of managed and unmanaged classes and objects.
sr and myText are both managed objects by virtue of them being declared as handles to managed classes, StreamReader and String, respectively. You know that StreamReader is a managed class, because it comes from .NET framework (System::IO namespace).
You define your own managed class using ref class, as opposed to class. You must allocate managed classes using gcnew, and instances must be declared as handles (^). You must allocate unmanaged classes (on the heap) using new.
There is no such thing as a managed global function--the CLS (common language specification) is like Java in that everything in defined classes. Your add function is therefore unmanaged. (But you can pass managed objects to unmanaged functions using the gcroot template).
Your managed C++/CLI classes can contain members that are handles (^) to other managed objects (.NET components, for example), or they can contain pointers (*) to unmanaged objects, but they cannot contain unmanaged objects directly.
In your question about #pragma unmanaged, it's enough to just declare the C++ class the old way (don't use public, don't use ref). You would use #pragma unmanaged to tell the compiler to assume that the /clr switch is not in effect for certain sections of code. I'm sure interpretations of other C++ constructs differ between /clr and not /clr, but I cannot give you the detail now. I am betting that #pragma managed had more of a role in the "old clr syntax" (still supported), where there was more of an overlap between the managed and unmanaged C++ syntaxes (e.g. * could mean a pointer to an unmanaged object; this token ambiguity brought about a redesign of C++/CLI syntax in VS 2005.)
Glossary/Acronymn detoxification:
CLS: Common Language Specification. All .NET languages have compilers that generate code that use a common datatype for classes and data (see CTS), and follow certain rules so that it plays nice with the .NET Runtime. This allows objects written in one .NET language, e.g. Visual Basic.NET, to call objects written in another, e.g. C#.
CTS: Common Type System: a standardization of datatypes that allows .NET languages to share objects.
CLR: Common Language Runtime, or .NET runtime.
CLI: Common Language Infrastructure, used in the context of "C++/CLI" meaning "C++ with the ability to interact with the CLR.
Managed (object): referring to an object whose allocation and deallocation (garbage-collection) is carried out by the CLR. Microsoft marketing, with good intentions, tried to scrub the word "managed" from all .NET literature, i.e. "C++/CLI instead of Managed C++" but apparently forgot to give us a useful adjective, so the term stuck.
Unmanaged (object): in the case of C++, refers to an object whose allocation is done by the C-runtime (malloc).
Last but not least, .NET. I think the term came out of the need to market Microsoft products that were better integrated with the Web, but later became associated with the whole new infrastructure for designing applications (.NET Framework, .NET runtime, and Visual Studio.NET).
Brian
SOAC
This is much clearer for me now
Greetings,
Nicolas
wolfkrow
I was confused with the term of "manage class".
And I wasn't sure of what is "native" and what is managed by the CLR.
So, to resume,
CLR manage object that use the ref keyword
The other object are not managed, and are "native"
So, this fully win32 statement :
char *name;is managed if it's in a "ref" class and "native" if not.GetModuleFileName(NULL,name,MAX_PATH);
In fact, should i think about managed / unmanaged only for object or for statements too
Best,
Nicolas