does c# code automatically get managed by .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. I know VB.net is one option, but I loathe VB and would prefer to do my coding in C#, if not C++ (though judging by the interviews, they lean more toward C#). I'm really stuck, though, as to how to actually implement it. Does C# automagically compile via Microsoft Intermediate Language? Does Visual Studio automagically go through Microsoft Intermediate Language regardless of whether I use C++, C# or VB? Do I just have to make sure I #include .net libraries?

[Momerath]

C# and VB.NET are managed languages (and there is a version of managed C++). This means they all compile to an Intermediate Language. At runtime this IL is compiled using a Just-In-Time compiler (just like Java is) and run.

In C# you don't use 'includes', the compiler makes use of 'references' and copies the needed code as required. You can consider these references like you would an external DLL in C++ (and most of the time they *are* external DLLs) that is linked at runtime.

The biggest difference you'll encounter is that you don't need to worry about memory management. C# will handle that for you (in most cases).

[oscargrower11]

C# and VB.NET are managed languages (and there is a version of managed C++)

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.

[Momerath]

No, you need to let the system know you want a managed C++ project. If you are using Visual Studio, you'd use one of the CLR C++ base projects (CLR = Common Language Runtime).

My experience with managed C++ is close to yours. I'm not sure how it handles destructors exactly, but from what I've read all they really do is mark the object as unreferenced so the GC can clean it up later, the same thing that happens if you just let them go out of scope or when they are no longer referenced. The main purpose of a destructor would be to handle unmanaged resources (the same thing that C# uses the IDisposible interface for, and the Dispose() method). In fact, creating a destructor in managed C++ forces the system to implement IDisposible for that class!

If I were just starting out with managed C++, I'd just write code like it was unmanaged C++. I'm fairly sure you won't break anything this way and you can spend more time developing rather than worrying about the differences. I'm sure you'll learn them over time and also figure out what you don't need to do anymore because of the managed objects.