How many of you are working on a new MFC professional project?

Dear All,

I am wondering how many of you are involved in starting a new MFC professional project and why are the reasons that lead you to do this.

Thanks!

Hi, Im working in an MFC as a professional project (in fact my very first proffesional project ) mainly because I have been teached C++ and a little bit of MFC in my univeristy ,I dont know any C#, .NET or similar neither had time to learn another way to develop a GUI app (typical desktop application i mean)

I'm almost possitive it is not the most productive way, though.

I think you chose the wrong Forum for such a question. You'd better have asked it in some of the "General Discussion" forums. :cool:

Pretty much using MFC exclusively for all development of desktop based applications.

For projects that will need a different type UI (web, graphical, ...) MFC is rarely the obvious choice.

Sometimes MFC, and sometimes QT.

I am asking in this forum since I rarely go into general discussion and I believe that here is more likely to find people programming using MFC (is a Visual C++ Programming forum and I am asking how many people starts programming new projects using MFC and Visual C++).

Anyway.. I appreciate the quick answers of the other two members.. that seems to indicate that there are still people choosing MFC.. I have done some performance test and pure C++ wins againsts C# with a ratio of 4:40 (ten time faster), even when using Ngen code optimizer for .NET 2.0. I was wondering if also other people uses MFC or pure C++ for reason of performances..

I was on a developer event last Saturday and some of the senior developers where arguing that C# is not the best choice and using MFC is crazy.. they said also that there are plenty of forums and articles showing that the performances are nowadays similar and that there should be something wrong with my results.. I double checked them and I am pretty confident that the code is the same in the two versions (C++ and C#).. the thing is that probably is a very complex mathematical code (that was the idea) and that most of the test available "asks less" in computational terms..

thanks to everyone that will contribute!

Quote:

---

Originally Posted by pengCC

and using MFC is crazy..

---

Crazy in wich sense?

Quote:

---

where arguing that C# is not the best choice and using MFC is crazy..

---

There is nothing wrong with MFC.

Quote:

---

they said also that there are plenty of forums and articles showing that the performances are nowadays similar

---

Complete BS. C# will never win from any form of C++. Both speed and functionality are better.

Quote:

---

Originally Posted by Rez_Spain

Crazy in wich sense?

---

I asked him why and he told me that he believes that C# .NET framework learned from the MFC framework errors and thus is better.. following the idea that thing evolve..

He also said that he couldn't find any MFC programmers to maintain his existing code..

then there is the thing that MFC is based on Win32 Api and there is no guarantee that in the future they will rewrite MFC to support the Win64 Api ..

those where some chunks of the conversation we had..
I just got a freight and then went back to the code and added the ngen compiler optimization to see wheter we were that creazy and if fact the imporvement wasn't relevant..

Quote:

---

Originally Posted by Skizmo

There is nothing wrong with MFC.


Complete BS. C# will never win from any form of C++. Both speed and functionality are better.

---

Cheers Skizmo! That's nice to hear from you as well... I kind of got the impression that many many people speaks too much sometimes and even more without supporting data.. reading something in a website is something, implementing and verifying it is something else.. reading something in codeguru with the sourcecode and verifying the letter is even better :-)

Performance is a moot issue in many projects. The majority of todays applications spend 99% of their time 'waiting' for user input via keyboard or mouse.

In this kind of setting, C# has an advantage over C++. Writing your UI and all the 'interfacing' bits in C# will usually mean you get the programming part done faster with fewer chances of errors.
The low level 'engines', bussiness logic and calculations tend to benefit from being in C++ because there an X-fold performance change will be noticable.

Typical example: making a UI that displays some video's is easier to do in C# than C++.
But i wouldn't suggest making a video codec in C#.

Quote:

---

Originally Posted by Skizmo

There is nothing wrong with MFC.


Complete BS. C# will never win from any form of C++. Both speed and functionality are better.

---

On the other hand, I wouldn't take the statement "I have done some performance test and pure C++ wins againsts C# with a ratio of 4:40 (ten time faster), " at face value.

we were considering using C# to write the UI and C++ to write the computational part.
But personally I am facing some difficulties in understanding how to write a C++ dll (I am following some tutorials but I haven't fully understood the practical details and soem of them are missing in the tutorial) and furthermore we are using Matlab to create the computational core of the program, we will then export the matlab file in a C++ source code (there is this feature). We will be using also some other dll..

the problem arises in how to write the wrapper class that will communicate from the C++ dll to the C# dll. it is not a straightforward operation (for me).

The other thing is that the GUI at the end of the day will be only 20% of our coding, so adding the above process will yes make it more easy to mantain but also add a considerable overload.. is not an easy decision.. If I had more experience in writign dlls I would probably feel more confident on that.. but I think we will stick with C++ MFC, also because we have some UI code already written in MFC which we can reuse.

thanks for the contributions!

Probably the easiest way to maintain simplicity in the C# app is to use COM in your C++ dll. Using the project wizard, you can create a simple ATL dll (with MFC support if you want), then using the class wizard, add methods/properties to your ATL interface.

For the last 10+ years I have been using MFC for professional and personal projects. There is nothing wrong with using MFC. MFC is just a thin wrapper around Windows API. As long as Windows API exists, MFC would exist.

WinForms are now being replaced by WPF, which requires more code maintenance, than a MFC project. Earlier it was VB to .NET migration. Even before that MFC existed, and still exists.

Quote:

---

Originally Posted by Ajay Vijay

WinForms are now being replaced by WPF, which requires more code maintenance, than a MFC project.

---

Why do you believe this to be the case?

I mean the WPF technology is out. For excellent GUI, many are thinking of migrating from Windows Forms applications to rich WPF applications. Since, there are class hierarchy changes, and some stuff like data binding must be put in .XAML file - it obviously needs more of code changes, than required in upgrading MFC (like group-view in list control, requires less change).

We use MFC in all new applications for a number of reasons.

1. Using C# for the UI has been raised now and then, but we all know C++ & MFC well and have little to no experience of C#
2. Our GUIs are simple enough for WPF or Forms to not have any real advangtage over MFC
3. Splitting the code into separate C++ processing and C# GUI sections just adds complexity but no real benefits for us.
4. Over the years we've built up a library of sub-classed MFC components that have an STL interface and add functionality common to most of our applications.