D-Pointer for Custom Classes
-
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.
-
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.
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, likeqsomething_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 anyQObject
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. -