You need to have split your functionality into about 20 different DLLs before you get to the point of being an oh-god-why-is-it-so-massive project.
How does separating out code into DLLs help? Linking is fast.
You must write most of your objects using the interface pattern (a pure virtual interface in the header file, and your implementation exclusively in the source file).
This is something which you should always do -- not just for large C++ projects. Separating interfaces from implementations is ALWAYS good design.
Unfortunately, no. The linking step at work is the most time-consuming. Visual Studio takes four minutes (and growing) to link the client, no matter how small the change.
By the way, do you have any samples of C code from your project I could read? I'm writing my game engine in C, so I try to learn as many different C styles as I can.
I totally agree with the breaking up of the project to smaller DLLs, as long as you write your tests for each DLL separately it can save a great deal of time, as you only have to recompile the DLL&test with the bug-fix.
How does separating out code into DLLs help? Linking is fast.
You must write most of your objects using the interface pattern (a pure virtual interface in the header file, and your implementation exclusively in the source file).
This is something which you should always do -- not just for large C++ projects. Separating interfaces from implementations is ALWAYS good design.