> If you don't care about heap allocations then why are you using C++ :)
Because more often than not it is a made-up problem that at best is classified as premature optimization.
Take, for example, Qt and how it uses it's UI form classes. You can include it's autogenerated code by composition, inheritance, and through a pimpl. You are here complaining that everyone should care about heap allocations. Well, in this case they happen only at app start and behind a standard C++ smart pointer, and it's basically only used to instantiate a factory to create UI elements.
Can you tell me exactly any concrete reason why anyone should care about instantiating a few bytes in the heap with a smart pointer at app start?
Sometimes there are real problems,but sometimes there are made-up problems that have no relevance or meaning.
I've had to deal with fragmentation at some point or another across most titles I've shipped or larger programs. Small allocations are actually worse in some ways because they incur a lot of fine-grained fragmentation. My favorite was logic in a fairly well-known game engine that would allocate a generic name for an entity and then immediately rename it to something unique. That 5 byte allocation would be left behind multiplied by every entity cost us ~30mb of a 256mb fixed memory address space.
If you don't deal in those sorts of domains that's fine but don't dismiss them as those are some of the primary use cases for native languages. Pimpl is a hack, it's a clever hack in the context of C++ but it's not something intrinsic to native development. For instance it's a non-concern for languages like Rust(which just handle this whole domain much better due to not having to inherit a bunch of legacy behavior).
There's a bunch of feedback in adjacent threads that you seem to be ignoring so I suspect I won't change your mind here but I would encourage you to be a bit more open and consider that there are use cases where things like this matter rather than dismissing them offhand.
> Exactly this. Pimpl idiom is just a bandaid and typically goes against the main benefits of the language.
No, not really. The pimpl idiom is a basic technique that is employed to "improve the software development lifecycle", which is a description straight from Microsoft.
Even Microsoft's Herb Sutter himself has quite a few articles on the virtues of pimpls and how to implement them.
If you think they are wrong, are you planning on reaching out to them to correct them and to try to educate them on the matter? That would be something.
Herb Sutter's main discussions on this are nearly 15 years old lol. Like I said above, pimpl went out of style maybe a decade ago due to advancements in language design, learning about its flaws, etc.
This is a meaningless statement. As others in this discussion already stated repeatedly, pimpl is a very basic and fundamental C++ idiom that is pervasive in all application, and some frameworks are notorious for using them extensively even right now, as is the case of Qt.
At most, all you can claim is that you developed an irrational dislike of pimpls, but developers are renowned for making poor decisions and even introducing bugs, so it's worth what it's worth. I mean, some developers even in this day and age still complain about the whole notion of design patterns. Are these blends of opinions worth taking into consideration?
You asked "which ones?", I answered with some drawbacks to note, mentioned there are pros and cons, answered your question (with links you didn't fully read).. and you proceeded to go on a defensive tirade accusing me of noise and baseless claims (while you reference deprecated language features), etc. Have a nice day.
