But is that with or without link time code generation?

My dev build configurations always leave it off (partly because at least in the bit of experimentation I did, if I wanted to disable optimisations in any source file for easier debugging in an IDE, it seemed to be incompatible, and putting the debugger into fully optimised code is a pain that normally results in me using the disassembly view to get anywhere), and linking is a lot faster than my release builds.

I don't think that's a good reason to use dll's. It would probably be better to use other methods for these kinds of resources, the simplest being to just load the files directly from a subdir of the game directory.

Sorry I think I misrepresented what I was trying to say. My point being that loading the resources in a moderate size game project can be a reason for slow iteration times. One way I've got my iteration times down was to separate the light weight gameplay code into a separate DLL and only recompile and reload that part. I leave the resource manager running the whole time so it doesn't have to reload resources. This a quick way and pretty straight forward way of getting a "hot reload" working... I don't know how you would get hot-reload using static libs.

The biggest advantage for DLLs during development is iteration time. DLLs let you compile and link smaller chunks of the game and then get back into the game quicker, meaning you can test and iterate on your game faster. Which means you can make a better game with less time and money.

Even without a hot reload, iteration is quicker with dlls.

Nobody wants 2 minute link times just for simple one-line changes.

I have the same problems with link times in static link mode, so I rarely build those... but I like to keep them working so that I can use it as an optimised release build (with all the bells an whistles, LTCG e.t.c) I automate this using a TeamCity server, which is free and simple to setup in-case you are interested.

(Number of source files is pretty unimportant to the linker in any case. The linker scales by symbol count and code size, not by translation unit count, generally speaking. The worse case you can get into is having headers or the like that bloat symbol count per TU and then have a lot of TUs, giving a multiplicative effect, but... well, don't do that.)

This is a good point... and probably more important to keeping compile times low than using a dynamic or static lib config. I see pro-coders do this and it bugs me. I think people coming over from C# or Java tend to be the culprits.

...As a general rule, if a class is referenced in a header as a pointer or reference type then you don't need to include the header file with the declaration for the type. A simple forward declare is enough.

i.e. the following example would be found in header files...

//header includes

class CForwardDeclared;

//class declarations + codes

or you can do it in the code. (i personally like to do it this way)

class CSomeClass
{
public:
     CSomeClass(const class CSomeConstDataOrSomething& InData);
     const class CSomeConstDataOrSomething& Data;

    void SomeFunction(class CSomeOtherClass* ptr);
};

Same goes for template instantiation parameters

TWeakPtr<class CSomeClass> SomeClassPointer;

This also means that changes to the header files wont dirty any unecussary TU's which will just result in less compiling generally.

... but this will not help with linker times, so still better to use DLL's as well anyway.