class planning
Hey gamedev, I am getting really frustrated with programming, everytime I write some code it usually breaks down the road, I try to fix it but then it breaks something else. I try to plan things out but I don't know what to plan or even what I need. So I just start programming I get so lost that I start all over, then I plan out this is the only thing I need, then I forget to include something that would be very good to have but then it breaks all my other code. I am sick of rewriting every time to get a good peice of code. I mainly program in c++. So before I plan anything or start writing code I want to how you guys set up your include files, Do you have on main include file thats included in all your files. Do you just .h files or do you have a .cpp for every .h, Do you guys put the source files in a source folder, and include files in an include folder. Do you use namespaces and have seperate folders for each namespace or category of code. I want it easy to navigate through my code, but not so complicated I have to go through 10 folders just to find a file. The next thing I would want to do is see all the useful classes I would need to cut back on rewriting everything a million times. Obviously it would be a class that creates a window or something. But I don't want to get too far from just planning. Post what you guys think and maybe we could post a window class. thanks
Here is a window creating template I wrote. Is this a good way to start a window. Should I make a class for this so I don't have to rewrite it everytime?
#include "windows.h"HINSTANCE g_hInst;WNDCLASSEX g_wcex;HWND g_hWnd;MSG g_Msg;char *g_ClassName = "TEMPLATE";char *g_Title = "TEMPLATE";LRESULT CALLBACK WndProc(HWND hWnd, UINT iMsg, WPARAM wParam, LPARAM lParam);int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmdLine, int nShowCmd){ g_hInst = hInst; ZeroMemory(&g_wcex, sizeof(WNDCLASSEX)); g_wcex.cbClsExtra = 0; g_wcex.cbSize = sizeof(WNDCLASSEX); g_wcex.cbWndExtra = 0; g_wcex.hbrBackground = (HBRUSH)GetStockObject(0); g_wcex.hCursor = LoadCursor(NULL, IDC_ARROW); g_wcex.hIcon = LoadIcon(NULL, IDI_APPLICATION); g_wcex.hIconSm = LoadIcon(NULL, IDI_APPLICATION); g_wcex.hInstance = g_hInst; g_wcex.lpfnWndProc = WndProc; g_wcex.lpszClassName = g_ClassName; g_wcex.lpszMenuName = NULL; g_wcex.style = CS_CLASSDC; if(!RegisterClassEx(&g_wcex)) { return 0; } g_hWnd = CreateWindow(g_ClassName, g_Title, WS_OVERLAPPEDWINDOW, 0, 0, 800, 600, NULL, NULL, g_hInst, NULL); if(!g_hWnd) { return 0; } UpdateWindow(g_hWnd); ShowWindow(g_hWnd, nShowCmd); ZeroMemory(&g_Msg, sizeof(MSG)); while(g_Msg.message != WM_QUIT) { if(PeekMessage(&g_Msg, NULL, NULL, NULL, PM_REMOVE)) { TranslateMessage(&g_Msg); DispatchMessage(&g_Msg); } } UnregisterClass(g_ClassName, g_hInst); return 0;}LRESULT CALLBACK WndProc(HWND hWnd, UINT iMsg, WPARAM wParam, LPARAM lParam){ switch(iMsg) { case WM_DESTROY: PostQuitMessage(0); break; } return DefWindowProc(hWnd, iMsg, wParam, lParam);}
The windows code is really hard to wrap because the Windows Procedure message handler has to be static within a class, which means it cant access its members and such and such. Since you arent going to "reuse" that section of code, you generally only use it to enter your application there is little use (in my opinion) to wrap it up.
Id reccomend somthing simple such as a CApplication. Which you initialize before and run outside of peekmessage.
Try to decide what code your going to be reusing, and wrap it up, or learn about singletons. Dont write a class for the sake of writing a class =)
Id reccomend somthing simple such as a CApplication. Which you initialize before and run outside of peekmessage.
Try to decide what code your going to be reusing, and wrap it up, or learn about singletons. Dont write a class for the sake of writing a class =)
yah, I only write code that I can reuse, but sometimes I forget to include something then I have to implement it and it breaks code that depends on that class. The post name should have been structure with include files, plus class planning. I just have a bunch of files then I get link errors that I can't fix, I get memory errors alot, and then the problem of writting crappy slow code.
Quote:Original post by Asheh
The windows code is really hard to wrap because the Windows Procedure message handler has to be static within a class, which means it cant access its members and such and such. Since you arent going to "reuse" that section of code, you generally only use it to enter your application there is little use (in my opinion) to wrap it up.
It makes things a little more tricky than usual, but really hard? Not _really_.
With a little trickery you can add function handlers to the window class:
http://www.angelcode.com/dev/window2/window2.asp
What I do is that I have a map in my window class which maps the different messages to registered handlers. I started out by just using a message to static function map (std::map<uint, WndCallback>), but lately I realized that it's more dynamic if you have a message receiver base class that all the different hanlder types inherit from (std::map<uint, IWndMsgReceiver>. That way it's simple to associate data with the handlers. I don't have any of the code here, but I can post what's relevant later if you want?
Edit:
Ooh... I forgot.. I've changed the handler from std::map<uint, IWndMsgReceiver> to std::map<uint, std::list<IWndMsgReceiver> > to allow for more than one handler for each message. Another way to handle this is to use a composite IWndMsgReceiver. That is create a message receiver class which can contain multiple message receivers.
Edit:
I didn't really answer the main question, now did I? :P I have a couple of pretty large projects going on now where I do the following:
-I usually have a cpp file for every hpp file (as a rule I put all the code in cpp files)
-I have a different folder for each namespace since I find it easier to navigate through the files. Another nice thing with this approach is that you see which namespace a class file belongs to by looking at the include file. I also have different folders in the solution folders. One for project files, one for code and one for includes.
-I use a namespace for each library name and if the library is large, I create another namespace under the first one. I never use more than two namespaces.
[Edited by - e-u-l-o-g-y on August 5, 2005 4:20:41 AM]
http://www.angelcode.com/dev/window2/window2.asp
What I do is that I have a map in my window class which maps the different messages to registered handlers. I started out by just using a message to static function map (std::map<uint, WndCallback>), but lately I realized that it's more dynamic if you have a message receiver base class that all the different hanlder types inherit from (std::map<uint, IWndMsgReceiver>. That way it's simple to associate data with the handlers. I don't have any of the code here, but I can post what's relevant later if you want?
Edit:
Ooh... I forgot.. I've changed the handler from std::map<uint, IWndMsgReceiver> to std::map<uint, std::list<IWndMsgReceiver> > to allow for more than one handler for each message. Another way to handle this is to use a composite IWndMsgReceiver. That is create a message receiver class which can contain multiple message receivers.
Edit:
I didn't really answer the main question, now did I? :P I have a couple of pretty large projects going on now where I do the following:
-I usually have a cpp file for every hpp file (as a rule I put all the code in cpp files)
-I have a different folder for each namespace since I find it easier to navigate through the files. Another nice thing with this approach is that you see which namespace a class file belongs to by looking at the include file. I also have different folders in the solution folders. One for project files, one for code and one for includes.
-I use a namespace for each library name and if the library is large, I create another namespace under the first one. I never use more than two namespaces.
[Edited by - e-u-l-o-g-y on August 5, 2005 4:20:41 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement