Menu
The pimpl idiom, as far as I can tell, hides a private implementation behind a forward declared symbol name so it can be declared and used in the private cpp module.
Example: https://cpppatterns.com/patterns/pimpl.html
As far as I can tell, because the class hosint the pimpl needs to know about its structure (size, aligment), the pimpl must be indirect through a pointer of some sort.
(or allocated as a block of sufficient size then moved/created into the location where it is reinterpreted by cast later.)
Does the upcoming modules specification solve this in any way?
596
The PImpl Idiom (Pointer to IMPLementation) is a technique used for separating implementation from the interface. It minimizes header exposure and helps programmers to reduce build dependencies by moving the private data members in a separate class and accessing them through an opaque pointer.
"Pointer to implementation" or "pImpl" is a C++ programming technique that removes implementation details of a class from its object representation by placing them in a separate class, accessed through an opaque pointer: // -------------------- // interface (widget.
P0142R0
5.2.3 Exported Class Properties
An occasionally vexing rule of standard C++ is that of controls access, not visibil- ity. E.g. a private member of a class is visible to, but not accessible to non-member entities. In particular, any change to a private member of a class is likely to trigger e-processing of any translation unit that depends on that class’s definition even if the change does not affect the validity of dependent units. It is tempting to solve that problem with a module system. However, having two distinct sets of rules (visibility and accessibility) for class members strikes us as undesirable and poten- tially fertile source of confusion. Furthermore, we want to support mass-migration of existing codes to modules without programmers having to worry about class member name lookup rules: if you understand those rules today, then you do not have to learn new rules when you move to modules and you do not have to worry about how the classes you consume are provided (via modules or non-modules).
Rule 3 In general, any property of a class (e.g. completeness) that is computed in the export declaration part of a module is made available to importing modules as is.
As all properties of a class are visible to the importer, any change to those properties would be visible in the importer. I don't see modules solving the problem that PIMPL solves.
61
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
