4 ms·
Hmm. Do people use PIMPL that much (I have used it, but rarely) that we need std library support (and testing, documentation, understanding)? Just asking.
by zabzonk 3mo ago
Hmm. Do people use PIMPL that much (I have used it, but rarely) that we need std library support (and testing, documentation, understanding)? Just asking.
- neonz80 3mo agoThey didn't add PImpl support, they added std::indirect which can be used for PImpl among other things.
- seanhunter 3mo agoBack when I used to write C++ it was used all over the place. Admittedly that was a log time ago.
- jeffreygoesto 3mo agoHow you doin' fellow Qt-kids? ;)
- green7ea 3mo agoI 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 3mo agoWe put #define WIN32_LEAN_AND_MEAN 1 #include <windows.h> In precompiled headers to solve that particular problem.
- silon42 3mo agoThat's kind of a hack, still best only used in implementation files, not headers.
- whizzter 3mo agoThe 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 3mo agoNot when using modules, which I have moved into on hobby projects. The import std is much faster than plain #include<iostream>.
- maccard 3mo agoThis 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 3mo agoI 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 https://github.com/pjmlp/RaytracingWeekend-CPP
- maccard 3mo agoI've just spent an hour trying to set up import std to use std::print on MacOS. I got there, eventually with cmake + ninja. I hit an absolutely ludicrious number of errors for effectively a hello world, and I don't understand why in 2026 it is as complicated as it is. But, no ICEs and it's working! I'll start writing some code with them tomorrow.
- feverzsj 3mo agoYes, if you actually care compile times.
- RossBencina 3mo agoIndeed. I primarily used PIMPL when I want to avoid polluting public header files with implementation detail #includes in cases where forward declarations are impossible or unwieldy and inline methods are irrelevant.
- einpoklum 3mo agoMy approach to reducing the compile time of code which uses a class is moving the functionality out of the class and into standalone functions; or at least moving the method definitions into a non-header `.cpp` file.
- otabdeveloper4 3mo agoLucky for you, I don't.
- flohofwoe 3mo agoThis std::indirect thingie looks more like a general helper for any data 'dangling off' an object, not limited to pimpl. Not sure how much pimpl is used in reality, but it's a pretty ok solution to speed up build times (apart from unity builds), because it avoids having to include headers that are only needed for the private state into the public interface header.
- dvratil 3mo agoIt's often used in libraries where you need to guarantee ABI compatibility. Fixing a bug or implementing a feature may require adding a new member into the class, which would change its size (thus break ABI compatibility). PIMPL is the typical solution here, since the inner/impl class is not part of the public ABI. I also like to use it sometimes to "hide" private methods and their documentation into PIMPL, so the public header is kept clean.
- zabzonk 3mo ago> PIMPL is the typical solution here, since the inner/impl class is not part of the public ABI. Yep, that's what I've used it for. Didn't find it too difficult to implement it myself, but I guess every bit of convenience/bug avoidance helps.
- hasley 3mo agoYes, it is a good fit when a customer is supposed to use some functionality one has implemented but shall not see the implementation.
- daemin 3mo agoIt was used extensively at a former workplace of mine where each class that wasn't a message or data type was a pimpl. They had implemented their own private pointer class to handle it. It worked well enough to avoid pulling in lots of headers, but was still a PITA when you wanted to change methods as you'd always need to change the method signature in at least 3 places - header file declaration, source file definition, source file impl definition.