1

I have a program written using MFC to communicate with a device over the Ethernet. I need to rewrite it and convert it to Qt.

The MFC program uses Win API functions like CreateFile, ReadFile (to get network packet) and DeviceIOControl (to talk to the protocol used to facilitate communication)

Can I use these functions - CreateFile, ReadFile and DeviceIOControl in my Qt code directly if I include Windows.h ?

How about about Win API functions used for concurrency, like WaitForSingleObject and Mutex? What part of Win API is/is not available in Qt?

Is there a standard mechanism for converting MFC code to Qt?

László Papp
  • 51,870
  • 39
  • 111
  • 135
Gumbly jr.
  • 729
  • 2
  • 9
  • 18
  • 3
    You can use any Windows API function from a Qt application (compiled for Windows, of course). How well Qt cooperates with Windows synchronization primitives is something you will have to investigate. The standard mechanism for converting MFC to Qt: Simply don't do it. There is nothing to be gained. – IInspectable Apr 25 '14 at 23:25
  • Really? I thought Qt was much better than MFC. I am going to extend the program for the next couple of years. I decided to migrate for long term gains. – Gumbly jr. Apr 25 '14 at 23:28
  • Qt is popular among developers, but not necessarily good. If you have a working MFC application and are comfortable with MFC, keep using it. Plus, Qt has a number of issues: The entire GUI rendering is implemented in software, leading to sluggish GUIs. You cannot implement `Q_OBJECT` templates. Keyboard navigation usually never works. Qt requires an additional pre-processing stage, increasing the complexity of setting up a build system. For a substantial list of issues see [this answer](http://programmers.stackexchange.com/a/88689/76775). – IInspectable Apr 26 '14 at 08:14
  • 1
    @IInspectable "The entire GUI rendering is implemented in software" That's a good thing, since if you wish, you can parallelize it. It seems you don't realize that all of the legacy GDI/GDI+ is done entirely in software as well, only that Qt's rendering is sometimes faster than Windows's :) – Kuba hasn't forgotten Monica Apr 28 '14 at 15:16
  • 1
    @IInspectable "Qt requires an additional pre-processing stage, increasing the complexity of setting up a build system" Not pre-processing, but code generation. Of course people who actually know their programming craft realize that code generators are a good thing. They save you from typing the same old boring stuff over and over. The time they save is incomparable to the single "expenditure" of setting up moc in the build system. – Kuba hasn't forgotten Monica Apr 28 '14 at 15:18
  • 1
    @IInspectable "You cannot implement Q_OBJECT templates." It's a minor nitpick, and not a very accurate one - you can certainly have template-parametrized classes that derive from a `QObject` base class. If you insist, you can still do it if you tweak `moc` a bit. – Kuba hasn't forgotten Monica Apr 28 '14 at 15:19
  • 1
    @IInspectable Write [this](http://stackoverflow.com/questions/22664217/making-my-own-photo-mosaic-app-with-qt-using-c/22674903#22674903) in MFC, then we'll talk :) – Kuba hasn't forgotten Monica Apr 28 '14 at 15:22
  • @Kuba *"It seems you don't realize that all of the legacy GDI/GDI+ is done entirely in software [...]"* GDI+ is a software library. GDI is - and has been since Windows 3 - hardware accelerated, to varying degrees (except for Vista). While - in theory - it would be possible for Qt to suck less in that department, in reality, its attempt to *parallelize* rendering employing SSE turned into an epic failure. If you want to see what a permanent stall looks like in source code, check out the *SSE-deoptimized* RGBA alpha blending code path. Compile an app with Qt3 and compare perf. against Qt4+. – IInspectable Apr 28 '14 at 18:59
  • As for the "Write this in X" challenge: I'd be happy if you could implement that with Qt so that it is usable. *Usable*, to me, includes, that I have to be able to exclusively operate it with the keyboard. Best of luck. – IInspectable Apr 28 '14 at 19:02
  • 1
    @IInspectable GDI is not hardware accelerated on current hardware with the exception of blits. Seriously. – Kuba hasn't forgotten Monica Apr 29 '14 at 01:44
  • @Kuba BitBlt and AlphaBlend are hardware-accelerated. Those are costly operations, and it makes a world of a difference. There's a reason why Qt GUIs **always** feel sluggish - no exceptions. – IInspectable Apr 29 '14 at 06:21
  • 1
    @IInspectable So, given that the GDI rendering *is* otherwise done in software, you claim that pushing two bitmaps from RAM to texture memory, then doing a blend or blit there, and moving them back to continue software rendering, is cheaper? I don't buy it. Those operations are *only* limited by the memory bandwidth, not by the CPU, so having the GPU do them is pointless. A blit or blend *to screen* is hardware-accelerated, and Qt *does* leverage that in the cases where it blits to screen (there's no other way!). – Kuba hasn't forgotten Monica Apr 29 '14 at 12:14
  • @Kuba You're beating a dead horse. However you argue that GDI is potentially not faster, in theory, in practice it is. In other words: Qt is slow as molasses. If you wish to continue to live in a fantasy universe, continue arguing. But please, don't do it over here, in the real world, where we have established facts: Qt is **sloooow**. End-of-story. – IInspectable Apr 29 '14 at 12:28
  • @IInspectable: your circular argument of Qt being "sloooow" is unfounded, so either provide benchmarks here or people may just ignore your continuous claim without backing it up. Also, Qt guis can be hardware accelerated, too, as it entirely depends on OpenGL. – László Papp Apr 29 '14 at 18:41
  • @Laszlo Benchmark results (Fullscreen app, rendering 128 solid rectangles, 1920x1200@32bpp, offscreen rendering): Qt (SW raster engine): **32.1 fps** - Qt (Direct2D raster engine): 22.3 fps - Native Windows (Direct2D): 24.0 fps - Native Windows (GDI): **74.3 fps**. I didn't benchmark OpenGL, but would assume performance to be slightly below Direct2D. – IInspectable Apr 30 '14 at 09:22
  • This is not a benchmark, just numbers. Where is the code. Where is the hardware accelerated scenegraph alternative? So far, it seems to be a benchmark of apple and orange without knowing anything about the fruits. – László Papp Apr 30 '14 at 09:26
  • @Laszlo I cannot post code in comments - even you should realize that. I have performed substantial profiling recently, to evaluate whether or not Qt is a viable option for our product. The results I posted are just one test. This one is relevant here, because rendering solid rectangles is what GUIs mostly consist of. The scenegraph-based alternative on average exhibits worse performance, than the SW raster engine. Depending on the test even worse than the hardware accelerated Direct2D raster engine. – IInspectable Apr 30 '14 at 09:33
  • I would be very surprised if the hardware accelerated solution was slower than the old software raster engine. Anyway, you could have used a pastebin service... – László Papp Apr 30 '14 at 09:44

1 Answers1

4

Can I use these functions - CreateFile, ReadFile and DeviceIOControl in my Qt code directly if I include Windows.h ?

Yes.

How about about Win API functions used for concurrency, like WaitForSingleObject and Mutex? What part of Win API is/is not available in Qt?

You can use any part of the Win API.

Is there a standard mechanism for converting MFC code to Qt?

There is no standard mechanism. However, for the aforementioned functionality, you really want to look into the Qt alternatives, like QMutex, etc.

Also, you would need to consider whether the conversion is worth it. After all, Qt will use the Windows API on Windows in the background.

Assuming you wish to make your code cross-platform, you would really like to migrate away from the direct Windows API usage, otherwise your code will end up full of compilation-time preprocessor directives.

László Papp
  • 51,870
  • 39
  • 111
  • 135
  • I do not intend to make my application cross platform. I just want to use a better application framework. – Gumbly jr. Apr 27 '14 at 18:29
  • I was thinking that I would retain the portion of my code that uses Windows API in its current form, and phase it out gradually over time. Since, I am not worried about supporting cross platform compatibility, I can afford to take my time with it. – Gumbly jr. Apr 27 '14 at 18:43
  • Oh no no, I was responding to "Assuming you wish to make your code cross-platform". I was simply letting you know that for this application, I dont. – Gumbly jr. Apr 27 '14 at 18:59
  • OK, you know your project better than me. :) – László Papp Apr 27 '14 at 19:00
  • Given IInspectable's comment, do you think I am correct on my premise that Qt is a better application framework than MFC? I want to do real time image acquisition and processing, lots of data, lots of processing in real-time. – Gumbly jr. Apr 27 '14 at 19:04
  • It is a bit opinion based, but I agree with you about that. My disclaimer is that I do not like the WinAPI and MFC in general. – László Papp Apr 27 '14 at 19:11
  • @user3397590 Another migration route you had not considered: .NET. It offers perfect migration paths, by means of C++/CLI interop mechanisms, and a pretty good class library. MFC is already well prepared here as well: It can host both WinForms and WPF windows/controls, allowing you to gradually transition. If you're looking for a platform with high productivity gains, while still retaining your investments in high performance code, you should seriously consider .NET. – IInspectable Apr 28 '14 at 19:08
  • @Laszlo C++/CLI allows to comfortably interop with native code. I never suggested to move everything to .NET. Plus, .NET code - if written properly - can be very efficient. Depending on the characteristics, it can even beat native code. Allocating lots of small short-lived objects is something that native heap management cannot deal with gracefully, and where .NET can be faster by a wide margin. – IInspectable Apr 29 '14 at 06:28
  • @Laszlo Yes, and I explained what scenarios .NET deals with better. If you care about the issue, you are free to run your own benchmarking tests. I have, and the result was posted in my previous comment. Plus, you are missing the point entirely: I wasn't suggesting to leave native code behind. Are you having severe issues with respect to comprehension? – IInspectable Apr 29 '14 at 06:46
  • @IInspectable, I plan to do lots of real time data acquisition and processing. How suitable is .Net for that? I am concerned about acquiring data in .Net defined types, then casting those types to those supported by C++ before my data can be processed using C++. For instance, how do I acquire 3-dimensional data, what .Net type can I use for it? And can that type be passed directly to a C++ library function for processing in C++. I am not familiar with C++/CLI and interops. Your input will help. Thanks. – Gumbly jr. Apr 29 '14 at 15:28
  • @user3397590: .NET is inherently slow, and if you use C++ to be fast, then it is C++ anyway. Currently, I do not understand the alternative suggestion. It is true that the Qt API is much nicer than the Win API, but some biased WinAPI devs and users might disagree. – László Papp Apr 29 '14 at 15:32
  • @LaszloPapp, I have been recommended by some to keep my backend in C++ and choose either Qt or .Net for my frontend. I dont yet understand how to acquire data in .Net and process it in C++ without sacrificing efficieny. – Gumbly jr. Apr 29 '14 at 16:47
  • @user3397590 The recommendation to keep your processing kernel and data acquisition native C++, and gradually move your GUI to a framework you're comfortable with is a good one. MFC is superior to both Qt and .NET (WinForms or WPF) with respect to usability. .NET is superior to Qt with respect to migration paths - you can **gradually** move your GUI to .NET. This is not easily possible with Qt, and the *winmigrate* plugin has been phased out a long time ago. Using C++/CLI allows you to access managed memory directly from native code, and vice versa - no copying required. – IInspectable Apr 29 '14 at 18:35
  • @user3397590: despite what *spectable says, t has a nice API, the migration is not that difficult, and eventually with QML, you will spend only a small portion of the time with the coding, and you can focus more on the interesting stuff. .NET/C++/CLI, whatever, does not have any QML alike option either. It will also allow you later to get your project to another platforms, even if you do not want, other people might, so be flexible, and it will pay off one day. :) – László Papp Apr 29 '14 at 18:39
  • @user3397590 I never denied that Qt is a joy to work with. I comes at a price, though: Unhappy customers. Qt produces GUIs that are below standard, when compared to native Windows GUIs. QML is true to this philosophy: It makes writing GUIs more fun, while those GUIs are even less enjoyable to work with. If your product is good enough so that you can afford to piss off a few customers, then by all means, go with Qt. If you would rather employ a modern platform, choose .NET: Anonymous types, lambda expressions, closures, LINQ - to name just a few goodies. – IInspectable Apr 30 '14 at 18:54