Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. D-Pointer for Custom Classes

D-Pointer for Custom Classes

Scheduled Pinned Locked Moved Solved General and Desktop
4 Posts 3 Posters 76 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Z Offline
    Z Offline
    ZNohre
    wrote last edited by
    #1

    All,

    Should I be using the D-Pointer approach for all of my custom classes?

    As I was reviewing some test output I came across the below in the "General Messages" section of the IDE:

    Project MESSAGE: This project is using private headers and will therefore be tied to this specific Qt module build version.
    Project MESSAGE: Running this project against other versions of the Qt modules may crash at any arbitrary point.
    Project MESSAGE: This is not a bug, but a result of using Qt internals. You have been warned!
    

    Reviewing the source code from time to time I had come across this concept but now that I'm seeing these output messages I'm realizing maybe I should have done this on my custom classes as well (including my subclasses of QObjects). Apologies in advance if this is a novice question I should have known earlier.

    Pl45m4P 1 Reply Last reply
    0
    • Z ZNohre

      All,

      Should I be using the D-Pointer approach for all of my custom classes?

      As I was reviewing some test output I came across the below in the "General Messages" section of the IDE:

      Project MESSAGE: This project is using private headers and will therefore be tied to this specific Qt module build version.
      Project MESSAGE: Running this project against other versions of the Qt modules may crash at any arbitrary point.
      Project MESSAGE: This is not a bug, but a result of using Qt internals. You have been warned!
      

      Reviewing the source code from time to time I had come across this concept but now that I'm seeing these output messages I'm realizing maybe I should have done this on my custom classes as well (including my subclasses of QObjects). Apologies in advance if this is a novice question I should have known earlier.

      Pl45m4P Offline
      Pl45m4P Offline
      Pl45m4
      wrote last edited by Pl45m4
      #2

      @ZNohre

      The one thing does not have to do with the other.
      You see the message / warning because you seem to have Qt private headers included in your project, like qsomething_p.h.
      This makes YOUR project coupled to your current Qt version as Qt internals might change without any notice... because it's not part of the public API and nothing that it is recommended to use... however you still can...

      on the other side you have the pImpl approach, which, in fact also relates to Qt's private headers because this is where the private data of all widgets is defined/stored, but it's more a general programming approach i.e. to design a library.
      To simply subclass and modify a widget, you don't need that (or for any QObject subclass)
      If you make your own widget from scratch and plan to export it as shared library, it is worth considering to follow the approach using d_ptr.


      If debugging is the process of removing software bugs, then programming must be the process of putting them in.

      ~E. W. Dijkstra

      1 Reply Last reply
      4
      • SGaistS Offline
        SGaistS Offline
        SGaist
        Lifetime Qt Champion
        wrote last edited by
        #3

        Hi,

        As @Pl45m4 pointed out, it's mainly useful if you want to provide a library that has API and ABI guarantees while keeping the possibility to modify its internals without requiring your users to rebuild everything.

        Interested in AI ? www.idiap.ch
        Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

        1 Reply Last reply
        1
        • Z Offline
          Z Offline
          ZNohre
          wrote last edited by
          #4

          @Pl45m4 and @SGaist thank you for the guidance here. I'll review my code and leave a final post if there is anything useful as I troubleshoot where the private headers were included if others have this issue.

          1 Reply Last reply
          0
          • Z ZNohre has marked this topic as solved

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved