ATL, WTL, MFC, Win32... ?? (Noob) 2

[AtomicChip]

I'm somewhat of a C++ Windows programming noob...

The more I've been reading recently, the more I'm discovering the differences between ATL, WTL, MFC and basic Win32.

Question is - which one is the most preferred for standard Windows programming (nothing too fancy)? As I understand it, MFC was the wrapper class foundation for Win32 API calls. ATL was next and the newest iteration is the WTL (no, I'm not forgetting WinForms; just don't want to do managed C++ - I do my managed stuff in C#

Hope some of you can shed some light on this. I'm kinda confused right now, wondering which set to use in my apps (I'm assuming that if you use a couple, or all of them, you'd be getting fairly significant code bloat - or am I wrong?).

Thanks in advance for your comments.

-----------------------------------------------

http://www.liquidfuzion.com

"The night sky over the planet Krikkit is the least interesting sight in the entire universe."
-Hitch Hiker's Guide To The Galaxy

 

[xwb]

You did not say which development environment you have.

MFC - If you are using MDI or lots of tabbed windows/wizards, splitters etc, this is brill. It is a bit quirky in that it has its own RTTI built in with macros. The nice bit is you get the source code so if you don't like the way something is done or you want to do something special, you can change it. Lots of MFC programmers about so no problems getting help on this one.

ATL - a variant of MFC non GUI classes with templates. Takes a lot less space. The big problem with MFC is the library. If you have V6 and someone sends you code with V7 or V8, it doesn't work. With ATL, because it is templates, there is no library as such and not that much to worry about. The only problem I find is stepping into the template code. It always looks unduly cryptic.

WTL - a variant of MFC GUI classes with templates. There is hardly any help on this one if you get stuck. WTL calls are almost like MFC but not quite. The big advantage is that you do not have to have the MFC dll.

What I normally do is get the code working in MFC first and then convert it to WTL.

To answer your original question: there is no preferred dev env. Different developers like different environments for different reasons. I like to keep to standard C++. I prefer using std::string instead of CString because that is what I'm used to.

For instance, VS6 I find nice and friendly. VS.net2003, I find awful. I hate the way it builds the system backwards and tries to be clever and automatically wipes out code without telling you. VS.net2005 is the same as VS.net2003 but prettier. Still has the same annoying faults and they've deprecated most of the standard C I/O (Why?? bad case of "not invented here"?).

CodeWarrior support MFC6 but not ATL/WTL. Having said that, they're just header files and can easily be ported across.

 

[Bones3]

quote: "Different developers like different environments for different reasons."

So true! But just for grins,
If you want to take on MFC, learning at least the basics win32 API will be helpful for obvious reasons. (Of course this could be useless information because your MFC book probably talks about a lot of win32 API.)

MFC reminds me of Java because of CString and some other similar classes. Also, usually your important code starts off in some class. (CChildView or CMainFrame) I like it as far as design because it kindof enforces the smalltalk concept in C++. (in my far fetched opinion)

-Bones

 

[AtomicChip]

Thanks for the comments xwb, appreciate it - I had a feeling it went something like that (star for you). However,

ATL - a variant of MFC non GUI classes with templates.

Is it really the non GUI classes? Is the CWindow object (as defined in atlwin.h) not a part of the ATL group, or is that part of the WTL and the header filename is just misleading?

Bones - I do have a fair understanding of the Win32 API, having had to use some of it in Visual Basic (in a previous lifetime). I have also done a bit of console programming (Win32 and STL) as well as a bit of Assembler. I'm not learning Windows programming per-se (I've been developing C# apps for about 2 years now, and VB before that) - I'm learning C++ Windows programming.

Thanks again for the comments guys. If you have any more, please let me know.

-----------------------------------------------

http://www.liquidfuzion.com

"The night sky over the planet Krikkit is the least interesting sight in the entire universe."
-Hitch Hiker's Guide To The Galaxy

 

[AtomicChip]

PS...

Is there really a difference between the MFC CArray class and the STL Vector class, or is this just the programmers' preference?

The more I read, the more there seems to be a ton of overlap. Not too used to this coming from the managed side of things

-----------------------------------------------

http://www.liquidfuzion.com

"The night sky over the planet Krikkit is the least interesting sight in the entire universe."
-Hitch Hiker's Guide To The Galaxy

 

[AtomicChip]

Anybody?

-----------------------------------------------

http://www.liquidfuzion.com

"The night sky over the planet Krikkit is the least interesting sight in the entire universe."
-Hitch Hiker's Guide To The Galaxy

 

[neseidus]

I'd say learn the STL over mfc classes since it's more applicable to other applications, but I try to avoid using MFC whenever possible

Quote "For instance, VS6 I find nice and friendly. VS.net2003, I find awful. I hate the way it builds the system backwards and tries to be clever and automatically wipes out code without telling you"

What do you mean it wipes out code? What do you mean it builds the system backwards?
I've been using 2003 for a long time now and have found it to be much, much nicer than VC 6.

 

[PerFnurt]

>Is there really a difference between the MFC CArray class and the STL Vector class

Well, the major diff is that CArray inherits CObject. While std::vector used anywhere (it is standard C++) without any dependancies.

Also CArray have a strange < class TYPE, class ARG_TYPE > interface, while a simple std::vector<TYPE> is well...simple.

>The more I read, the more there seems to be a ton of overlap.

The MFC collection stuff was developed before there was nice STL collections to use.

The MFC stuff have a lot of debug support the STL stuff doesn't have.

Btw, I never use MFC collections as I find 'em rather quirky, but thats a personal pref.


/Per
[sub]
www.perfnurt.se[/sub]

 

[AtomicChip]

Thanks PerFnurt. That's what I was looking for.

-----------------------------------------------

http://www.liquidfuzion.com

"The night sky over the planet Krikkit is the least interesting sight in the entire universe."
-Hitch Hiker's Guide To The Galaxy

 

[buzznick]

The problem with Microsoft is that... if they didn't invent something in the first place, they feel compelled to reinvent it - a pain in the arse for developers because it causes confusion. I mean, why use LPVOID's and UINT's instead of the regular void* and unsigned int's that all C/C++ programmers are familiar with? Also makes it a pain when you want to port some code over to another platform.

Personally, if I'm creating a regular "Windows" type program with controls, dialogs, etc. I'll create a basic MFC project and use that as a basis. However, the code I add in to make it "do it's thing", I tend to keep as generic as possible. For instance, I'll use std::vector<> instead of CArray, std::string<> instead of CString, and so on. Also, for basic stuff like setting window titles, etc. I'll use the basic WinAPI instead of the MFC variant.

Also, a good book for learning the basics of creating windows, controls, etc. in MFC is Sam's Teach Yourself Visual C++ 6.0 in 24 Hours. That'll get you creating windows with font drawn text in and dialog controls, etc. in no time.

Just my two cents worth!

 

[xwb]

Just to clarify a few points

VS.net 2003 wiping out code (known in some circles as "The Woe") sorry that is a random C# problem not a C++ one. It tends to do it with custom controls. Click on the wrong spot in the design view and zap the code is gone from the code view. Sometimes, if you do not close the design view before a build, it also wipes out code. Most people who have worked on large C# projects (the ones that take over 5 minutes to load on a 3GHz 1Gb PC) have experienced "the woe".

Building the system backwards: have you ever watched a system build? Notice how the files are compiled in reverse alphabetical order? Also alpha appears after ZERO in the file list because a is after Z in the ASCII sequence. You'll think that the file is missing if there is a long list and you do not realize that the tree control has stuffed them down the bottom!

If you're programming .net stuff, stick to C#. The managed stuff is just unbelievable. Like using a sledgehammer to crack a peanut. Also, when you get back into the unmanaged stuff, you forget to delete things and end up with a gigantic memory leak.