MFC, WTL or .NET?

So I want to start programming for Windows, only I'm stuck on what library to use. I've programmed in raw Win32, and I kindof know my way around it now, but it's pretty annoying to program in. That's why I want to use a framework that's supposed to make the programming easier.

Anyway, I've heard about 3 frameworks: MFC, WTL and .NET.
Which is the way to go?

Are MFC and WTL supposed to be faster, since they don't use a managed enviroment?

Can you use API's like DirectX and OpenGL in .NET applications?

I've also heard MFC is a 'bad' library, because it doesn't offer enough encapsulation and uses bad coding practices. Is this true?

. NET is short name for Visual Studio .NET which is a compiler that can produce both managed and unmanaged programs, libraries and DLLs. MFC and WTL are set of libraries and template classes that wrap win32 api functions.

Quote:

---

've also heard MFC is a 'bad' library, because it doesn't offer enough encapsulation and uses bad coding practices. Is this true?

---

Depends on who you talk to. I use MFC all the time with VC++ 6.0. Many programmers complain that it encapuslates too much, I've never heard anyone complain that it doesn't do enough ;) As for "bad coding practices", again it depends on who is doing the complaining. MAC and *nix programmers are just jealous :rolleyes:

Quote:

---

Originally Posted by Ancient Dragon

. NET is short name for Visual Studio .NET which is a compiler that can produce both managed and unmanaged programs, libraries and DLLs.

---

sorry, that's just wrong. yes there is a version of visual studio (2 in fact) called .net, but .Net is much more then that.

.Net is basically a complete platform that runs on windows. It is JIT compiled, and cross-language compatible, at least between the 3 .net langs, vb.net, c# and managed C+. I believe the IronPython project is adding python support, but I'm not sure.

Anyway .Net has a massive class library that does everything MFC does and more. As to which language to use, well, managed C++ is a bit hacky, but still usable. I hear the new C++/CLI in vs2005 is pretty good, but haven't had the chance to check it out for myself. C# is pretty decent, but I wouldn't bother with vb.net unless you really like the syntax. you can use managed directx in .net

as for performance, unless you're writing the next quake engine, it should be enough for what you need.

WTL is now open source, and I've heard good things, but never used it.

as for MFC

Quote:

---

Depends on who you talk to. I use MFC all the time with VC++ 6.0. Many programmers complain that it encapuslates too much, I've never heard anyone complain that it doesn't do enough ;) As for "bad coding practices", again it depends on who is doing the complaining. MAC and *nix programmers are just jealous :rolleyes:

---

I've used MFC since visual studio 97 and it's evil, (public data members all over the shop), hacky (dodgy casting for messages instead of clean virtual functions) and ugly (the macros! my eyes, my eyes!!) but it gets the job done. if you're after a simple gui, you can't really go too far wrong with it.

MFC is short for the Microsoft Foundation Classes. It's a host of over 200 classes a windows programmer can use in order to do many many things. They're very fully featured and for the most part a lot of people will tell you that if you want to combat something like an ActiveX control, then the MFC could really get rid of a lot of code you'd have to otherwise create. The MFC is a double edged sword though. It's incredibly bloated and somewhat a disaster in design. But again, if I was to write a huge frontend or something like an ActiveX control I'd seriously, seriously consider using something like the MFC.

Inconclusive on WTL.

.NET is programming framework created by Microsoft, sorta like the MFC, only I think they, you know, put some more thought into creating it. .NET has features such as just in time compilation and cross-architecture compilation, that can be taken with this example: Let's say user A creates a .NET 1.1 windows form program on your typical Pentium 4 Windows XP SP2 Office edition. It's a fairly large program, but .NET was able to combat it. When user A runs that application for the first time, it's main method has to be Just in time compiled by the .net framework. When they access another method they haven't used before, that method is also, then, JIT compiled. Once that's done, it doesn't need to be done again and this can be proved by creating a very simple .NET application that does the cliche "Hello World!" When you run it the first time it may take a little time to execute. That's just the JIT compiler kicking in. But then if you run that application again it's almost instant (given there's a little delay, but it's inexorably faster than the first time.) So his application works. Then let's say you have user B, who is using the somewhat less known configuration of a Windows 2000 system with a Pentium 2 processor (or for a little wackier combo, let's say a 64-bit Alpha processor) and he downloads this EXACT SAME executable user A created off of a website.

Anybody who's anybody will know that you can't compile an x64 app and have it work on Alpha, they're different processors and it's just impossible, right? Wrong. .NET can detect this anomaly in the program, and therefore, the .NET runtime can recompile the application for alpha systems. Thus, you compile once and you're done.


In regards to 'efficiency' complaints with .NET, .NET is good for pretty much anything you can put it up too. Two microsoft systems programmers wrote an entire Microkernel Operating System with about 95% managed code (there was only a very tiny amount of C backend needed) called "Singularity" (which they are very proud of because they use it to show images and stuff in things like presentations without the fear of crashes.) Unrelated to that, a group of programmers went and ported Quake II to .NET, and it actually ran better than the original version. This is because:
A) .NET is highly optimized (good luck finding any people who can look at Microsoft code and say it was anything other than excellent.)
B) Carmacks' now GPL'd quake II code leaves room for a lot of improvement more than likely.

There's also the development of Rotor, which is kind of like a cross-platform .NET, which isn't open source, only shared source so you can see the real details of lots and lots of .NET libraries. According to wikipedia, they've gotten Rotor to work on FreeBSD 4.7 and up, Windows, and Mac OSX 10.2.



As for what you develop with, if you ask me, it strictly comes down to what you like to use. I personally try to use the Win32 API for most of my programming. I like the structure, and for some reason when I try to build things in C# I feel strange (such as Windows forms,) not as I normally feel when I'm programming.

Quote:

---

sorry, that's just wrong. yes there is a version of visual studio (2 in fact) called .net, but .Net is much more then that.

---

Since the OP mentioned .NET, MFC and TWL all in the same breath, I assumed the op was referring to the compiler, not the .NET Framework. The are two completely different things.

Quote:

---

I've used MFC since visual studio 97 and it's evil

---

That statement just confirms what I posted -- it depends on who you talk tl :D I would say the same about X11 and Motief for *nix, but that is my opinion.

Quote:

---

Originally Posted by Ancient Dragon

That statement just confirms what I posted -- it depends on who you talk tl :D I would say the same about X11 and Motief for *nix, but that is my opinion.

---

Minus the fact that the framework is called "Motif" and the general consensus would agree that the MFc is designed stupidly and bloated. I can bet you'll find at least ten times more people that'll say the MFC is designed worse than, say, GTK/Motif/QT.


Hell, I would WAY rather work with Motif or GTK over the MFC if they didn't require simple runtimes (simple, but annoyances for end users none-the-less.)

QT isn't in the same category -- its used for portability between operating systems. X11, Motif and MFC are very specific os dependent -- you can write an MFC application for *nix or a Motif program for MS-Windows.

Quote:

---

Hell, I would WAY rather work with Motif or GTK over the MFC

---

Your opinion. I have the opposite opinion because I am not that familiar with Motif. It takes a dozen or so X11 and Motif very thick books just to be able to write a simple Hello-World program. I haven't used QT so maybe it has relieved a lot of the Motif and X11 complexity.

Thanks for all the replies! It sure cleared up some things for me.

Mad_guy, I know what you mean when you say C# feels strange. I think I'll stick with C++ and take a look at the WTL.

Thanks loads!