Managed C++/C++.net

[oscargrower11]

I'm used to c++ along with an open database (switched from mysql to postgres not too awful long ago.) A new job I'm looking at taking focuses heavily on .net along with SQL Server. As such, I've been looking into the .net framework and what I can't seem to figure out is how to make sure I'm actually using it. From what I've gathered, C# and VB.net are both managed languages, and someone mentioned that there is a managed C++ that compiles first to Microsoft CLR.

Is using Visual C++ enough to ensure I use this "Managed C++." Does this mean I don't have to worry about destructors? Would using destructors have any effect at all? Seems it would make for more efficient code to destroy pointers and just keep the gc as a second set of eyes watching for memory leaks. My experience with managed code is pretty much nil.

Thanks in advance.

[Ancient Dragon]

When you create a new project with VC++ 2010 you have the option to create standard C++ or CLR/C++ (M$ doesn't call it "managed" any more, but CLR). See attached screen shot. With CLR/C++ you can call most, if not all, the same functions that can be called by C#.

I have not done extensive CLR/C++ programming either, just enough to get dangerous.

[mike_2000_17]

>>someone mentioned that there is a managed C++ that compiles first to Microsoft CLR.

That is called C++/CLI. It is not really C++, it is a completely different programming language if you ask me (it is a kind of a frankenstein between C++ and C#). But I know little about it. I think any .Net version of Microsoft IDE's for C++ will allow you to create a "C++/CLI" project. But it is different from a C++ project.

>>Is using Visual C++ enough to ensure I use this "Managed C++".

No, you have to specify when doing a new project that it is a Managed C++ or C++/CLI project. I'm not sure that just "Visual C++" has that option, you might need a "Visual Studio .NET" version.

>>Does this mean I don't have to worry about destructors?

Managed programming languages have either no destructors (like Java) or destructors that are useless. In pure C++, and using the RAII idiom, the destructors are not something to "worry about", they are something to use. Because C++ has automatic value-semantics, it has a predictable and reliable mechanism of construction / destruction of objects, and thus, you can make great use of destructors to manage your resource acquisition and release code to produce robust and effective code. In managed languages, you have to give up automatic value-semantics and replace it with reference-semantics (in order for garbage collection to work), and at the same time, you lose predictability and reliability of the object construction / destruction mechanisms, so you can no longer rely on that mechanism to achieve anything. So, in managed languages, you don't have to "worry about" the destructors but you cannot use them either, it's a double-edge sword. Basically, you get (almost) robust management of memory by the GC, but you lose robustness in just about every other aspect. The popularity of managed languages grew out of the inability of a majority of programmers to see construction / destruction mechanisms as one of the strongest and most robust tool for programming, and instead, see them as an annoyance and just another thing to "worry about". Many run-time environments, like .NET and Java's virtual machine, have chosen to do garbage collection because the majority of programmers are unreliable when it comes to managing memory correctly, it is certainly not because garbage collection is the best resource management strategy (it is just more "fool-proof", as in, robust to the presence of fools).

>>Would using destructors have any effect at all?

You cannot predict or rely on the time or context in which your destructors get called. So, I don't see how you can really, safely do much in a destructor in the context of a managed programming language, and that's why many of them don't even let you define a destructor at all (and that's a good thing).

>>Seems it would make for more efficient code to destroy pointers and just keep the gc as a second set of eyes watching for memory leaks.

The most effective and efficient strategy is to not use pointers at all (but this is not really possible in a managed context). Use dynamically allocated memory only under the wraps of a RAII class (like STL containers or smart-pointers). In this context, a GC is meaningless, and that's why C++ doesn't have one. As the saying goes: "C++ doesn't need garbage collection because good C++ programs don't produce any garbage". The kind of dual approach you are suggesting doesn't make much sense, either you robustly manage resources yourself using pure C++, or you let the garbage collector take care of memory management (but then you are stuck with no robust means to manage other kinds of resources). Explicitly destroying objects that are already being managed by the GC is not going to change anything, it's just wasting lines of code.

For more details on resource-management in C++, I suggest you read my tutorials on RAII and Memory-Management.

The real question is not whether to use managed code or not, it's whether to use .NET or not. .NET, like JVM, is a managed-memory run-time environment, it requires managed code to work. Anything you code that is not managed cannot be in .NET, and anything you code in .NET has to be managed. Of course, C++/CLI is a reasonable option because it allows you to write both managed C++ code (that works for .NET, CLR) and regular C++ code. But if you don't need to write any pure C++ code, then you could simply use C#.

[Ancient Dragon]

>>No, you have to specify when doing a new project that it is a Managed C++ or C++/CLI project. I'm not sure that just "Visual C++" has that option, you might need a "Visual Studio .NET" version.

See the screen shot I posted -- I used VC++ 2010 Express to generate it.