[quote name='Olof Hedman' timestamp='1316787459' post='4865154']
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.
[/quote]

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

On 9/22/2011 at 4:28 AM, BattleMetalChris said:

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.

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.

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

On 9/23/2011 at 6:56 PM, Ftn said:

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 by compile time you're only referring to full project re-builds), but that doesn't have much to do with the balanced approach you're disagreeing with.

On 9/23/2011 at 6:56 PM, Ftn said:

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 actual practice. It wouldn't be surprising that they saw improved compile times if they were testing the normal incremental code change pattern of work. It seems natural that compiling less code would take less time.

On 9/23/2011 at 7:10 PM, Ftn said:

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.

On 9/23/2011 at 6:56 PM, Ftn said:

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.

On 9/23/2011 at 6:56 PM, Ftn said:

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.

On 9/23/2011 at 7:10 PM, Ftn said:

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.

[quote name='VReality' timestamp='1317922223' post='4869836']
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.
[/quote]
This was my disagreement.

[quote name='Codarki' timestamp='1316829409' post='4865372']
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.
[/quote]
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.

[quote name='Codarki' timestamp='1316829409' post='4865372']
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.
[/quote]
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.

[quote name='Codarki' timestamp='1316830204' post='4865376']
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.
[/quote]
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.