Jump to content
  • Advertisement
Sign in to follow this  
Burnt_Fyr

Code organization for larger win32 projects

This topic is 2128 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'm working on a largely win32 gui based app, and as the project gets larger, I'm finding it harder to navigate the increasingly larger main source file. Does anyone have any tips on breaking up windows code? My first thought was 1 source/header per window class, but I'd like some more experienced windows programmers to chime in. In the mean time I plan to crack open Petzold's book and see if I can glean anything from the master.

Share this post


Link to post
Share on other sites
Advertisement

Not sure what language this is, but if it's C++, then I've experienced it's good to wrap everything what the Win32 API is to proper exception handling. It's a bit tedious work at first, but pays off whenever you have more than two callsites for some win32 function.

 

If this is C++, then first natural step is to place one class per source/header, unless there's some good reason not to. Most likely this is an issue of layering classes from high-level to low-level.

 

I'm interested about what Petzold's book you're reading (I hope its not +10 year old book). I'm not fan of his earlier works, and now looking the bibliography it doesn't seem promising.

Share this post


Link to post
Share on other sites

I believe it's the 6th edition, so yes likely 10 years old by now. But still useful as a reference when dealing with raw win32 in c++.

Share this post


Link to post
Share on other sites

Book might be useful when dealing with Win32, but surely not when dealing with C++. Win32 is a C API. 10 years ago it was all clumped together as C/C++. C++ is totally different language than C.

 

Anyway, that was just a side-comment in my post.

Share this post


Link to post
Share on other sites

I'm finding it harder to navigate the increasingly larger main source file.

Usually my main.cpp file is just a few lines. Then there's program.cpp or application.cpp. After that it gets more domain specific, high level class what the application does. Then there might be 10 more layers all down to the lowest level classes and functions. It all depends how big the program is. You should introduce higher level abstractions whenever the program grows too big, or if you know the requirements beforehand you can try to do it prematurely (beware of overengineering).

 

I'm sure if you can give an example, many of us can give our thoughts.

Share this post


Link to post
Share on other sites

1 source/header per window type is a good start, but you should really be thinking about how to organize the data so that everything that needs to read or change the data is able to do so appropriately.  After that, good project/file organization should reveal itself intuitively.

 

For example, I recently made a 2D map editor and I organized it like this:  Each panel/window gets it's own file, but there's a central data structure that all the panels/windows have access to which provides all the functions to manipulate the map.  The data structure itself is split up into multiple files logically based on the type of data being modified (for example there's one file for all the tile manipulation functions, another file for all the entity manipulation functions).

Share this post


Link to post
Share on other sites
Work in 'Show All Files' (button in Solution Explorer), which allows you to work with real folders instead of the virtual ones. This allows to easily organize source/header files in folders (like a folder per (sub)namespace). I currently have a project that is really big and it is using virtual folders. It sucks balls to work with, but I can't refactor the code to the more desirable use of real folders because the effort is not worth the gain at this point. Stupid MS to use virtual folders as the default imo.

Share this post


Link to post
Share on other sites


Work in 'Show All Files' (button in Solution Explorer), which allows you to work with real folders instead of the virtual ones.

Virtual folders (also called filters) seem to be standard in C++ IDEs, not only Visual Studio. This way you can organize the sources "logically" while preserving a flat real folder structure. To some degree it's a matter of taste, but e.g. I prefer having all .h of a project in one folder, so I don't have to deal with multiple include paths or paths in the #include directives.

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!