[green7ea]

I remember using it all the time for the Windows headers because they pollutes the compilation unit like you wouldn't believe — the rule was to only include them in c/cpp files.

[maccard]

We put

    #define WIN32_LEAN_AND_MEAN 1
    #include <windows.h>

In precompiled headers to solve that particular problem.

[silon42]

That's kind of a hack, still best only used in implementation files, not headers.

[whizzter]

The irony is that including/using many standard c++ headers is far far more expensive than including a lean windows.h these days.

To make hobby-coding fun, i use a mstdp.hpp that implements "naive" versions of unique,shared,function,etc that compiles faster than including just one of the std versions (and yes, MSVC versions of those libraries seem to be excessivly complex).

[pjmlp]

Not when using modules, which I have moved into on hobby projects.

The import std is much faster than plain #include<iostream>.

[maccard]

This is a fair point. Last time I tried modules in anger, it wasn't viable. Cmake didn't support them (well, they were experimental), intellisense didn't work and there were many ICE's in MSVC.

Maybe it's time to move my hobby project over and see how well it works.

[pjmlp]

I give you that Intelisense is broken as always, and the best experience appears to be with Clion, but I can live with it.

Best experience is VC++ with MSBuild, cmake/ninja work great with latest clang however import std support is not yet enabled by default in CMake.

I only care about VC++ for hobby coding, hence using modules.

See for example, https://github.com/pjmlp/RaytracingWeekend-CPP

[maccard]

That may be true, but it's a "hack" that has caused me approximately 1 issue in 15 years of writing C++ professionally, and that issue was a problem with our build system not the precompiled header.

> Still best only used in implementation files, not headers.

We only compile implementation files!