Congratulations to our 2022 Qt Champions!

Inheriting from QObjectPrivate

  • Hi all!
    I am creating a library with a large class hierarchy based on QObject and all its savvy features. However, I'm worried about the overhead of dynamic memory allocation for the private (d_ptr/pimpl) class. I would rather have my own Class/ClassPrivate that would respectively inherit QObject/QObjectPrivate and that could use custom allocators, so that I can tightly manage dynamic objects allocations. I could also provide some level of ABI compatibility for my library using this d_ptr/pimpl for myself alongside Qt.

    I know there is no guarantee about API and ABI compatibility of those private internal classes, but I don't really care since my only plan is to inherit QObjectPrivate and not use any of its API, apart from its default constructor. I do not care about rebuilding the library with new versions of Qt.

    Does anyone see a good reason not to attempt this? Thanks in advance!

  • Moderators

    In Qt5, you can include private headers with QT += core-private added to your .pro file.

    I'm not sure why you are so concerned about it. All Qt uses QObjects intensively, and it works quite well :) IIRC, you can create your own PIMPL implementations with Q_Q etc. macros without access to QObjectPrivate.

  • Doesn't inheriting from anything in the private parts of the library create the possibility of breaking your binary compatibility with any future version of Qt?

  • Moderators

    Headers are private for a reason. If you choose to use them, you are doing it on your responsibility. There is no promise of any compatibility for private APIs, even between patch releases. Of course, in real life, most of the code will stay the same for long periods of time.

    There is nothing inherently wrong about it, you just need to recompile your project every time you update the libraries, and be very careful to use right version with your application, including user machines.

Log in to reply