In many places in the implementation, we use the Public class, paying for the d-pointer allocation, when the Private class would do.

An example where we use the Private class is QCryptographicHash::hash() which creates a Private on the stack instead of the full Public class, saving a memory allocation and, in the form of hashInto(), even allowing to mark the operation noexcept.

Elsewhere, we happily pay the price for the d-pointer allocation, even though, with a bit of method shuffling, the Private would do just as well.

Two recent examples are QLocale use in QSystemLocale (for the fall-backs, where a QLocalePrivate would do, one supposes) and QDir's use of QDirListing instead of QDirListingPrivate.

This being an epic, we should have one task per class identified.

Each task would be about the following:

• "prop up" the Private so it can be used in lieu of the Public:
  • move some implementation there from the Public
    • in extreme cases, the Private class would carry almost all the API and the Public methods would all just go d->doX();.
  • if the implicit sharing requires some locking, split functions into locked and unlocked versions so the Private user can choose whether they have to pay for the mutex or not (cf. QCryptographicHash)
• use Private instead of Public in implementation:
  • as a temp variable (easiest)
  • as a member of another class
  • what will not work is doing this for QObject subclasses, as they have an identity as-a QObject that's user-visible (by walking the parent-child tree).

In general, such uses should be limited to the module the component is defined in, otherwise, as Volker noted, we'll add extra work for submodule integration.