The PImpl idiom and the C++26 std:indirect type

Re:The PImpl idiom and the C++26 std:indirect type by whizzter on Friday July 24, 2026 @06:15AM (#49033415)

Where are we with modules, isn't pimpl there largely to avoid costs related to including the world?

I was pondering on why he was putting the defaulted methods in the cpp, any particular reasons?

I did realize that the indirect version is required to be in the cpp since the header won't know how to copy without knowing the definition of the impl class.

[ Parent | on HN ]

Re:The PImpl idiom and the C++26 std:indirect type by ghosty141 on Friday July 24, 2026 @06:38AM (#49033599)

pimpl helps more since its trivially implementable in existing codebases while modules are a much bigger pain.

[ Parent | on HN ]

Re:The PImpl idiom and the C++26 std:indirect type by cemdervis on Friday July 24, 2026 @07:02AM (#49033800)

pimpl also helps to keep data structure layout stable, e.g. Qt's d-pointer convention

[ Parent | on HN ]

Re:The PImpl idiom and the C++26 std:indirect type by knorker on Friday July 24, 2026 @07:06AM (#49033837)

pimpl also makes it much easier to make changes without breaking ABI. E.g. shared libraries.

[ Parent | on HN ]

Re:The PImpl idiom and the C++26 std:indirect type by pjmlp on Friday July 24, 2026 @10:06AM (#49035882)

Even with modules, if you expose such types over the ABI, naturally the machine code memory layout will change, this is an issue regardless of the language.

[ Parent | on HN ]

Re:The PImpl idiom and the C++26 std:indirect type by binary132 on Friday July 24, 2026 @02:25PM (#49039729)

The article explains why, indirect and unique_ptr are templated and require the complete definition of the type, and the default impls of those methods use methods of the templated types.

[ Parent | on HN ]