Comment by zabzonk
4 days 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.
4 days 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.
It'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.
> 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.
Yes, it is a good fit when a customer is supposed to use some functionality one has implemented but shall not see the implementation.
This 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.
It 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.
They didn't add PImpl support, they added std::indirect which can be used for PImpl among other things.
Yes, if you actually care compile times.
Indeed. 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.
My 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.
Lucky for you, I don't.
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.
We put
In precompiled headers to solve that particular problem.
That's kind of a hack, still best only used in implementation files, not headers.
6 replies →
Back when I used to write C++ it was used all over the place. Admittedly that was a log time ago.
How you doin' fellow Qt-kids? ;)