6 ms·

It strikes me as something of a language flaw that without pimpl any addition/removal/ modification of private member functions, or even renaming of private mem

It strikes me as something of a language flaw that without pimpl any addition/removal/ modification of private member functions, or even renaming of private member variables triggers full recompilation of every source file that needs to use a particular class. I understand that changes to the size of the object should do so (even if it's just new private member variables), but if it can be determined by the rules of the language that a particular change to a class definition can't possibly affect other compilation units that happen to use that class, then why can't the compiler automatically determine no recompilation is necessary e.g. by calculating and storing a hash of everything about a class that can potentially have an external effect and comparing that value rather than relying on timestamps...

BenFrantzDale 3y ago
If your internal representation is stable, you can put private functions in a private friend class that is only defined in the cpp file: `private struct access; friend struct access;`.
- wizofaus 3y ago
  Interesting idea, can't say I've used that pattern used, and obviously the code will end up slightly more verbose (no automatic "this" argument) but in principle could be better than the pimpl technique.
rewmie 3y ago
> strikes me as something of a language flaw that without pimpl any addition/removal/ modification of private member functions, or even renaming of private member variables triggers full recompilation of every source file that needs to use a particular class. It is not a language flaw. C++ requires types to be complete when defining them because it needs to have access to their internal structure and layout to be in a position to apply all the optimizations that C++ is renowned for. Knowing this, at most it's a design tradeoff, and one where C++ came out winning. For the rare cases where these irrelevant details are relevant, C++ also offers workarounds. The pimpl family of techniques is one of them, and type erasure techniques are also useful, and protocol classes with final implementations are clearly another one. Nevertheless, the fact that these techniques are far from being widely used demonstrates that there is zero need to implement them at the core language level.
- jstimpfle 3y ago
  There isn't a good reason why private methods should be exposed in the header. This makes refactoring the class implementations much more of a pain in the butt than plain structs + global functions. You can always add internal functions to the implementation without causing a reimplementation of all dependencies, while you can't do the same with private methods. And private methods aren't exactly "rare cases". The situation is bad to the point that most good codebases make less use of classes, and many average code bases avoid adding private methods and resort to code duplication to a degree.
  - wizofaus 3y ago
    Private methods do need to be in some sort of privileged "single source of truth" for the class definition though - if you were permitted to have a partial class definition in the "public" header file that defined public/protected methods plus all variables, then a single other partial class definition in a separate header or compilation unit it would go some easy towards solving the issue. But I still don't quite see why compilers can't make assumptions about what changes to class definitions can possibly require recompilation of other compilation units (even if it only applies at certain optimisation levels).
    - jstimpfle 3y ago
      Private methods, unless they are virtual, do not to my knowledge have any bearing on the ABI of a class, nor need they be known to users of the class, so listing them in the class declaration seems nonsensical. The reason why they have to be listed anyway could be 1) a vague idea of "consistency" with e.g. public methods and generally the enforcing access control only centrally from the class declaration 2) the idea of overriding the implementation in an inherited class. As far as I'm concerned, both are bad reasons to impose such an annoying limitation to the user of the language.
      - wizofaus 3y ago
        The whole point of private methods is that they have privileged access to the implementation details of the class (i.e. private member variables and other private methods). So there still needs to be a restricted place they can be defined - what are you proposing?

BenFrantzDale 3y ago

If your internal representation is stable, you can put private functions in a private friend class that is only defined in the cpp file: `private struct access; friend struct access;`.

wizofaus 3y ago
Interesting idea, can't say I've used that pattern used, and obviously the code will end up slightly more verbose (no automatic "this" argument) but in principle could be better than the pimpl technique.

rewmie 3y ago

> strikes me as something of a language flaw that without pimpl any addition/removal/ modification of private member functions, or even renaming of private member variables triggers full recompilation of every source file that needs to use a particular class. It is not a language flaw. C++ requires types to be complete when defining them because it needs to have access to their internal structure and layout to be in a position to apply all the optimizations that C++ is renowned for. Knowing this, at most it's a design tradeoff, and one where C++ came out winning. For the rare cases where these irrelevant details are relevant, C++ also offers workarounds. The pimpl family of techniques is one of them, and type erasure techniques are also useful, and protocol classes with final implementations are clearly another one. Nevertheless, the fact that these techniques are far from being widely used demonstrates that there is zero need to implement them at the core language level.

jstimpfle 3y ago
There isn't a good reason why private methods should be exposed in the header. This makes refactoring the class implementations much more of a pain in the butt than plain structs + global functions. You can always add internal functions to the implementation without causing a reimplementation of all dependencies, while you can't do the same with private methods. And private methods aren't exactly "rare cases". The situation is bad to the point that most good codebases make less use of classes, and many average code bases avoid adding private methods and resort to code duplication to a degree.
- wizofaus 3y ago
  Private methods do need to be in some sort of privileged "single source of truth" for the class definition though - if you were permitted to have a partial class definition in the "public" header file that defined public/protected methods plus all variables, then a single other partial class definition in a separate header or compilation unit it would go some easy towards solving the issue. But I still don't quite see why compilers can't make assumptions about what changes to class definitions can possibly require recompilation of other compilation units (even if it only applies at certain optimisation levels).
  - jstimpfle 3y ago
    Private methods, unless they are virtual, do not to my knowledge have any bearing on the ABI of a class, nor need they be known to users of the class, so listing them in the class declaration seems nonsensical. The reason why they have to be listed anyway could be 1) a vague idea of "consistency" with e.g. public methods and generally the enforcing access control only centrally from the class declaration 2) the idea of overriding the implementation in an inherited class. As far as I'm concerned, both are bad reasons to impose such an annoying limitation to the user of the language.
    - wizofaus 3y ago
      The whole point of private methods is that they have privileged access to the implementation details of the class (i.e. private member variables and other private methods). So there still needs to be a restricted place they can be defined - what are you proposing?