tags:

views:

287

answers:

2

Let's suppose you're an IT student with a basic knowledge of C++ and C#. Let's suppose that you want to design apps that:

  1. need to deliver some performance like archivers, cryptographic algorithms, codecs
  2. make use of some system calls
  3. have a gui

and you want to learn an Api that will enable you to write apps like those described earlier and:

  1. is mainstream
  2. is future proof
  3. entitles you to find a decent job
  4. is easy enough - I mean easy like VCL, not easy like winapi

So, making these assumptions, what Api will you choose? MFC, WPF, other? I really like VCL and QT, but they're not mainstream and I think few employers will want you to write apps in QT or Visual C++ Builder...

Thanks for answers.

+5  A: 

If you enjoy coding in C# and working with the .Net framework I'd recommend that you have a look at WPF. WPF is a great GUI framework where you can do just about anything - and also make it shine! WinForms might be easier to get a grasp on, but I'd say WPF is more "future proof". Another positive thing is that WPF is really similar to Silverlight, so if you handle WPF well you should be able to write Silverlight applications too - if that's of interest. Please don't bother to learn MFC.. I can't believe there are many that is using MFC today for other reasons than that they were using it before, and didn't get an opportunity to change..

There are a lot of good jobs out there for .Net programmers, so being able to handle some GUI framework in addition to C# and general knowledge about the .Net framework will be worthwhile.

When it comes to your points about being able to "deliver some performance like archivers, cryptographic algorithms, codecs" this really shouldn't depend on your choice of GUI framework. This kind of code will be writen in layers outside of the GUI layer, and will typically be bound to the GUI. With WPF you'd write your e.g. cryptographic algorithms in C# in some class independent of the GUI layer, and then the View written in WPF would bind to C# code and get its answer from here. However, if you used WinForms you'd still do the same thing, and the performance relies on the algorithms - not the GUI.

When it comes to getting started with WPF there are a lot of questions on SO helping with this. So you should find good help with a quick search.

Good luck!

stiank81
Well, thanks for the answer. WPF seems nice. But I don't understand "This kind of code will be writen in layers outside of the GUI layer, and will typically be bound to the GUI." part. You mean I write the GUI using WPF separately and the code using raw CPU power separately and somehow magically link them together? This implies using unmanaged C++ and interops?
Mack
No unmanaged C++, no interops - unless you want to. No magic really. Consider that you write a class in C# handling your heavy algorithms. Now you can write a console application displaying the result - or you could write a WPF application. The performance depends on the class library handling your algorithms - not the GUI showing the result. Performance on the GUI is mostly relevant when it comes to animations and fancy GUI stuff, and this is handled very well in WPF.
stiank81
Thanks. I will choose C# + WPF path. Both are nice enough, new technologies and all. I wasn't just sure if C# can deliver enough performance when it comes to desktop programs.
Mack
C# can truly deliver great performance. And if you have some extremely time critical sections where it isn't good enough you can write these parts in another language and host this as unmanaged code in your C# application. Good luck!
stiank81
+1 for "deliver some performance like archivers, cryptographic algorithms, codecs" shouldn't depend on your choice of GUI framework
fretje
+4  A: 
  • Win32 API -- I'd forget about it, if I were you. Programming a Windows application directly via the Win32 API only makes sense if you're programming in pure C, or if you really need to do a lot of system calls, or if you're concerned about the additional overhead introduced by more "comfortable" platforms or frameworks (such as the ones named below). Programming UIs directly through the Win32 API is tiresome, messy, and you need to deal with lots of details. It's also not platform-independent at all, but you may or may not be concerned about that.

  • MFC -- Perhaps an option if you're programming in C++ and fixed on the Windows platform. I never understood what's so great about it, other than it makes the Win32 API much more comfortable (AFAIK it's basically a collection of object-oriented wrappers around the Win32 API that take away some of it's complexity / messyness). Also, it's also not very platform-independent.

  • Qt, wxWidgets -- Fairly widespread UI frameworks. Might be good options where platform independence plays a role. AFAIK both frameworks are targeted at the C++ language.

  • WinForms (.NET) -- Similar to MFC, this is also based on the Win32 API (USER32 and GDI+). AFAIK the WinForms framework is now being ported to Mono, and therefore somewhat cross-platform. However, it's not exactly the most up-to-date technology. For complex UIs it can also be somewhat sluggish sometimes. If I had to decide today which framework to use, I'd rather choose...:

  • WPF (.NET) -- More modern than WinForms, with more graphical capabilities and, apparently, faster rendering, as it is no longer based on the Win32 API (GDI). (And it runs on .NET, which I find a great platform to develop for. Programming in C# is so much easier than programming in C++ IMHO, which is also an argument against Win32 API, MFC, Qt, and wxWidgets.)

  • Then of course there's Java, including the UI frameworks that come with it. I can't say much about that since I'm not a Java person, but I could imagine that Java would be the best choice for platform independence; and it's the dominant platform (over .NET) in certain industries (e.g. mobile phones, banking, due to the very solid JVM and security considerations).

So my recommendation would be the .NET framework, and WPF for the UI, if you're planning to stay mostly in the Microsoft world. Remember that you can still use the Win32 API (you won't come closer to "system calls" than that) via P/Invoke.

stakx
My only question would be: I use WPF and .net, how I will be able to implement code that makes use of some heavy arithmetic, make use of sheer CPU muscle? Like it's possible to implement a file archiver using .net? Maybe WPF GUI + C++ interops?
Mack
Well, I'm sure there's more than one way to do this. You could, e.g. **(1)** write your heavy-duty stuff in C and compile it into a .DLL, and then access the functions inside the DLL via .NET's interop capabilities. Or **(2)** write a COM component (which is basically the same as option 1, but object-oriented). .NET and COM interoperate together fairly well. **But**, before you do all that: it might be a good idea to see if interop is necessary at all, or whether your heavy-duty operations perform well enough when written in your favourite .NET language.
stakx
@Mack - I'd check-out C# and do some tests to see how fast it runs for your purposes. Of course there is some overhead in a managed language, but unless you're *really* stressing the CPU (to the point where a few percentage performance difference means a lot), you might not really notice .NET being that much slower. Of course it depends on what you're planning to do with it...
Fara
Thanks all. You have given enogh pointers to start-up. So, you are saying that if I choose WPF for the GUI, I can write the rest of the code in C# and have enough performance. I will try that.All in one, a nice, helpful, community here at Stack Overflow. And more than all, filled with answers. I'm very happy I discovered it and I'll do my best to contribute back if I can.
Mack
That's a strange thing, which I don't understand. I ran few quick benchmarks and I've learned that C# is actually faster then c++ in some cases.The testing is here: http://stackoverflow.com/questions/2496803/c-and-c-speed-compared
Mack
Actually, after redoing the tests it seems that C# is well behind C++ in terms of speed.
Mack