In a few cases in my own projects, I have a situation where I've declared/defined mutliple classes using the one set of .h and .cpp files, due to one always being used in conjunction with the other. For example, my Entity class is used with a struct which defines parameters for creating it (the struct is populated and passed to my EntityManager, which then constructs an appropriate entity and returns a reference). Rather than every time having to include headers for both Entity and EntityParams, I've just put everything for EntityParams into the files for Entity.
Is this considered bad practice in the wider world?
Multiple classes in the same .h and .cpp files
Unlike Java, C++ never made any relation between a file and its content. In Java, file, class and package are 1:1 mappings.
C and C++ compile top to bottom, so after preprocessor runs, there is one big file which contains everything. .h/.cpp separation exists solely at discretion of developer and potentially modularity.
One guideline that exists with regard to dependencies is that concrete types and type definitions should be included only if sizes need to be known, such as class members or pass-by-value. Otherwise, forward declarations offer sufficient decoupling and help reduce build times.
If params are passed by reference and not members of any type, then just forward declaring them is sufficient without including them specifically: "class EntityParams;". .cpp can then include them so they can be created and used without polluting the headers.
C and C++ compile top to bottom, so after preprocessor runs, there is one big file which contains everything. .h/.cpp separation exists solely at discretion of developer and potentially modularity.
One guideline that exists with regard to dependencies is that concrete types and type definitions should be included only if sizes need to be known, such as class members or pass-by-value. Otherwise, forward declarations offer sufficient decoupling and help reduce build times.
If params are passed by reference and not members of any type, then just forward declaring them is sufficient without including them specifically: "class EntityParams;". .cpp can then include them so they can be created and used without polluting the headers.
Author
I think you misunderstand a little.
I'm not talking about including declaration and implementation in the same file, but rather the headers for more than one class in one .h file, and the implementations for those classes in one .cpp file.
In the example above, I have the headers for both Entity and EntityParams in Entity.h and the implementations for both in Entity.cpp
Is this a sensible thing to do, or is it frowned upon (the only reason I can think of why it might be is readability, where it might make the code for EntityParams difficult to locate)?
I'm not talking about including declaration and implementation in the same file, but rather the headers for more than one class in one .h file, and the implementations for those classes in one .cpp file.
In the example above, I have the headers for both Entity and EntityParams in Entity.h and the implementations for both in Entity.cpp
Is this a sensible thing to do, or is it frowned upon (the only reason I can think of why it might be is readability, where it might make the code for EntityParams difficult to locate)?
There's generally no issue in placing related classes in the same header and/or implementation file, especially if the only reason one of those classes exists is to be part of the other class' interface as it sounds like with your Entity and EntityParam classes.
No problem at all.
Though if you want to be fancy-pansy OOP, then you might want to put your classes as nested classes.
The upside being that you can use "Entity::Params" as just "Params" everywhere within the implementation of Entity.
Maybe not much gain, and a bit messier declaration, just thought I'd point it out.
Though if you want to be fancy-pansy OOP, then you might want to put your classes as nested classes.
class Entity {
public:
class Params {
//...
};
//...
}
The upside being that you can use "Entity::Params" as just "Params" everywhere within the implementation of Entity.
Maybe not much gain, and a bit messier declaration, just thought I'd point it out.
This is a totally legit practice. I do it all the time.
For organization, you can use inner classes (as has been suggested), or namespaces, to prevent things from getting out of hand; but that's optional in most non-huge code bases.
For organization, you can use inner classes (as has been suggested), or namespaces, to prevent things from getting out of hand; but that's optional in most non-huge code bases.
Because I don't like switching through .h and .cpp files, I just put the headers and the code in the .h file. How bad of a practice is this?
For example
For example
class a
{
private:
function();
};
a::function()
{
}
some people might say it clutters the header which provides a concise overview of the class details. but really all modern IDE have code completion etc which makes that argument a bit mute.
the big downside to not seperating code into headers/source files in c/c++ is that it means that the code needs to be recompiled in every file that includes it, whereas normally we have the actual code in the source file which is compiled once, and only needs recompiling accross builds if it's content has changed.
the big downside to not seperating code into headers/source files in c/c++ is that it means that the code needs to be recompiled in every file that includes it, whereas normally we have the actual code in the source file which is compiled once, and only needs recompiling accross builds if it's content has changed.
Another pitfall with having the implementation and declaration in the same file is if you have a circular dependency.
That's not possible (I think) to solve in a single file, you will need a forward declaration in the header file, and include the real header-file only in the implementation.
like this:
That's not possible (I think) to solve in a single file, you will need a forward declaration in the header file, and include the real header-file only in the implementation.
like this:
classA.h:
--------
class B;
class A {
public:
B* b;
}
classB.h:
--------
class A;
class B {
public:
A* a;
}
That's not possible (I think) to solve in a single file
Keep in mind that C++ includes are just blind idiot text replacements. Anything you can do in multiple include files you can do with a single include file.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
