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).
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.
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.
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).
Not when using modules, which I have moved into on hobby projects.
The import std is much faster than plain #include<iostream>.
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.
2 replies →
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!