So, while equivalent code might run slower in certain cases when unmanaged, a programmer writing for an unmanaged environment would probably be going about things in a different way than one writing for a managed environment. I definitely agree that, even in situations when managed code can be written to efficiently accomplish a task, unmanaged code has more raw potential for speed than managed (though I think this difference is often exaggerated). Put the needed development time into an unmanaged app and you will be able to make it faster than a managed one that performs the same task. Many times the development time needed to surpass managed code's speed will be non-existent or negligible, but in some cases a managed environment may lend itself well to an application, requiring a little more work to get an unmanaged counterpart running faster.
That kinda depends on the experience of the dev. Even though it's native, I can write a class that takes care of freeing memory when not needing anymore (with far less overhead than the managed approach since it silently executes a thread on its own, checking pointers and freeing them when no longer needed, and moving memory around, etc).
If you're fluent on GUI (comes with experience too), then you'll probably not spend so much time on that either. In this case, you'll probably be stuck on advanced stuff such as making your app multi-threaded or progress or other little convienience, but hard stuff. Which takes equal amount of time in both langauges, I might add (I would know, since I have experience in both).
Anyway, if you haven't ever tried using C# or one of it's brethren, I'd suggest you try it out sometime. You might hate it, but you might not too. It's framework may decrease performance by a couple percent in average situations, but it also makes GUIs and even things like games much less of a headache to write, at least IMHO. (Still not a good choice for emulators though.
)
I've tried C#, C++ .NET and every time I've been turned off. Sure, it may be pretty GUI, but MFC 2008 fixes that anyway. Sure, it may have a huge library of things at your fingertips, but if you're experienced, you probably have a common code library lying around somewhere with lots of code for common tasks anyway, so that makes that point moot.
There are many variables in this question: the experience of the coder, the efficiency of the coder and the knowledge of the coder. With experience, you can write code faster and better since you know how it works, requiring less dev time. With efficiency comes speed. If you're a native dev, then you probably make efficient apps mostly. In managed evironments, where you can just allocate, forget and so on, you usually turn sloppy, reducing performance of your apps (*cough* ATI control panel *cough*).
And lastl there's knowledge - how much you know of the .NET Framework or Windows API or the STL - with such knowledge, you have to spend less time on finding what you need and build a code base.
We can say one thing for sure - Native apps, if written efficiently, will
always be faster than managed (*cough* emulators *cough*) due to the overhead of managed. But in real-time apps, speed can vary due to the factors above, so we may or may not see faster native apps.
For me, however, native is the only way to go and I will
never give up native for managed crap.
That's just IMO though.
