C# vs. Visual C++\MFC

The WinAPI sucks, and if it is a main part of your project to have standard windows and buttons etc (meaning you're not making a custom interface like many games have), then your best bet is a language that lets you stay away from the API while still taking advantage of the standard UI, such as C# or Java.

haha, im not that good, cant make my own gui yet :)

I have been doing some work in C#. And I must say it is pretty good.

However, I feel a subconscious calling to go toward the harder WINAPI stuff. Maybe its cause I need a challenge :P. However I would reccomend you diving head first into the the complexities of native Win32 programming.

Afterword, you will apreciate languages such as C# more [smile]. Creating a simple program does not have to be complicated.

Quote:

Original post by vrok137 I have been doing some work in C#. And I must say it is pretty good. However, I feel a subconscious calling to go toward the harder WINAPI stuff. Maybe its cause I need a challenge :P. However I would reccomend you diving head first into the the complexities of native Win32 programming. Afterword, you will apreciate languages such as C# more [smile]. Creating a simple program does not have to be complicated.

I do know some Win32 API (the basic C part programming i mean), the thing is that i dont like langs that i have no control of the way that i want to design it, i mean the fact that everything is in a class, sometimes i prefer using functions withot creating an object... it saves some code lines...

The thing is that when i look at MCAD and MCSD i see that they require VB and ASP and C#, now the question is also, are they trying to get rid of MFC?

Quote:

Original post by Ancient Spirit ...are they trying to get rid of MFC?

Of course. It's a horrible hack. It was developed before C++ was standardized, so it does a lot of things in a manner that is inferior to the techniques now available in the C++. WTL was the first attempt to clean that up, but it was never officially documented or supported.

The other problem with MFC is that it is built on top of Win32, which has a number of complexities of its own. For instance, because you generally want to minimize entry points to a system API, and because the Win32 API is an extension of the original Win16 API and implemented without the advantages of polymorphism or genericity, MFC is not a viable long-term windowing strategy for Microsoft.

Note that Windows Forms was a stop-gap measure, to allow a .NET-based approach to using Win32 controls. It is scheduled to be replaced by the Windows Presentation Foundation (WPF), formerly codenamed "Avalon."

There is no "perfect" solution. You will have to learn multiple APIs if you intend to develop Windows GUI applications, unless you elect to use abstraction/wrapper libraries like wxWidgets.

Quote:

Original post by Oluseyi There is no "perfect" solution. You will have to learn multiple APIs if you intend to develop Windows GUI applications, unless you elect to use abstraction/wrapper libraries like wxWidgets.

So what you recommend is not to mess with the choices but learn them both?

EDIT: Windows Presentation Foundation, what lang is it based on and ummm... is there a point of learning MFC then? I mean for jobs and stuff...

I'd recommend you focus on C# and WinForms. That will give you the foundation to move forward to WPF.

MFC was updated with MSVC 7.0 but not much changed with the 7.1 & 8.0 releases.

Jobs wise there is significant work available for .Net programmers and will be into the future. There's a lot of code in MFC that needs to be maintained but I think the sun is on its way down. I cannot see anyone deciding to start a new project in MFC when C++/CLI w/WinForms is a viable option.

My problem is that I don't really want to learn new langs nowm because I need to study at the university aswell, so I want to stick with those things, is there a choice for a C\C++ Developer?

Quote:

Original post by Ancient Spirit So what you recommend is not to mess with the choices but learn them both?

Well, all windowing toolkits are based on the same basic principles - handles, messages, queues, threads, events. If you're going .NET, Windows Forms is the technology for right now, and WPF is the technology for next year and beyond. If you're sticking to C++, MFC is widely used, but it's basically a wrapper around Win32, so learn Win32 and it'll be applicable to more areas.

Note, however, that MFC makes some Win32 GUI tasks much simpler, so if you plan to do heavy GUI work in C++ and a wrapper is not an option, definitely learn MFC.

Quote:

EDIT: Windows Presentation Foundation, what lang is it based on and ummm... is there a point of learning MFC then? I mean for jobs and stuff...

WPF is a .NET technology, so it's language-agnostic. I don't see that many MFC job postings anymore, but, then again, I don't look so often.

Quote:

Original post by Ancient Spirit My problem is that I don't really want to learn new langs nowm...

These are much simpler languages to learn and use than C++ (which is horridly complex). Plus, with the tools from Microsoft, you don't have to write the GUI code from scratch, just the event handlers.

Microsoft give me a headache... So basically if I want to stick to C++ MFC is the way? Is GUI the only thing that is easier to do with MFC? What about system programming stuff, like the kernel and what about threads? (never used threads and kernel on Win32 SDK, I only wrote a bit GUI on the SDK and a fullscreen opengl window).

EDIT: it took me a while to learn C\C++, and now I should forget it all if I want to be a Windows programmer?

Quote:

Original post by Ancient Spirit So basically if I want to stick to C++ MFC is the way?

No, it's a judgment call. Ultimately, you have to make up your mind for yourself.

Quote:

Is GUI the only thing that is easier to do with MFC? What about system programming stuff, like the kernel and what about threads? (never used threads and kernel on Win32 SDK, I only wrote a bit GUI on the SDK and a fullscreen opengl window).

GUI has nothing to do with the kernel, thankfully. MFC does wrap threads, but largely to facilitate writing GUI code. But if you're writing threaded code for non-GUI purposes, introducing the overhead of MFC is not worth it.

Quote:

EDIT: it took me a while to learn C\C++, and now I should forget it all if I want to be a Windows programmer?

If you think you'll only ever need one programming language, you are sorely mistaken. Learn as much as you can.

You know, C++/CLI is an option for you. It takes advantage of WinForms and stuff, and allows you to still write unmanaged code (ie, C++ code.) Think of it like C++ with full access to the .NET runtime.

Quote:

Original post by Flimflam You know, C++/CLI is an option for you. It takes advantage of WinForms and stuff, and allows you to still write unmanaged code (ie, C++ code.) Think of it like C++ with full access to the .NET runtime.

Thanks, i'll give it a shot :)

By the way, when I say Visual C++ and MFC... Are those 2 different things?

I think the technical way to think about it is that MFC is a particular way to use C++.

In my experience (I've used a lot of Win32 API and .Net Forms), .Net forms is *far* easier to get what you want done quickly.

You are free to choose from several languages (C#, C++, and VB are the major ones) if you decide to use .Net.

is there a way to insert C++\C stuff to C# code?

Not exactly. But if you write some code in C++ and compile it as a DLL, there are many ways to use it from C#. Unfortunately you can't #include any C++ source code inside C# files.

[edit] There *might* be a way to merge two .Net 'assemblies' (this is their word for "EXE or DLL or similar file") that were compiled from separate languages into one EXE. I haven't tried that hard to get it to work though, since one EXE and many DLLs works fine for me.

So basically I can use C++ for the class design and C# only for the GUI?
I have managed to combine fortran and C\C++ code and some ASM code with it as well. The thing is that for it to work the program should make an .obj file and then in the compile time all the objects are combined... and you have a multi lang exe program... Actually I have done it in Linux, but that shouldnt be that hard in windows either...

Quote:

Original post by Anonymous Poster Quote: Original post by Extrarius The WinAPI sucks Based on what criteria? The Win32 API doesn't suck. Just because you don't like it doesn't mean you should go around making generalizations. Your comment simply demonstrates that you haven't had much experience with APIs that REALLY suck.

Based on design principles covered in many great books by the microsoft press, such as "Code Complete"(ISBN 0735619670) and "Writing Secure Code"(ISBN 0735617228). As Oluseyi said, the main problem is that it was designed a LONG time ago, before modern languages or techniques were well-known, and it was designed to be mostly compatable with an even older system that is beyond 'legacy' these days.
Even these days, design isn't entirely objective, though, so you're free to have your opinion. For now =-P