6 ms·

The article mentions forward declararions but does not mention the age-old pimpl idiom. https://en.cppreference.com/w/cpp/language/pimpl https://en.cppreferenc

by rewmie 3y ago

The article mentions forward declararions but does not mention the age-old pimpl idiom. https://en.cppreference.com/w/cpp/language/pimpl https://en.cppreference.com/w/cpp/language/pimpl Pimpl greatly reduce build times by removing includes from the interface header at the expense of requiring pointer dereferencing, and it's a tried and true technique. Another old school technique which still has some impact in build times is to stash build artifacts in RAM drives.

wiseowise 3y ago
I’ll never understand why C++ developers insist on using this ugly hack instead of using pure virtual interfaces.
- rewmie 3y ago
  What leads you to believe that protocol class + concrete implementations + factory can replace pimpls? I'm going to make it simple for you: take a Qt widget. You define its widget layout with Qt a designer, save a UI form file, and get Qt's UIC to generate a header file that implements that widget tree. You have three options to include the object in that header: either inherit from it, composition, and pimpl. So you swore off a pimpl. Pray tell, how do you use a Pure virtual interface in this case?
  - wiseowise 3y ago
    > What leads you to believe that protocol class + concrete implementations + factory can replace pimpls? What leads you to believe they can’t? > I'm going to make it simple for you: take a Qt widget. You define its widget layout with Qt a designer, save a UI form file, and get Qt's UIC to generate a header file that implements that widget tree. You have three options to include the object in that header: either inherit from it, composition, and pimpl. So you swore off a pimpl. Pray tell, how do you use a Pure virtual interface in this case? Never worked with Qt. Can you give me FooBar example where pimpl is superior to pure abstract class, please?
jb1991 3y ago
Pimpl has so many other drawbacks, though.
- rewmie 3y ago
  Which ones?
  - jb1991 3y ago
    There are discussions in many places about this, including right here on HN. I encourage you to Google it. Here are some examples: https://news.ycombinator.com/item?id=24537267 https://news.ycombinator.com/item?id=24537267 https://www.cppstories.com/2018/01/pimpl/#pros-and-cons https://www.cppstories.com/2018/01/pimpl/#pros-and-cons It used to be a widely advertised technique maybe a decade ago, but it has long gone out of style.
    - rewmie 3y ago
      I feel you're just adding noise to an otherwise interesting discussion. If all you have to add is handwave over "Pimpl has so many other drawbacks" and to reply "google them" when asked to substantiate your baseless claim, I feel it was preferable if you sat this discussion out. The noise you add is particularly silly as all your references point is the pointer dereferencing drawback I already pointed out and you claimed there were more.
      - vvanders 3y ago
        Heap fragmentation is another, pimpl works but it's really papering over limitations in the pre-processor and header model that leaks details to downstream consumers.
        rewmie 3y ago
        > Heap fragmentation is another For the rare cases where potential pimpl users care about heap allocations, there's a pimpl variant called fast pimpl with replaces the heap allocation with a opaque member variable that holds memory to initialize the impl object. Since C++11 the opaque object can be declared with std::aligned_storage.
TillE 3y ago
Pimpl is basically my default C++ style, with exceptions made when the teeny tiny bit of overhead might actually matter. It just feels great to be able to totally refactor the implementation without touching the header.
wizofaus 3y ago
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.
Blackthorn 3y ago
I'll be glad if I never have to see PIMPL ever again. It makes tracking down the actual implementation of some functionality so much harder than it has to be.
- rewmie 3y ago
  > I'll be glad if I never have to see PIMPL ever again. It makes tracking down the actual implementation of some functionality so much harder than it has to be. Not really. There are two main flavours of pimpls: one where the impl class is a pod that only holds member variables, and one where the impl class holds both member variables and private member functions. On both, the implementation can and does stay in the very same translation unit. On the former, the code stays in the very same class,without any change. You only experience the sort problems you describe if you bring them upon yourself. That's hardly the idiom's fault.
_0w8t 3y ago
The primary reason for Pimpl is to ensure binary compatibility for C++. QT uses it extensively precisely for this reason. Reduced compilation time is just a nice bonus.
- deleted 3y ago
  [deleted]
deleted 3y ago
[deleted]
malkia 3y ago
But you can't implement std::string with pimpl (and the small-string optimization), but I agree though - I wish there was a way somehow (?)

by rewmie 3y ago

wiseowise 3y ago

I’ll never understand why C++ developers insist on using this ugly hack instead of using pure virtual interfaces.

rewmie 3y ago
What leads you to believe that protocol class + concrete implementations + factory can replace pimpls? I'm going to make it simple for you: take a Qt widget. You define its widget layout with Qt a designer, save a UI form file, and get Qt's UIC to generate a header file that implements that widget tree. You have three options to include the object in that header: either inherit from it, composition, and pimpl. So you swore off a pimpl. Pray tell, how do you use a Pure virtual interface in this case?
- wiseowise 3y ago
  > What leads you to believe that protocol class + concrete implementations + factory can replace pimpls? What leads you to believe they can’t? > I'm going to make it simple for you: take a Qt widget. You define its widget layout with Qt a designer, save a UI form file, and get Qt's UIC to generate a header file that implements that widget tree. You have three options to include the object in that header: either inherit from it, composition, and pimpl. So you swore off a pimpl. Pray tell, how do you use a Pure virtual interface in this case? Never worked with Qt. Can you give me FooBar example where pimpl is superior to pure abstract class, please?

jb1991 3y ago

Pimpl has so many other drawbacks, though.

rewmie 3y ago
Which ones?
- jb1991 3y ago
  There are discussions in many places about this, including right here on HN. I encourage you to Google it. Here are some examples: https://news.ycombinator.com/item?id=24537267 https://news.ycombinator.com/item?id=24537267 https://www.cppstories.com/2018/01/pimpl/#pros-and-cons https://www.cppstories.com/2018/01/pimpl/#pros-and-cons It used to be a widely advertised technique maybe a decade ago, but it has long gone out of style.
  - rewmie 3y ago
    I feel you're just adding noise to an otherwise interesting discussion. If all you have to add is handwave over "Pimpl has so many other drawbacks" and to reply "google them" when asked to substantiate your baseless claim, I feel it was preferable if you sat this discussion out. The noise you add is particularly silly as all your references point is the pointer dereferencing drawback I already pointed out and you claimed there were more.
    - vvanders 3y ago
      Heap fragmentation is another, pimpl works but it's really papering over limitations in the pre-processor and header model that leaks details to downstream consumers.
      - rewmie 3y ago
        > Heap fragmentation is another For the rare cases where potential pimpl users care about heap allocations, there's a pimpl variant called fast pimpl with replaces the heap allocation with a opaque member variable that holds memory to initialize the impl object. Since C++11 the opaque object can be declared with std::aligned_storage.

TillE 3y ago

Pimpl is basically my default C++ style, with exceptions made when the teeny tiny bit of overhead might actually matter. It just feels great to be able to totally refactor the implementation without touching the header.

wizofaus 3y ago

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.

Blackthorn 3y ago

I'll be glad if I never have to see PIMPL ever again. It makes tracking down the actual implementation of some functionality so much harder than it has to be.

rewmie 3y ago
> I'll be glad if I never have to see PIMPL ever again. It makes tracking down the actual implementation of some functionality so much harder than it has to be. Not really. There are two main flavours of pimpls: one where the impl class is a pod that only holds member variables, and one where the impl class holds both member variables and private member functions. On both, the implementation can and does stay in the very same translation unit. On the former, the code stays in the very same class,without any change. You only experience the sort problems you describe if you bring them upon yourself. That's hardly the idiom's fault.

_0w8t 3y ago

The primary reason for Pimpl is to ensure binary compatibility for C++. QT uses it extensively precisely for this reason. Reduced compilation time is just a nice bonus.

deleted 3y ago
[deleted]

deleted 3y ago

[deleted]

malkia 3y ago

But you can't implement std::string with pimpl (and the small-string optimization), but I agree though - I wish there was a way somehow (?)