CODEWITHSUNDEEP
c++windowsmfc
Tae-Sung Shin
Tae-Sung Shin

Reputation: 20643

Better framework than MFC?

My clients have used MFC applications in years. Main reason was because their applications were real-time app interacting with various sensors, and their performance was key to their success.

I used MFC about 10 years ago and moved to .NET. But I am willing to go back to MFC if neccessary. But question is if it is worth and if there is anything better than MFC right now.

I understand that C++ is necessary to optimize our applications and that MFC is OOP wrapper for Win32 API and might be fastest OOP UI API on Windows.

But I am mainly worried about its testability and its complex API. So MFC might slow us down in long term.

What do you think? Is there any framework that you can achieve better performance than with MFC?

UPDATE: As for needed performance, I don't have exact numbers but I saw one app in its operations. It was almost getting various types of signals from each of moving objects. My guess at the time was less than 1/2 second to get & display all the signals from each one. But I could be wrong.

Upvotes: 1

Views: 1353

Answers (3)

Karthik Krish
Karthik Krish

Reputation: 131

There are some best alternatives for MFC.

  1. QT is the first choice to go with. But for commercial release, it becomes little costlier.

  2. wxWidgets, is also a good choice for a cross platform opensource library.

  3. Ultralight - This is totally different as it is a HTML based UI engine to create nice applications with the help of HTML, css, and javascript.

Upvotes: 0

jkerian
jkerian

Reputation: 17016

Assuming (although it wasn't specified in the question) that your application is another sensor-control system, it doesn't matter as much as you think it does.

Basically, your architecture should keep the sensor communications in their own thread, which asynchronously communicate with the rest of the app. So you're mostly checking to see if your potential replacement libraries do something pathological with their multi-threading implementation.

To give particulars, we would need particulars: required response times, interrupt frequencies, these sorts of things. But even in that case, we'd mostly just be guessing (or campaigning for our favorite API).

My real recommendation is that you look into the performance numbers you get with .NET in a "prototype control". Your recent familiarity with the API should enable you to do this relatively quickly.

If the performance seems unacceptable, do a similar prototype in Qt or WTL or whatever else looks reasonable. I would consider MFC a last resort simply due to age UNLESS you can leverage significant amounts of existing control code from the client.

Upvotes: 4

Dirk is no longer here
Dirk is no longer here

Reputation: 368191

You probably want to look at Qt.

The internet is full of comparisons of MFC and Qt; here is a particularly recent one: https://softwareengineering.stackexchange.com/questions/17490/comparing-qt-vs-mfc

Upvotes: 4

Related Questions