tags:

views:

892

answers:

14

I want to develop a windows application. If I use native C++ and MFC for user interface then the application will be very fast and tiny. But using MFC is very complicated. Also If I use C# then the application will be slower than the native code and It reqiures .NET framework to run. But developing GUI is very easy by using WinForm. Which one do you prefer?

+17  A: 

"fast" and "slow" are subjective, especially with today's PC's. I'm not saying deliberately make the thing slow, but there isn't nearly as much overhead in writing a managed application as you might think. The JIT etc work very well to make the code execute very fast. And you can also NGEN for extra start-up speed if you really need.

Actually, if you have time to learn it, you might want to consider WPF rather than winform - this is a different skill-set, but allows you to make very good use of graphics hardware etc.

Also - .NET framework comes with new OS installs, and is still very common on those that pre-date it. So for me it would be a fairly clear choice to develop with C#/.NET. The time to develop a robust and fully tested C++ app (with no leaks, etc) is (for me at least) much greater than the same with C#.

Marc Gravell
Yep, c#.net seems like a much more practical choice here.
Kon
I don't think "subjective slow" is determined by overhead anymore - but mostly by responsiveness of the UI.
peterchen
Making an app with no leaks is an easy thing.. If you structure.. I've not had a leak in years. That said.. I'd go with C# too.. Just a bigger market.
baash05
+1  A: 

C# applications are slower to start than MFC applications, but you might not notice a speed difference between the two once the application is loaded.

John D. Cook
That is true, but CLR 4 (.NET 4.0) should significantly improve the cold start time of a .NET application.
Scott Dorman
+5  A: 

Be careful not to optimize too early; you mention the speed of the code but for most Windows user interface operations, the difference is not noticeable as the main bottlenecks of drawing and disk access are no different for either approach.

My recommendation is that you use C# and WPF or WinForms for your user interface. If you encounter some slow downs, use a profiler to determine where and then consider replacing some business logic with native code, but only if there is a benefit.

Jeff Yates
+2  A: 

There are a great many possible Windows applications, and each has its own requirements.

If your application needs to be fast (and what I work on does), then native C++ is a good way to go.

If your application needs to be small (perhaps for really fast transmission over slow lines), then use whatever gets it small.

If your application is likely to be downloaded a lot, you probably want to be leery of later versions of .NET, which your users might not have yet.

If, like most, it will be fast and small enough anyway on the systems it's likely to be used on, use what will allow you to develop fastest and best.

In almost all cases, the right thing to optimize is developer effort. Use whatever gets a high-quality job done fastest and best.

David Thornley
+1  A: 

Having no information on the application you plan to develop, I vote for WPF.

mackenir
A: 

Choice of a language or tool should be dictated by the functional and performance requirements of your project and expertise. If performance is a real consideration for you and you have done some analysis to prefer C++ over C#, then you have a decision already. Note though that having MFC based application is not terribly efficient either. On the other hand, overheads in .NET applications are over-stated.

Performance is something that is really a function of how well you write your code and what scalability requirements exist. If you would only have to work with one client with a maximum database records of 1K, then we should not be talking performance.

If ease of development and maintainability is more important, certainly C# would be the choice.

So I am not sure this is a question that can be given an answer as choice A or B with the data you have provided. You need to do the analysis of functional and non-functional requirements and decide.

Ather
+2  A: 

Note also that most Windows computer already have .NET installed on them, so that really shouldn't be a concern.

Also, aside from the .NET installation, .NET applications tend to be quite small.

And for most application with a UI, the speed of the User is the really limiting time factor.

James Curran
+1  A: 

In my opinion, the requirements should help you decide the platform. What is more important: Having an application that is easily maintainable or one that must be extremely fast and small ?

A large class of applications nowadays can be written using .NET and managed code and this is in general beneficial to the development in the long term. From my experience, .NET applications are usually fast enough for most use cases and they are simpler to create. Native C++ still has its use, but just for being "faster and smaller", when "fast enough and small enough" is sufficient does not sound enough as a justification.

boxofrats
A: 

Also If I use C# then the application will be slower than the native code and It reqiures .NET framework to run

An MFC app requires MFC dll's to run (and probably VC runtime as well!), so they might need to be installed, or if they are statically linked, you add to the size of the exe.

crashmstr
+1  A: 

The speed argument between native and managed code is largely a non-issue at this point. Each release of the .NET Framework makes performance improvements over the previous ones and application performance is always a very high priority for the .NET development teams.

Starting with Windows Vista and Windows Server 2008, the .NET Framework is installed as part of the operating system. It is also part of Windows Update so almost any Windows XP system will also have it installed. If the requirement that the framework be installed on the target machine is really that much of a problem there are also compilers that will essentially embed the required runtime portions into your application to generate a single exe, but they are expensive (and in my opinion, not really worth the cost).

Scott Dorman
A: 

Blockquote

.NET is easier to work with. Unless you'll lose users by using it or will have trouble with code migration, you should probably use .NET. It is highly unlikely that speed will be an issue for this. Size probably doesn't matter that much, either.

Brian
+1  A: 

MFC isn't hard to learn, actually it is very easy.

Almost equal to C#.

plan9assembler
agreed.. I'd say as easy.. And even better you can get go deeper into things if you need to.
baash05
totally 100% disagree, every MFC project I've seen is a bloody mess. which does speak something to the tools, not just the developer.
Dustin Getz
A: 

Which technology are you more familiar with?

The information you gave does not include anything that would help decide. Yes, MFC apps tend to be smaller (if you include the runtime size which isn't a suitable measure in the long run), more responsive and mor costly to develop. So what?

peterchen
+1  A: 

First.. (though I'm a die hard c++ coder) I have to admit c# is in most cases perfectly fine where speed and size are concerned. In some cases the application is smaller, because the interpreted part is already on the target system. (don't spamm me on that one, an app with a dll is smaller then the app all in one. Windows just happens to ship with the "DLL" already there.)

As to coding.. I honestly don't think there is a significant difference. I don't spend alot of my time typing code. Most of it is thinking out a problem. The code part is quite small. Saving a few lines here and there.. Blahh it's not an argument for me.. If it were I'd be working in APL. Learning the STL, MFC and what have you is likely just as intensive as learning the c# libraries. In the end they're all the same.

C# does have one thing going for it.. A market. It's the latest "hot" skill and so theres a market for it. Jobs are easy to find. Now keep in mind java was a "hot" skill a few years back and now ever tom dick and harry has it on their resume. That makes it harder to niche yourself.

Ok.. all that said.. I LOVE C++.. There's nothing like getting dirty when I really need to. When the MFC libs don't do the job I take a look at what they're sitting on and so on and so on.. It's a perenial language and I belive it's still at or near the most used lang in the world. Yah c++, Yah!.

baash05