D-Pointer

D-Pointer简介

如果你经常阅读QT的源码,你会看到大量的Q_D和Q_Q宏.这篇文章将会揭开这些宏的用处.这些宏是d-pointer设计模式的一部分,此设计模式可以把库的设计实现细节对用户隐藏,当对实现细节进行修改更正时不会打破库的二进制兼容性.

二进制兼容性简介

在设计像QT这种规模的库时,理想的状态应该是:动态链接到Qt库的应用程序,在Qt库升级或替换后不需要重新编译就可以继续运行.例如,你的CuteApp程序是基于Qt4.5的,你应该可以把qt库从4.5更新到4.6,而此时你的CuteApp依旧可以继续正确运行.

什么会打破二进制兼容?

类库发生何种变化时会打破二进制兼容呢?我们来看个简单的例子:

class Widget
{
private:
    Rect m_geometry;
};

class Label : public Widget
{
public:
    String text() const 
    {
        return m_text;
    }
private:
    String m_text;
}

此时,我们有一个Widget,它含有一个geometry作为成员变量.编译并发布widget为WidgetLib1.0.
当制作WidgetLib1.1时有人提出要加入stylesheets功能.没问题,我们只需要加入新的成员变量和新的成员函数就行了.

 class Widget
 {
 private:
     Rect m_geometry;
     String m_stylesheet; // NEW in WidgetLib 1.1
 };
 
 class Label : public Widget
 {
 public:
     String text() const
     {
         return m_text;
     }
 private:
     String m_text;
 };

我们发布WigetLib1.1,新版本仅仅包含上面的变化,却发现和WidgetLib1.0一起正常工作的CuteApp光荣的崩溃了...!

为何CuteApp会崩溃?

因为我们添加了一个新的成员变量,我们就改变了Widget和Label对象的大小.这又有什么关系呢?当C++编译器产生代码时,它使用偏移量(offset)来访问对象中的数据.下图是一个简单的POD对象内存布局图:

Label object in WidgetLib1.0	Label Object in WidgetLib1.1
m_geometry<offset 0>	m_geometry<offset 0>
---	m_stylesheet<offset 1>
m_text<offset 1>	---
---	m_text<offset 2>

在WidgetLib1.0中m_text的偏移量是1,在编译器生成的代码中成员函数Label::text()被翻译为访问Label对象偏移量1的位置.在WidgetLib1.1中,Label对象的m_text成员的偏移量变成了2.由于应用程序没有重新编译,他仍然认为m_text的偏移位置为1,结果却访问了m_stylesheet变量.

此时肯定有人会问,为什么Label::text()的偏移计算工作会在CuteApp的二进制文件中而不是在WidgetLib的二进制文件中呢?这是因为Label::text()是在头文件中定义的内联函数.如果Label::text()不再写成内联函数,把Label::text()转移到cpp文件中,情况会发生改变么?

不会.c++编译器依赖对象的大小在编译时和运行时是一样的.例如堆栈操作 - 如果你在堆栈上创建一个Label对象,编译器产生的在堆栈上分配空间的代码是基于Label在编译时的大小的,由于WidgetLib1.1中Label对象的运行时大小已经发生改变,Label的构造函数会覆盖堆栈数据导致堆栈崩坏...

不要改变C++导出类的大小

总结:一旦你的库发布后,不要再改变导出的C+ +类的大小和布局(不要随便移动数据成员的前后次序).C+ +编译器生成的代码会假定一个类的大小和数据成员的顺序编译后就不会变化.

那么如何在不改变对象的大小的前提下添加新功能呢?

d-pointer

要想保持所有的导出类的大小不变的诀窍是只存储一个指针.这个指针指向一个包含所有数据的私有/内部数据结构.这个内部数据结构的大小可以增大或缩小,而不会对应用程序产生副作用,因为这个指针只会被类库代码访问,从应用程序的角度来看对象的大小并没有改变--它永远是指针的大小.

这个指针就叫d-pointer.这个模式的精髓可以用以下代码来概述:

widget.h

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

widget_p.h

struct WidgetPrivate
{
    Rect geometry;
    String stylesheet;
};

widget.cpp

#include "widget_p.h"
#include "widget.h"

Widget::Widget():d_ptr(new WidgetPrivate)
{
    
}
Rect Widget::geometry()const
{
    return d_ptr->geometry;
}

label.h

struct LabelPrivate;
class Label:public Widget
{
    String text();
private:
    LabelPrivate* d_ptr;
};

label.cpp

struct LabelPrivate
{
    String text;
}
Label::Label()d_ptr(new LabelPrivate)
{
    
}
String Label::text()
{
    return d_ptr->text;
}

CuteApp从来不会直接访问d-pointer.由于d-pointer只会在WidgetLib中被访问,并且每次发布WidgetLib都会重新编译,私有类可以自由变化而不影响CuteApp.

d-pointer的其他好处:

• 隐藏实现细节 -- 发布WidgetLib的时候只需要头文件和二进制文件,源文件可以使闭源的代码.
• 头文件很干净整洁,不包含实现细节,可以直接作为API参考.
• 由于实现细节全部在cpp中,头文件中仅有一个指针,编译速度会更快.

不过以上好处都是微乎其微的,Qt要使用d-pointer的真正原因是为了保持二进制兼容性,和最开始Qt是闭源的.

q-pointer

到目前为止我们看到的d-pointer都是C语言风格的结构体.实际上他们是含有私有方法的(辅助函数).很多时候这些辅助函数需要访问共有类,也就是Label或者他的父类Widget的一些函数.比如辅助函数 setTextAndUpdateWidget() 想要调用Widget的共有方法Widget::update().所以WidgetPrivate可以存储一个指向共有类的指针,称为q-pointer.

widget.h

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

widget.cpp

struct WidgetPrivate
{
    WidgetPrivate(Widget* q):q_ptr(q){}
    
    Widget* q_ptr;
    Rect geometry;
    String stylesheet;
};


Widget::Widget():d_ptr(new WidgetPrivate(this))
{
    
}
Rect Widget::geometry()const
{
    return d_ptr->geometry;
}

label.h

struct LabelPrivate;
class Label:public Widget
{
    String text()const;
private:
    LabelPrivate* d_ptr;
};

label.cpp

struct LabelPrivate
{
    LabelPrivate(Label*q):q_ptr(q){}
    Label* q_ptr;
    String text;
};
Label::Label() : d_ptr(new LabelPrivate(this))
{
    
}
String Label::text()
{
    return d_ptr->text;
}

利用继承来优化d-pointer

在上面的代码中,创建一个Label对象导致了LabelPrivate和WidgetPrivate的内存分配.如果我们在Qt中采用这种策略,情况就可能变得恶化.例如QListWidget - 它有六层的继承层次,会导致6次内存分配.

我们可以通过为私有类提供一个继承层次来解决.

widget.h

class Widget{
public:
    Widget();
protected:
    Widget(WidgetPrivate& d);
    WidgetPrivate* d_ptr;
};

widget_p.h

struct WidgetPrivate
{
    WidgetPrivate(Widget* q):q_ptr(q){}
    Widget* q_ptr;
    Rect geometry;
    String stylesheet;
}

widget.cpp

Widget::Widget():d_ptr(new WidgetPrivate(this))
{
    
}
Widget::widget(WidgetPrivate& d):d_ptr(&d)
{
}

label.h

class Label:public Widget{
public:
    Label();
protected:
    Label(LabelPrivate& d);
};

label.cpp

class LabelPrivate:public WidgetPrivate
{
public:  
    String text;
};
Label::Label()
    :Widget(*new LabelPrivate)
{
}
Label::Label(LabelPrivate& d):Widget(d)
{
    
}

当我们创建Label对象时,他会创建一个LabelPrivate(继承自WidgetPrivate).它传递一个正确的d-pointer到Widget的保护构造函数.现在当创建Label的时候只有一次内存分配.Label也有一个保护构造函数,可以被它的子类继续拿来使用.

Q_D 和 Q_Q

经过上一步的继承优化后产生的一个副作用是: q_ptr和d_ptr的类型分别是Widget和WidgetPrivate,这意味着下面的代码将无法工作:

void Label::setText(const String& text)
{
    d_ptr->text = text;
}

因此,在子类中方位d_ptr需要static_cast到适当的类型.

void Label::setText(const String& text)
{
    LabelPrivate*d = static_cast<LabelPrivate*>(d_ptr);
    d->text = text;
}

正如所见,如果到处都带着static_cast会很麻烦.所以我们要使用src/corelib/global/qglobal.h中定义的两个宏来完成这个工作.
global.h

#defind Q_D(Class) Class##Private* const d = d_func()
#define Q_Q(Class) Class* const q = q_func()

Label.cpp

void Label::setText(const String& text)
{
    Q_D(Label);
    d->text = text;
}
void LabelPrivate::someHelperFunction()
{
    Q_Q(Label)
    q->selectAll();
}

Q_DECLARE_PRIVATE 和 Q_DECLARE_PUBLIC

qglobal.h

#define Q_DECLARE_PRIVATE(Class)\
    inline Class##Private* d_func() {\
        return reinterpret_cast<Class##Private*>(qGetPtrHelper(d_ptr));\
    }\
    inline const Class##Private* d_func() const {\
        return reinterpret_cast<const Class##Private *>(qGetPtrHelper(d_ptr));\
    }\
    friend class Class##Private;

PIMPL模式 : point to implementation