Well try the micrsoft msad web site

http://msdn.miscrosoft.com

MFC was made by mircosoft...they have good information''s about-it!

First, get "Programming Windows with MFC" by Jeff Prosise. This book is great. No AppWizard or ClassWizard or anythinhg else like that. It teaches MFC from the ground up from purely a coding perspective. Hell, you could write MFC apps in Notepad after you read this book. (Although that would just be sadistic).

Ummm, you really do need to learn about pointers. I know they are difficult to grasp, but they are such a cornerstone in C/C++ that there''s no real way to sidestep them. Trust me, once you figure them out and why they are used, you''ll understand how powerful they really are.

As far as CList and CArray, I''m not certain. I used CArray once in an office application I wrote, but speed wasn''t critical there. I believe they work by dynamically allocated memory whenever you exceed the array''s size. I don''t know if only new memory is allocated only for the new entries needed or if an entire new array is allocated and everything is copied over. Either way, I wouldn''t expect it to be very fast.

If you are just dead set on using them though, make sure that you find a good initial size and grow value for your problem. The grow size is how many more nodes are added once the array has to increase in size. If it''s too small, you''ll be allocating memory all over the place, and if it''s too large, you''ll just be wasting memory.

For a problem like that, linked list are probably better, but then there comes the pointers, etc...

I loathe the MFC container classes (CArray, CTypedPtrArray, etc). The array classes use a hash table, which is completely inappropriate for some arrays, and whose table depths have to be manually initialized. Never mind the fact that you have to overload all these "helper functions" to get any custom class to work. Perhaps my biggest beef is that it uses the hideously inefficient quadratic key with any class that can be converted to a string, i.e.:
key for "key" is ''k'' * 64 + ''e'' * 32 + ''y''. Fine for small strings, but I was trying to make an array of large strings. Talk about painfully slow access.

Anyway, I would normally say "learn STL". Well, I''ll say it anyway. Learn STL. But if you''re not comfortable with pointers, it tells me that you''re a beginner, and STL is pretty advanced (although amazingly useful). It might be a good thing for you to start with implementing an array or list class yourself, get you into the groove of things.

As for MFC, I highly recommend the "Scribble" tutorial. Even though most people around here seem to berate the document-view architecture, it does have its place. You can probably ignore that part of it and just get an idea of how the view works.

To get the "raw app" you want, take these steps:
1) Use appWizard to create a new MFC application (say "Game").
2) Select "Single Document". If you have 6.0, I think it allows you to un-check document/view architecture. Go ahead & uncheck it.
3) Click "Finish". This will automatically give you a toolbar, status bar, some other stuff. It''s easy to remove later.

If you weren''t able to uncheck the Doc/View tab, here''s what you want to do:
1) Remove the files "GameDoc.cpp" and "GameDoc.h" from the project. This can be done via the FileView tab in your "Workspace" toolbar (menu View->Workspace).
2) Go to the function GameApp::InitInstance. Delete all the malarky about document templates and command line parsing. It should basically look like this:

// ...snipped top of function...
// Change the registry key under which our settings are stored.
// TODO: You should modify this string to be something appropriate
// such as the name of your company or organization.
SetRegistryKey(_T("Local AppWizard-Generated Applications"));

// To create the main window, this code creates a new frame window
// object and then sets it as the application''s main window object.

CMainFrame* pFrame = new CMainFrame;
m_pMainWnd = pFrame;

// create and load the frame with its resources
pFrame->LoadFrame(IDR_MAINFRAME,
WS_OVERLAPPEDWINDOW / FWS_ADDTOTITLE, NULL,
NULL);

// The one and only window has been initialized, so show and update it.
pFrame->ShowWindow(SW_SHOW);
pFrame->UpdateWindow();

return TRUE;
}

3) Go to the "CGameView" class, and remove all instances of GetDocument and CGameDoc.
4) Compile the sucker & remove any other instances of the doucment there may be left in there. (haven''t done this too much, so I might have forgotten something.

Now you have a program with very simple structure:
- CGameApp class is created when you execute the program. The first thing it does is call InitInstance, which creates the frame.
- CMainFrame class is created by CGameApp::InitInstance. This class represents the frame around your game''s window. This includes the window title, the size & position on the screen, moving & resizing, the menu (file, edit, etc.), the toolbar, and the status bar at the bottom. Basically, everything that''s in that window except the white space in the middle is the frame.
- CGameView is the white space in the middle. This is where your game''s display and mouse inputs will take place.

Hope that helps you get started.

MFC is GREAT... for Windows applications. I did some office application programming for a couple years and MFC worked very well. MFC is very well suited for things like level editor and other custom tools. Basically, any standard Window''ish program. Although the Doc-View architechure is a little mystifying at first, it can save you weeks of work.

As far as games go, Win32 API is the only real way to go. In games, you want speed and control. MFC trades speed and control for functionality and ease. This really isn''t that bad though since most games only use a minimal amount of Windows code anyway.

Thanks for the extra info Stoffel. I didn''t know that.

It may look like a pointer, work like a pointer, but hey, it''s a god damn Iterator-What-The-Hell-Is-That-How-Did-They-Do-That-Works-Like-A-Pointer-Thing???

just wanted to say that

"That"

ooh while we''re on the case of STL, may I recommend the book from Addison Welsey "Generic Programming and the STL"
It explains rather well the workings of STL.

MFC collection classes and STL? Is that really a choice?

http://www.codeguru.com is great, but I am not sure it would be real good for learning. It seems targeted to programmers who know MFC and are looking to learn some more advaced techniques. (There''s more than MFC here now and everyone should at least check it out).

For getting into professional game programming, MFC is something good to know. You won''t use it in games, but it''s very handy for tools programming. Depending on what a company''s needs are, this can be a good way to break in.