• Advertisement
Sign in to follow this  

C# vs. Visual C++\MFC

This topic is 4379 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was wondering, since I will need to do some windows GUI stuff, and it surely will include the hard to do things in Win32 SDK, what language should I learn? I am a C\C++ Programmer I also know basic Java, maybe that will help your answer... The thing is that I might want to write a property sheet or some other things for game settings or for example for other apps... As I see it thou, C# slowly takes over... Anyway, please advice, Thanks!

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest 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.


Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.


Perhaps the Win32 API isn't the worst API ever conceived. However, considering there are vastly better in every way options, anyone who uses the WinAPI for anything but maintenance if legacy code is insane. INSANE. Or stupid.

Share this post


Link to post
Share on other sites

Quote:
Original post by Anonymous Poster
Quote:
Original post by Extrarius
The WinAPI sucks

Just because you don't like it [...]

Does anyone like the Win32 API?

Share this post


Link to post
Share on other sites
Quote:
Original post by Ancient Spirit
By the way, when I say Visual C++ and MFC... Are those 2 different things?

Very. Visual C++ is the brand name for Microsoft's integrated development environment (IDE) for C++. Visual C++ is a part of Visual Studio, which has evolved over the years to let the various "Visual" products share components such as the text editor. The compiler is known as Microsoft C++ x, where x is the version number (currently at 8.0).

The Microsoft Foundation Classes (MFC) are a collection of C++ classes and preprocessor code (and macros) that greatly simplify the process of writing Win32 GUI code. MFC has shipped with Visual C++ for at least 12 years; I first encountered them both in Visual C++ 1.52, which was my first C++ compiler.

Quote:
Original post by Ancient Spirit
So basically I can use C++ for the class design and C# only for the GUI?

Yes, you can. You have two alternatives:

You can write an "unmanaged" C++ DLL (with C interfaces, naturally) which is made accessible to C# via interop. This is best if you are going to expose a limited number of APIs from your C++ DLL to C#, and communication is simple: pass native type (int, byte arrays) arguments to the DLL, retrieve integer type return values.

You can also write a managed assembly in C++/CLI, placing the interoperability layer between managed and unmanaged code within your assembly. This has the advantage of making the overall assembly much easier to use, as well as making it available to the full range of .NET languages (C#, VB.NET, F#, Nemerle, PERL.NET, COBOL.NET, FORTRAN.NET, IronPython, etc).

Quote:
I have managed to combine fortran and C\C++ code and some ASM code with it as well.

The mechanisms are very different. First, all of the above expose C declarations (you can pass C++ declarations because name mangling makes them unrecognizable). Secondly, it sounds like you linked them all into a single binary file. Using the .NET assembly-based method, each language can generate its own assembly (produce code) and any other language can use it (consume code).

It's a very different approach.

Share this post


Link to post
Share on other sites
Borland C++ Builder. The VCL is amazing, although it is a 'wrapper' for the Win API, you can still do *a lot* with it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement