managed vs unmanaged

If you mean managed vs. unmanaged C++... you will gain the garbage collector... but you'll also gain(?) some really funky syntax.

You'll probably be fine with unmanaged C++.

In my experience, the only reason I'd use Managed C++ rather than regular C++ is when I wanted to make a GUI app and also wanted to avoid using MFC, or if I wanted to make a managed wrapper out of existing C++ code so that I could use it in C#.

Unless you plan on bridging with a .NET application, or really have difficutly with cleanup, C++ is a better route to go for game programming. The benefits of MC++ are really aimed towards business applications.

it feels weird not deleting stuff in C++...

Oh, see the thread I hate virtual machines for more information.

Try C#, and see what you think. Either way, you will know a new language and also be better qualified to make this decision for yourself.

Working with Managed DirectX has been interesting. It can definately be quirky, and the documentation and help resources are still being developed (like a first wave of adopters that can sort through the issues and help). But for the most part, working with Managed DirectX is very very simlar to Unmanaged DirectX.

The benifits of workign with Managed code have been coming from the actual construction of the game. Working with Garbage Collection certainly makes life easier, and the very extensive framework also helps out. One thing I am really taking advantage of is the ability to load assemblies (think libraries) at runtime to very easily make my game use plug-ins. It is becoming very extensible, and it isn't taking extra work either.

Quote:

Original post by necreia MC++ are really aimed towards business applications.

Why would someone making a business application choose to use Managed C++ instead of C#, unless for something like interoperability with old code?

Quote:

Why would someone making a business application choose to use Managed C++ instead of C#, unless for something like interoperability with old code?

That's pretty much the only reason.

Quote:

Original post by Nypyren Quote: Why would someone making a business application choose to use Managed C++ instead of C#, unless for something like interoperability with old code? That's pretty much the only reason.

Exactly...

Here's an example: Our company right now is using a C++ library for a datalayer (we acquired a SDK, but it was only available in java and C++), while the rest of our software is written in C#. Using MC++, we will be able to expose the C++ to our .NET for integration.

It's a pretty nice thing to be able to do, I will admit.

Thanks for all your replies. Sorry I couldn't reply sooner; needed some sleep.
Glad to say I'm staying with unmanaged c++. And yes, I've tried using c#. It's ok, but not THAT much different than c++.

Glad to here from the community,
ProgrammingNerd

I highly recommened you go more indepth into C#. managed C++ is there, as mentioned, to provide a layer to interact with unmanaged code beyond Interop, and thats all it should be treated as. It should never be a primary development language.

Quote:

Original post by ProgrammingNerd And yes, I've tried using c#. It's ok, but not THAT much different than c++.

It's very different.

My feelings on C# / .NET (which is now my primary development platform)

First of all, this always starts arguements, but speed wise .NET can be anywhere from half way between the speed of a release and debug C++ app, too twice as fast again. Thats the first thing to remember, it's very fast, and any difference really is irrelivant and comes down to how it's written. Also remember it will automatically take advantage of newer tech due to the JIT compiler. So when we all eventually move away from x86, your program will run nativly and very fast, taking advantage of all the new hardware, where old C++ apps will be being emulated. Just something to think about. [wink]
Get that out the way first.

Sytax wise, C# is not that different from C++, and visually it can almost be mistaken for C++, and if you use usafe code blocks (grrrrr!!!) then you are basically 90% there, It's a much faster language to write in than C++, *however* it's when your project starts to expand that C# and .net will really come into their own. There are far too many things to list that simply make your code more reliable, and easier to maintain, but here are some of the ones that come to mind:

The obvious one is the garbage collector, not having to do low level memory managment is a wonderful thing in a large project, especially comming from C++. The time when this really also excells is when using multi threading. Doing multithreaded memory managment can have some really tough problems to work through, and of course the .net memory manager is far more efficient than the C++ heap when it comes to most types of frequent allocations.

Of course there are other things like having a very well documented, extremly extensive, heavily error checked and very logically built API (ie the .net framework), where the documentation is not only huge but also integrated into the languages and the IDE like intellisense. You basically don't need to hit F1 anymore.

One of the things, however, that I like the most about .net and C# in perticular, is that it is *extremly* strict. C++ is not, and C far less again. In C# you won't generally get anything done for you implicitly unless it's guarenteed to not have a potential side effect. Ie, value type casting almost always has to be explicit, even to the extent that if a value overflows and wraps from it's highest to lowest value it will thrown an exception (unless you put it in an 'unchecked' block), and my favorite, if your .exe/.dll are linked to another .dll, the link will be based on exact version number, so no more crashes due to newer/older dlls, it's the cumulative effect of everything being very strict that ends up making errors much easier to track down, and improving reliability. And don't even get me started on linker errors in C++ and things like header files, undefined symbols, exe size, etc.

So please don't evaulate it from what it looks like compared to C++, the visual and style differences are designed to be as superficial as possible, it's the in depth differences that completly and utterly change everything.

The advantages of C++ are of course there is a potential speed improvment (although in the real world it's often not the case), and if you like lower level access to how things work, then yeah it's for you. And there are obviously already 1000s apon 1000s of code lirbraries out there already. Some would also say portability, but I persoanlly feel this is less so, as you have to recompile, and replace platform dependant code.

I realise that half of what I've said (or more [smile]) doesn't really matter for a small project, in fact some are completly irrilevant, but I still feel they are important. Just remember, all projects start small. [wink]

The one thing I'll mention is that if you are using managed directX in a .net language, in visual studio, the debug window will not show debug information from the directX api (as it's unmanaged debug info, or whatnot), so you will need to use a 3rd party progam to get this debug info, such as this.

I only looked at c# as an alternative to unmanaged directx c++. From that perspective, it isn't that different, being I wasn't using the .net framework not that much.

Thanks for your responce,
ProgrammingNerd

PS. I might take a better look if I start developing apps other that directx apps.

Quote:

Original post by RipTorn The one thing I'll mention is that if you are using managed directX in a .net language, in visual studio, the debug window will not show debug information from the directX api (as it's unmanaged debug info, or whatnot), so you will need to use a 3rd party progam to get this debug info, such as this.

Not necessarily true, you can enable unmnanaged debugging output in the project properties->Debugging->Enable Unmanaged Debugging and setting that to TRUE. However, I've found that this slows my apps down terribly. You can also use dbmon.exe which comes with Visual Studio (\Common7\Tools\Bin\winnt\dbmon.exe)

I'm liking C# a lot. I've programmed a number of small apps in C++ and a few games in SDL but the main advantage I'm seeing with C# and SdlDotNet is it's EXCELLENT wrapper over several SDL libraries. I'm still waiting to see some good OpenGL support but if worse comes to worse, I'll just move back to C++, or maybe Managed DirectX would be a good thing to try? As stated above, C# is VERY similar to C++ and each puts you in a different state of mind when programming.

C# is great for hobbiests because our time is extremely critical, and it's even better for beginniners because they don't have much of a code-base built up in another language. No, C# is not the industry standard (which has nothing to do with its abilities as a language), but 90% of the programming practice you get in C# can be applied to any coding you do in C++ in the future (vice-versa is also true). And once you pick up one language, the other will come much more naturally.

I started with C++, then tried out C# a couple years ago and haven't gone back.

Quote:

Original post by ProgrammingNerd And yes, I've tried using c#. It's ok, but not THAT much different than c++.

Then you've only skimmed the surface. Learn the more advanced features, C# has a lot to offer.