Difference Between Managed C++ and C++

What is the difference between Managed C++ and C++/CLI?

Managed C++ is the version in VS2002 and VS2003. It had race conditions and other serious bugs, as well as being confusing. It's no longer supported.

In VS2005, Microsoft introduced C++/CLI, which has also been accepted as an ISO standard. It's also supported in VS2008 and the upcoming VS2010.

Both of them had the same goal, which is to create .NET assemblies using the C++ language. The syntax is different (C++/CLI managed code is a lot easier to differentiate from standard C++ at a glance) and C++/CLI also has syntax for .NET 2.0 features such as generics.

Difference between managed C++ and C++

When not specified, C++ is unmanaged C++, compiled to machine code. In unmanaged C++ you must manage memory allocation manually.

Managed C++ is a language invented by Microsoft, that compiles to bytecode run by the .NET Framework. It uses mostly the same syntax as C++ (hence the name) but is compiled in the same way as C# or VB.NET; basically only the syntax changes, e.g. using '->' to point to a member of an object (instead of '.' in C#), using '::' for namespaces, etc.

Managed C++ was made to ease transition from classic C++ to the .NET Framework. It is not intended to be used to start new projects (C# is preferred).

What's the difference between managed C++ and C#?

Managed C++ and C++/CLI allow you to easily write managed code that interacts with native C++.

This is especially useful when migrating an existing system to .Net and when working in scientific contexts with calculations that must be run in C++.

What is the main difference between C++ vs C++.NET?

Is that right C++ is unmanaged code and C++.NET is managed code.

There's no such thing as "C++.NET". There's C++/CLI, which is basically C++ with Microsoft extensions that allow you to write code targeting the .NET framework. C++/CLI code compiles to CLR bytecode, and runs on a virtual machine just like C#. I'll assume you're actually talking about C++/CLI.

With respect to that, one can say standard C++ is unmanaged and C++/CLI is managed, but that's very much Microsoft terminology. You'll never see the term "unmanaged" used this way when talking about standard C++ unless in comparison with C++/CLI.

Both standard C++ and C++/CLI can be compiled by the same Visual C++ compiler. The former is the default on VC++ compilers, while a compiler switch is needed to make it compile in latter mode.

I need to program for a project in C++. For better building the GUI, I
would prefer to use C++.NET.

You can build GUI programs in C++ just as well as C++/CLI. It's just harder because there isn't a standard library in standard C++ for building GUI like the .NET framework has, but there are lots of projects out there like Qt and wxWidgets which provide a C++ GUI framework.

I also have another plain C++ library (unmanaged C++ dll), will it be
possible to use it as a normal dll library in the C++.NET project?

Yes. It might take some extra work to deal with the different standard C++ data types and .NET data types, but you can certainly make it work.

Understanding of Managed C++

It is a big topic with very gritty implementation details. Hard to address them all, but there are some misconceptions in the question. Let's address those, might help to get to next stage.

Moreover, how is it able to use .NET assemblies (which are CIL)?

Not just CIL, the linker produces a mixed-mode assembly. Contains both .NET metadata + msil and native code. In fact, as far as the OS loader is concerned, it is the native code in the executable file that is normal. No different from the kind produced by a native C++ compiler. It gets loaded and relocated just like a pure native executable image. It is the .NET metadata + msil that is the oddball. To the loader it just looks like a chunk of data, it doesn't touch it at all. Only the CLR does.

... use Standard C++ code (which isn't compiled to CIL)

Not quite accurate, native C++ code can be compiled to msil or machine code. What you get depends on whether the /clr compile option was used or the #pragma managed that was in effect at the function level. CIL does not compare that well to, say, the bytecode used in the Java JVM. It is more powerful and can support any C++03 compliant native C++ code. Sometimes you do this on purpose to take advantage of reverse pinvoke (native code calling managed code). Sometimes it is done by accident and entirely too much native C++ code gets compiled to msil. The machine code produced by the jitter is not as optimal (it optimizes under time constraints) and is not managed in any way. It is not verifiable and doesn't get garbage collector love.

Best mental image for CIL is as the Intermediate Representation that is used in any native C++ compiler between the front-end (parser) and the back-end (code-generator and optimizer). Often an invisible implementation detail but gets more visible when you use a C++ compiler that uses LLVM (like Clang does). The .NET just-in-time compiler does at runtime what LLVM does at compile time.

Most programmers have the mental image of a giant mode switch being thrown when managed code calls native code (or the other way around). That is not accurate at all. You might want to take a look at this post, shows the difference between machine code produced by the C++ compiler's back-end and the jitter. Key is it is almost identical, an essential feature to ensure managed code is competitive with native code. Helps to clarify how managed code calling native code, or the other way around, is not that special.

Another misconception is that managed code is automatically safer. Not quite true, a language like C# lets you party with pointers and scribble around on the stack just like you can with C++ and you can corrupt memory just as easily that way. It is just partitioned better, it forces you to be explicit about it with the unsafe keyword. No such constraints on C++/CLI, anything goes.

The essential difference between managed and native code is a data structure that the jitter generates when it compiles msil. Extra data you don't get from a native compiler. That data is required by the garbage collector, it tells it how to find object roots back. More about that data in this post. Having to conform to that data and allowing the GC to get its job done is what makes managed code a bit slower at runtime.

What is the difference between Visual C++ and C++?

Visual C++ can be many things, including:

Microsoft's C++ compiler (cl.exe, link.exe etc)
The IDE (Visual Studio in C++ mode)
The C runtime (MSVCRT)
Other libraries (less so): MFC, ATL

As for compiling old C++ code: Visual Studio is now a fairly compliant C++ compiler. This was not always the case, such as with Visual C++ 6 or earlier. It is likely your code is not standards compliant or uses deprecated behavior, which simply doesn't work on newer compilers.

Note: this paragraph is outdated: Visual C++ is unfortunately a poor C compiler, as it does not support C99 (and never will), unless features overlap between C++ and C99. The most notable issue for many people is the lack of stdint.h.

Visual C++ supports C11 and C17 starting with Visual Studio 2019 version 16.8 Preview 3

For many years Visual Studio has only supported C to the extent of it
being required for C++. Things are about to change now that a
conformant token-based preprocessor has been added to the compiler.
With the advent of two new compiler switches, /std:c11 and /std:c17,
we are officially supporting the latest ISO C language standards.

What are the advantages of C++/CLI (formerly Managed C++) over standard C++?

One thing I haven't seen mentioned in the answers yet (probably because it's more of a disadvantage, but it's a relevant consideration) is that C++/CLI tends to get second-class treatment. Microsoft used to push it as pretty much a replacement for C++. they wanted native developers to switch to .NET, and the way to do that was to write C++/CLI instead of C++.

Now, they've abandoned this, and C++/CLI is relegated to a role as an interop language. Microsoft recommends that you use it when you need to mix native C++ and .NET code, you may use C++/CLI as a "bridge" between them, while C++ is once again a first-class language.

C++/CLI has also fallen behind in certain ways:

In Visual Studio 2010, Intellisense no longer worked for C++/CLI. It will be reenabled at some point, but for now, it's gone.
VS2010 adds support for parts of C++0x, while, as far as I know, not all of it works with C++/CLI yet. Again, the assumption is that Microsoft keeps the two languages in sync, but there can be delays when new features are added to the C++ language, before they're made available in C++/CLI.

So if you want to write .NET code, use a "real" .NET language such as C#.
If you want to write C++, use the "real" native C++.
And if you want to mix the two, use C++/CLI to write the interop code.

What are the differences between memory management in C and C++

To allocate the array, you would do something like this:

const char **array = malloc( x * sizeof( char * ) );

Then allocate each element of the array.

if ( array )
    for ( int i = 0; i < x; ++i )
        array[i] = malloc( y * sizeof( char ) );
else
    printf( "malloc failed :(" );

malloc returns a void* but it's compatible with other pointer types.

In both C and C++ you need to manage the memory yourself, but C does not have things like unique_ptr -- also, no new and delete, use malloc and free. There's also calloc and realloc.

malloc can return NULL in the case when it fails, so you should check for that too. Note that it doesn't throw like new can in C++. More information on malloc can be found here.

As requested, when freeing up the array, you basically just do the same thing in reverse. Noting that free does not take in a size, just the pointer. The free function will ignore NULL pointers, so you don't have to worry about that here.

for ( int i = 0; i < x; ++i )
   free( array[i] );
free( array );

Of course, as in C++, don't double free memory. That is bad. :)

What is the difference between managed and unmanaged DLL

The term "managed code" usually refers to code written in a managed language, such as Java or C#. The term "unmanaged code" usually refers to code written in an unmanaged language, such as C or C++. If you're coming from the .NET world, "managed" probably means C# or VB.NET, and "unmanaged" probably means C or C++.

Difference between managed and unmanaged

Managed Code

Managed code is what Visual Basic .NET and C# compilers create. It runs on the CLR (Common Language Runtime), which, among other things, offers services like garbage collection, run-time type checking, and reference checking. So, think of it as, "My code is managed by the CLR."

Visual Basic and C# can only produce managed code, so, if you're writing an application in one of those languages you are writing an application managed by the CLR. If you are writing an application in Visual C++ .NET you can produce managed code if you like, but it's optional.

Unmanaged Code

Unmanaged code compiles straight to machine code. So, by that definition all code compiled by traditional C/C++ compilers is 'unmanaged code'. Also, since it compiles to machine code and not an intermediate language it is non-portable.

No free memory management or anything else the CLR provides.

Since you cannot create unmanaged code with Visual Basic or C#, in Visual Studio all unmanaged code is written in C/C++.

Mixing the two

Since Visual C++ can be compiled to either managed or unmanaged code it is possible to mix the two in the same application. This blurs the line between the two and complicates the definition, but it's worth mentioning just so you know that you can still have memory leaks if, for example, you're using a third party library with some badly written unmanaged code.

Here's an example I found by googling:

#using <mscorlib.dll>
using namespace System;

#include "stdio.h"

void ManagedFunction()
{
    printf("Hello, I'm managed in this section\n");
}

#pragma unmanaged
UnmanagedFunction()
{
    printf("Hello, I am unmanaged through the wonder of IJW!\n");
    ManagedFunction();
}

#pragma managed
int main()
{
    UnmanagedFunction();
    return 0;
}