Jump to content
  • Advertisement
Sign in to follow this  
TMP72

How many c++ classes per file

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

Hey All, I was wondering what the standard convention was for using classes in c++. In Java and C# you typically put one class per file. You can create your final executable from these seperate files. Is this the same for c++. Is the <include> statement similar to the using keyword in c#? I was just thinking of making the switch to c++ and was curious Thanks T

Share this post


Link to post
Share on other sites
Advertisement
You typically declare only one class per .h file (and of course, you have one cpp file to define it).

Of course, when you have a bunch of really small classes that are closely related, you can do yourself a favor and put them in a single file.

Regards,

Share this post


Link to post
Share on other sites
I believe this is a matter of taste really. Personally, I tend to write classes in seperate files. Small structs, enums and constants that might be specific to a class I usually write together with the class.

I have no idea if this is the best way of doing it, but i've had no problems so far anyway.

Share this post


Link to post
Share on other sites
DarkZoulz, you live in Bålsta?

Anyway on topic, it depends like it has been said. I usually only have one "main" class per file, but when this class has some small utility classes/structs to support it I often put them into the same header (and .cpp) files.

Share this post


Link to post
Share on other sites
In Java you *can* put multiple classes per file, but only one can be public. Normally you *don't* do this because there's usually little reason to have non-public classes (except perhaps inner classes). But it really does come in handy sometimes.

Good C++ practice is probably analogous; normally you have one class per file, but 'helper' stuff can get bundled together. For example, if you have a really simple-interfaced (pretend that's a word for a moment please) class, you might put the base class and all derived versions in one file; maybe the derivations only override one virtual function, and the base implements some kind of factory such that outside users never need to know about the inheritance scheme. You would then want only the base class (and factory) to be 'public' in the Java sense; to get that effect in C++, you would simply only mention those items in the header (that might possibly require some forward declarations within the implementation file).

Share this post


Link to post
Share on other sites
One more question. If I write a class in one .h file that inherits functions from a base class in another .h file, do I then need to use the <include "filename"> keyword where the base class is located or will the compiler know where to look?

T

Share this post


Link to post
Share on other sites
Quote:
Original post by Long Dog Studios
One more question. If I write a class in one .h file that inherits functions from a base class in another .h file, do I then need to use the <include "filename"> keyword where the base class is located or will the compiler know where to look?

T


You will need to include the header containing the base class. =)

Share this post


Link to post
Share on other sites
For me it really depends on the situation. As a general rule of thumb I try to have one class per .h/.cpp file. However, as people have mentioned before, small utility classes that have a strong relationship to the main class in the file I might put in the same file. Another case where I put several classes together was when I was defining exceptions for my game engine. I had all the child classes in the same .h/.cpp file because there were very few differences between them and it made it handy to include one file and get all the exceptions.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!