about the d-pointer,adding an api function will lead to crash?

QtTester

Hi ,all.

according the wiki dpointer: https://wiki.qt.io/D-Pointer?msclkid=56fa4f8cc44611ec9a340614427a8872
the code:

 class WidgetPrivate;
 
 class Widget
 {
     // ...
     Rect geometry() const;
     // ... 
 
 private:
     WidgetPrivate *d_ptr;
 };

but ,if we add a new api, should above code work still?

 class WidgetPrivate;
 
 class Widget
 {
     // ...
     Rect geometry() const;
     // ... 
     int sum(); // new API
 private:
     WidgetPrivate *d_ptr;
 };

If not ,how about put the dpointer to the first place?

class WidgetPrivate;
 
 class Widget
 {
private:
    WidgetPrivate *d_ptr;
public:
     // ...
     Rect geometry() const;
     // ... 
     int sum(); // new API,will it work for compatible?
 private:
     // none
 };

Christian Ehrlicher

@QtTester said in about the d-pointer,adding an api function will lead to crash?:

but ,if we add a new api, should above code work still?

When you add a new function the memory footprint (and therefore layout) does not change - it's still X bytes in your case. 'Just' the order of functions may change when you don't add it at the back but even this doesn't matter since the loaded is resolving the symbols during runtime. The only problem is when you add a virtual function since then the size of the vtable changes and a derived class compiled against the older version will go havoc.

QtTester

@Christian-Ehrlicher
thanks for replying.
That's to say: add a new variable will increase the memory size,but an api will not?
is thera a link to show why?
And, if we add a virtual function just at the back ,will it work compatible?

Christian Ehrlicher

@QtTester said in about the d-pointer,adding an api function will lead to crash?:

That's to say: add a new variable will increase the memory size,but an api will not?

Yes because the object doesn't need more memory when a new function is added - why should it?

And, if we add a virtual function just at the back ,will it work compatible?

As I said above - adding a virtual function will kill your classes derived from this class.

Why do you have such a hard binary compatibility requirement? If you really have you should take a deeper look into this before starting. It's not that easy as it seems (and mostly not needed for simple projects).