5 ms·

under what circumstances does (2) hold? for vanilla methods it's no problem

• loeg 3y ago
  If you touch a header, even private only, includers will rebuild. Modules might fix this.
• phkahler 3y ago
  >>> 2. Poor encapsulation, adding private functions requires recompiling all dependents >> under what circumstances does (2) hold? To add a private member variable or function, you need to put it in the class definition in the header file. Then anything that includes the header needs to be recompiled.
  • ThouYS 3y ago
    they don't need to be. dependents will continue functioning, because ABI hasn't changed
    • jstimpfle 3y ago
      Now explain that to my build system. But even if you managed to do that, first compilation is still much slower than it should be, because anlot of headers have to be included (transitively) to allow even declaring these fields and methods.
  • hkwerf 3y ago
    Admittedly, adding a private member variable changes the object size and thus the ABI and thus requires recompilation of dependencies. Thinking about that, is there any case in which private functions can end up in a vtable? In that case, it'd break ABI too.
    • NekkoDroid 3y ago
      > is there any case in which private functions can end up in a vtable? Yes, but it generally isn't something that is done. https://godbolt.org/z/5oPovKzoT https://godbolt.org/z/5oPovKzoT
• colonwqbang 3y ago
  C++ build systems are typically based on file timestamps. Modifying a header file triggers recompilation of all translation units including that header. There are workarounds like pimpl (aka. C style encapsulation). But this requires extra boilerplate and indirection. C++ modules might fix it at some point, but after 35 years of not having them in C++ most real life codebases aren't set up that way and may never be.
  • gumby 3y ago
    I don't think of pimpl as a tool for speeding up compilation, but for black box encapsulation. If the compile time (when adding a method) is really an issue you can chop up and reconfigure your include files. A pain, but perhaps saves you time in the long run. Of course (waves hands) modules will magically improve things...someday.
    • colonwqbang 3y ago
      I think it can be both things. Haven't you ever seen someone do struct Thing; struct OtherThing; in lieu of just including "thing.h"? I see it frequently in real life code bases and I can't see a reason for it other than compilation time optimisation.
      • gumby 3y ago
        Sure, I do that all the time too. But you can't call a method (or look inside Thing, or pass it as an argument, only a pointer to it) without including the definition. Hmm, there might be some interesting linker hacks to patch things up post compilation. But then you'd want some way to do the forward declaration for cases where Thing could have been passed in registers...
      • DerekL 3y ago
        This is sometimes required to break dependency cycles. Also, you can use this to rearrange declarations in the same file.
    • germandiago 3y ago
• jstimpfle 3y ago
  Adding private functions or fields requires changing the class declarations, which requires rebuilding any code that includes that class deckaration. It shouldn't be like that, especially for methods which shouldnt change anything about the class ABI. Even worse, this dependency is transitive. Dependencies to allow defining these private methods an fields are exposed too, forcing inclusion of headers to all members of the class, even if it's only implementation details.