17 replies to this topic

[BattleMetalChris]

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?

[Antheus]

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.

[BattleMetalChris]

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)?

[SiCrane]

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.

[Olof Hedman]

No problem at all.

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.

[ApochPiQ]

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.

[_Zac_]

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

class a

{

private:

function();

};

a::function()

{

}

[luca-deltodesco]

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.

[Olof Hedman]

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:

classA.h:
--------
class B;

class A {
 public:
  B* b;
}

classB.h:
--------
class A;

class B {
 public:
  A* a;
}

[SiCrane]

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.

[Olof Hedman]

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.

Yea, sorry, I was confused
Still I'd recommend keeping def&dec separate though...
except simple getters/setters, which I tend to inline

[ApochPiQ]

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

[snip]

That's going to screw you hard when you start writing programs more than a few hundred lines long.

Basically you may as well just write your entire program in one .cpp and not even use .h files if you do it that way. Can explain the full details if you're interested but a bit busy atm, sorry.

[VReality]

I have a situation where I've declared/defined mutliple classes using the one set of .h and .cpp files...
...
Is this considered bad practice in the wider world?

I'm certain there are those who frown on this, but you shouldn't take them too seriously (unless you have to - say - for work). There are multiple forces that you want to balance. Sure, you don't want to put too many different things in one file, but then you don't want to have too many files. Similarly, you may not want to have too many files in one directory, but then you don't want to have too many directories either.

Personally, rather than having a file called "FrameTimer.h", I'll probably have a file called "Timers.h" that defines a system timer and a frame timer that uses it. I might have something like "NetworkConnections.h", which defines both a network connection management system object, and the network connection objects it manages.

There may be times when I'll put several related classes in one header for cohesive browsing, but break implementations out into multiple files. Implementations are much larger, after all.

And let's not forget that not every function ever written will belong to a class. A file along the lines of "Math.h" will probably contain a collection of classes and loose functions.

[Codarki]

I'm sorry I have to disagree again with you VReality. I'd advise to put headers into their own files, and share the implementation in single cpp if you must. Low granularity on headers will cut the include chain, and having all implementation in single cpp file might imporpve link time optimization. Compile time will be shorter (unity build). But it will get messy.

Having a class in single header and single implementation is clear when you have a lot of code.

Btw, there was a bench in internet that 60% of compile time went for writing the .bdp file, and when they split the project all went fast. It wasn't about include chains or repeated opening of files.

[Codarki]

I'm talking from experience when our rebuild took over 30min.. and I got it under 10min.

[ApochPiQ]

Keep it polite and refrain from the personal jabs, please.

[VReality]

Low granularity on headers will cut the include chain, and having all implementation in single cpp file might imporpve link time optimization. Compile time will be shorter (unity build). But it will get messy.

Seems reasonable (if the shorter compile time you're referring to is for re-builds, and not incremental builds), but these techniques you're mentioning don't have much to do with the balanced approach you're disagreeing with.

Btw, there was a bench in internet that 60% of compile time went for writing the .bdp file, and when they split the project all went fast. It wasn't about include chains or repeated opening of files.

You mean splitting every class out to its own pair of files, as compared to shoving everything into only a couple files? Both seem needlessly extreme for practical use. It doesn't seem surprising that they saw improved compile times if they were testing a typical incremental-code-change-and-build pattern of work. Smaller files mean compiling less code per change.

I'm talking from experience when our rebuild took over 30min.. and I got it under 10min.

By splitting the project code up into two files per class? You seem to be contradicting your prediction above, that bundling everything together will make a full rebuild faster.

[Codarki]

There may be times when I'll put several related classes in one header for cohesive browsing, but break implementations out into multiple files.

I'd advise to put headers into their own files, and share the implementation in single cpp if you must.

This was my disagreement.

Low granularity on headers will cut the include chain, and having all implementation in single cpp file might imporpve link time optimization. Compile time will be shorter (unity build). But it will get messy.

Seems reasonable (if the shorter compile time you're referring to is for re-builds, and not incremental builds), but these techniques you're mentioning don't have much to do with the balanced approach you're disagreeing with.

This was my reasoning why one should prefer to put multiple classes in implementation file instead of header file, if you have a good reason to do so. Personally I usually put classes in their own files.

Btw, there was a bench in internet that 60% of compile time went for writing the .bdp file, and when they split the project all went fast. It wasn't about include chains or repeated opening of files.

You mean splitting every class out to its own pair of files, as compared to shoving everything into only a couple files? Both seem needlessly extreme for practical use. It doesn't seem surprising that they saw improved compile times if they were testing a typical incremental-code-change-and-build pattern of work. Smaller files mean compiling less code per change.

No, I meant they split the project. Most of their time went constructing the .bdp file. Splitting it allowed them the build to multithread better.

I'm talking from experience when our rebuild took over 30min.. and I got it under 10min.

By splitting the project code up into two files per class? You seem to be contradicting your prediction above, that bundling everything together will make a full rebuild faster.

No. I'd advice not to bundle everything together, unless you have good reason to do so (ie if you must). I didn't fix it by unity builds. I fixed it by removing excessive includes of headers.