D pointers for beginner
-
Hi,
I'm newbie for Qt. But I have to work in a Qt project which is written using d-pointers.
I felt difficulty of understanding it. Even the reason of using d-pointers.
I googled but not found a understandable article for Qt kid like me.
I already read "d-pointer":http://qt-project.org/wiki/Dpointer but not got what I want.Can anybody help me to understand it?
Thanking in advance.
-
the article you mentioned gives a pretty good complete overview.
Maybe you can tell what exactly you didn't understand out of it.Main reasons why to use d-pointers:
- binary compatibility
- separation of public interface and actual implementation
-
@ raven-worx,
Thank you for reply me.
I again read that article. This time more clear than before. :)
I faced difficulty with understanding how breaks binary compatibility. Basically I can not understand what is meant by running without compile. And why compiler can not understand the changes of the Lib as long as use same name for variables.
If a size change cause a problem how append things to private member without changing the size?
These are unclear for me.
Thanks again. I'll going to read again. :)
-
The thing you really need here is understanding of how linking works.
A short example: imagine that Qt is not using PIMPL (d-pointers). We release a new version, say Qt 7.1, and we add this to QWidget:
@
QString printSomeStuff();
QString someStuff;
@You application (say, MyApp) has been compiled and linked against Qt 7.0. This means that your application has, inside it, a reference to a library named QtWidgets.dll (assuming we are on Windows), which contains certain methods. Now, to improve performance, the linker only stores references (memory addresses!) of all the methods inside the library. If any of those addresses changes, MyApp will not be able to find the method inside the DLL.
And when you add data to the DLL (by adding a method or member), the compiler can change the memory layout, thus breaking the compatibility. That is meant by binary compatibility. It's all about the fact that your application (and other libraries etc.) do not store method names by name, but by address. This is good for performance, but bad for compatibility.
Of course, this is a very simplified description, but I hope it will help you get the overall picture.
