Well actually I was surfing the forums when suddenly I read this sort of stuffs... Umm..to make the story short,can you please tell me the difference between this terms or maybe just define to me what they really are: 1.MFC 2.C++\CLI 3.Managed/unmanaged (c++ or directx) 4.native codes 5.wrapper(is this just the use of oop to hide implementations) 6.JIT well thats as far as is can remember...i'll post again if i find more terms that i dont understand thanks for the help!

1. A C++ GUI framework developed by Microsoft. Windows-only, fairly popular, but only available with Standard editions of Visual Studio and up.

2. C++ running on the Common Language Infrastructure - .NET.

3. Managed C++ is the precursor to C++/CLI and generally is not recommended for use in light of the latter's improvements.

4. Code compiled directly for a processor and not an intermediary such as the CLI.

5. Implementation hiding, generally, yes.

6. A compiler for an intermediate form (such as the CLI) into native processor code, generally giving a large performance speedup over a purely interpreted version.

Yes, Wikipedia is your friend. In fact, I was just reading up on C++/CLI there earlier today.

1. MFC
2. C++/CLI
6. JIT

5. a wrapper is a way of changing an interface. say you have a library written in C. It isn't object oriented at all. You want to use it in an object oriented way so you write classes that use the underlying library to make it appear object oriented.


The term is also used when talking about making a library available in a new language. If you want to use opengl in python you need an opengl wrapper.

@Mike.Popoloski actually i googled this before i make this thread i've also read the things about my question in wikipedia,im not that kind of person that just creates thread you know...

@niteice can you expand your explanation about 2,3,4 if possible some examples regarding on its difference to the other

I think of 'managed' as meaning 'managed' by the the clr runtime (ie offering memory management services [garbage collection] and whatever else goes on). likewise 'managed code' is code that can only run in a 'managed environment' - the clr runtime.

'native' is the opposite of 'managed'. 'native code' runs straight on the cpu and you have to manage your own memory.

The normal c++ that we traditionally know is native or generates native code (ie we get compilers that target the cpu) and so there has never been a need for these distinctions. microsoft with their new (NET) technologies have introduced variations or extensions (and in some case limitations) to the c++ language that allow it to generate 'managed code'. ie some things are sufficiently different that they are judged to warrant changes in the language (or at least microsoft's implmentation of c++).

The first iteration of this stuff was called MC++ or 'managed extensions' for c++. this was really clunky and tried to make some stuff which wasnt c++ look like c++ to ease transition for programmers. The next iteration with vs2005/08 is CLI or c++/CLI. So the relationship of c++/CLI with MC++ is that it replaces it - but both can be considered to do the same job and merely enable the programmer to write managed code from a c++ style lanaguage or interop between managed and native.

one example of the difference between mc++ and c++/cli --> MC++ used the '*' operator so as to appear to be the same as normal c++ pointer syntax, while c++/cli uses '^' which has no equivalent in c++ to indicate references to manged objects.

sorry i am a bit tired so dont think am expressing myself very well. anyway it took me forever to work out these distinctions as well - so i hope it helps.

tnx for the clarification chairthrower (although some is still confusing)

Quote:Original post by Skeezix
@Mike.Popoloski actually i googled this before i make this thread i've also read the things about my question in wikipedia,im not that kind of person that just creates thread you know...

Then ask us to elaborate on what you don't understand about what you've read, rather than ask us to just regurgitate the same damn thing. You'd agree it'd be a waste of both our times if we ended up giving you the same answers as you already read, yes? On that note, I recommend reading this wonderful article which I've read time and time again myself.