Sign in to follow this  

Large projects : one object per h / cpp file?

This topic is 4752 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

Hi - just looking for some advice from those with experience with large projects. When I started learning C++ I tended to use a single .h / .cpp file-pair per object. However, as my programs start to get much larger this obviously increases the number of files I end up with. I started playing with having abstract interfaces and concrete class in the same file (so Entity, with EntityPlayer, EntityEnemy, whatever) but this just creates huge individual files which are hard to locate things in. I am also in the process of writing a cake-designing program for my wife to help with her business, that contains a lot of winproc functions. I've currently grouped them under file / edit etc categories (ie one file per top-level menu category), and have a hit a similar problem as the total program size increases. So - my question is : how do you tend to organise your large, multi-object files? What are the pros and cons of doing it in different ways? How about things like general purpose functions, functors etc? Thanks in advance for any help, Jim.

Share this post


Link to post
Share on other sites
I use 1 object per header/cpp, with the file basically sharing the name as the class.

class Renderer would be in Renderer.h and Renderer.cpp, and within visual studio to reduce clutter I group files under folders that describe their subsystem.

Share this post


Link to post
Share on other sites
One linkable class per .h/.cpp/.test.cpp is an acceptable heuristic.

Design to make them count since it will be annoying to write makefiles with hundreds of files. Just like it will be annoying to write comprehensive tests for classes that do too much.

Share this post


Link to post
Share on other sites
Yes, large projects just get big. Stuffing additional classes into less files only reduces the number of files you have, but not the complexity of yout project. Like DrEvil said, if you're in VS, make folders in your project representing subsystems. Then it is much easier to manage.

Share this post


Link to post
Share on other sites
U can make folders :P

i do kinda what the directx guys do and make a big one called common for basicly everything i need to include but didnt write myself. stuff like directx code microsoft wrote and my crappy timer i got soemhwre and stuff. then when i get something that has tons of files like for example i making a game and had 12 guns/bullets that is 24 FILES + 2 more for the base class!!!!! plz put in a foder called GUNS. WOW WIN!!!

Share this post


Link to post
Share on other sites
I wouldn't put my interface class definition in the same file as my concrete class. On of the big wins wiht interfaces is that you can change the concrete class without causeing hte rest of your app to recompile. If they're in the same file and you change the concrete class, even though it might not affect the rest of your code, every file that knows about the interface will be recompiled.

Try to have one file per interface and one for concrete implementations.

Cheers
Chris

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Well, that's fairly unanimous (as I suspected it might be!).

Quote:

To paraphrase several people : oi - you can create folders you know!


Ah, I learn something new every-day! In my rush to learn C++ I haven't really explored everything my compiler can do (and yes, I use VC primarily). Maybe it's time to learn about my programming environment some more ;)

It's amazing what you can learn by right-clicking stuff at random!

Quote:

I wouldn't put my interface class definition in the same file as my concrete class. On of the big wins wiht interfaces is that you can change the concrete class without causeing hte rest of your app to recompile. If they're in the same file and you change the concrete class, even though it might not affect the rest of your code, every file that knows about the interface will be recompiled.


Good point, and not something I'd considered.

Thanks for all the help (rating++). If anyone has any recommendations / experiences about general functions and/or winproc functions, would also be appreciated - although by keeping the whole program structurally simple, I might use one file per dialog box.

Thanks y'all,
Jim.

Share this post


Link to post
Share on other sites

This topic is 4752 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this