Choosing between WPF/C# and Qt/C++ [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

Me and my team are developing an application, which involves a back-end written in C++ and involves use of libraries such as OpenCV, MIL, etc.

Now, we need to develop a GUI to interface with this program, such that the GUI displays the images, and the user can interact with the images and annotate / mark the images, and then run the image processing algorithms written in C++ to display results.

For the GUI, i am stuck choosing between WPF and Qt I personally find WPF to be easier, and more powerful than Qt I understand that WPF is not portable to Linux, but i am not worried about this too much... Also, WPF uses the DirectX technology, which i may have to use to generate some 3-D visualization at a later stage.

Please help me with these points :

Can I interface WPF directly with C++ (and not with Visual C# ??)
If (Point 1) is not possible, then consider this : The code in C++ is going to be big, and involving some libraries too, so can i use C# to call C++ functions Would the time invested in learning Qt be lesser than making my unmanaged non-OO C++ code work with WPF ?

(i have a sinking feeli开发者_运维知识库ng that I'd have to write too much code for interfacing C++ with WPF, which may equal rewriting half of the actual program itself... :-( )

I've used both Qt with C++ and WPF. I much prefer WPF as a User Interface framework. Qt isn't bad, especially post 4.0. I wouldn't even touch earlier versions of Qt.

As others have said in comments, WPF is better documented, and the online community is larger. If you are looking at styled applications WPF is certainly the way to go. Qt's Declarative language which is new is a good step along that road, but because it's so new it tends to be a bit buggy. WPF has been around longer, and is more mature and richer in features.

However, I think the real issue in your case is the c++ code base that you have.

WPF will require a C++/CLI layer (managed C++) in order to interface properly with your c++ code base. This sounds complicated, and does require a little bit of work, but it is not as crazy as it might sound. And there is tons of documentation about this as well. Personally I would stay away from PInvoke.

Qt is a little easier because it is c++ based, but you will have some translation to do between c++ native types, and Qt types (like QString, QList etc...) that are used internally.

Another thing to consider is what look-and feel you would like for your UI. For example if you were thinking about a nice Ribbon (office 2008, 2010) look, then you will not get this with Qt. Also, there are a ton of third-party WPF controls, but I haven't found very many for Qt. In some cases it is very handy to buy a nice set of controls to supplement the ones Microsoft gives by default.

Over the past couple of years where we don't have a requirement to have a linux UI we have been using WPF, regardless of the code base. We haven't regretted it yet.

However, I will also suggest a third option. Code-jock is a UI framework that is based on MFC I believe. It is c++ and ActiveX based. It has become quite sophisticated. Check it out here.

EDIT: QML has come a long way since I first looked at it. I haven't had the time to look at it in depth, but from what I hear it offers some very interesting features. It is worth an extra look.

Also, as a few comments have indicated, there are more Office-like controls such as a ribbon, and also some diagram and graphing controls that have added to the Qt toolset. These do make Qt an interesting prospect.

I will stand by something I said earlier though, that as a programmer I find making UIs with WPF a whole lot easier, and I am more pleased with my results than anything that I have ever coded with Qt.

If it's C++, stick to Qt. 3D part of your project can be handled by Qt's OpenGL widget. Choosing WPF path will force you to do some parts in either C# or VB.net (always bad practice). There isn't much advantage in using WPF with C++. Besides, the rest of your code is C/C++. suits your needs. OpenCV, MIL etc are somewhat easier to integrate with Qt rather than making P/Invoke calls with WPF (which will also cause delays due to .Net marshalling).

I'd say you should stick with Qt if you have a big C++ codebase already. WPF is not as awesome and not as easy to develop as they say. C++ and Qt is a well-known team, plain C++ (not .NET) with WPF is not.

WPF is UI framework and not programming language. You can write WPF application in C# or VB .NET. To use native C++ code from .NET application, you have two options:

PInvoke - allows to call plain C API from native libraries. PInvoke cannot work with C++ classes, only functions. It works by the same way as API calls in VB6.
Using C++/CLI wrapper, you can write .NET Dll which can be used by C#/VB .NET clients. Internally, this Dll uses native C/C++ libraries.

If you feel comfortable with WPF, and don't need cross-platform solution, you can use it. You need to learn interoperability part. C++/CLI is quite complicated language, but programmer who knows both native C++ and .NET can learn it.

On the other side, Qt allows to use any existing C/C++ code directly, and gives cross-platform solution.

Last couple years I have been using SWIG to make pure (unmanaged) C++ DLL's available in WPF applications. It works great, no problems at all, and this is for big applications such as avionics maintenance trainer.

SWIG is great because with one set of interface files (which you write based on your .h header files, so quite easy), you can generate all the scaffolding code to export your C++ DLL to multiple languages such as C#, Python, Lua, Java. SWIG generates the code you need if you want to extend a C++ class from C# or Lua, it handles passing exceptions across languages (so a Lua script could throw an exception that trickle through the C++ layer and get caught at the C# level, for instance), etc. We never have to touch PInvoke (SWIG does it all). It's amazing.

This way, the same SWIG interface allowed us to use WPF (C#, with .NET 4) for the GUI, a native C++ backend (via SWIG) for some existing libraries we had to integrate with, and embed a Lua interpreter to support scripting of the application (via SWIG, same .i interface files, and lua-icxx on sourceforge to simplify interfacing with Lua C API interpreter stack).

I'm wondering how Qt/QML compares to WPF/XAML now, 2 years after this thread started. And I see there is now Qt3D to add builtin 3D as has been available in WPF for a while now (supports 3D canvas natively, without OpenGL or DirectX).

Your WPF code will need to be in C# or VB to get designer and tooling support. Interop between C# and C++ is very good via the use of mixed mode assemblies, which allow you to code a module in C++ that compiles to a mix of managed and unmanaged code. This gives you type-safe interop to your native C++ libraries.

See here for information on mixed mode assemblies. We can vouch for them.

One important consideration IMO is the WPF learning curve. If you can bring your team with you I believe it can be extremely productive.

In the WPF scenario, you would not be interfacing directly from WPF (i.e. xaml views) directly to your unmanaged C++. You would always want to wrap your C++ modules some sort of VB or C# managed wrapper. (You could theoretically use a Managed C++ wrapper, but you'd be mad to do this.) WPF needs thin View Models written in a .NET language at the very least. WPF shouldn't have any access directly to your unmanaged code, so the question is more "can .NET apps interface with unmanaged C++?" and the answer is yes, certainly.

http://msdn.microsoft.com/en-us/library/aa984739(v=VS.71).aspx