5 ms·
I'm inclined to agree that for objects that are going to be created and destroyed very often, especially in tight loops, PIMPL is not an ideal idiom. I wouldn't
by hellofunk 10y ago
I'm inclined to agree that for objects that are going to be created and destroyed very often, especially in tight loops, PIMPL is not an ideal idiom. I wouldn't use it to generate fleeting effects in graphics, for example.
For objects that are used in setting up parts of a system and that will persist for long periods of time, maybe even the lifetime of the app, PIMPL is particularly well-suited for such classes. Classes that might manage networking, or encompass an entire part of app's running architecture, etc.
- hendzen 10y agoThw complexity and overheead of PIMPL is justified in one scenario, and one scenario only - when you are writing a shared library and need to maintain a stable ABI. Otherwise it is complete overkill.