我可以知道C中不透明指针概念背后的用法和逻辑吗?
Answers:
不透明指针是一种不透露基础数据细节的指针(根据字典定义:opaque:形容词;无法透视;不透明)。
例如,您可以在头文件中声明(这来自我的一些实际代码):
typedef struct pmpi_s *pmpi;
它声明的类型pmpi
是指向不透明结构 的指针struct pmpi_s
,因此您声明的任何内容都pmpi
将是不透明的指针。
该声明的用户可以自由编写如下代码:
pmpi xyzzy = NULL;
不知道结构的实际“定义”。
然后,在了解定义的代码(即提供pmpi
处理功能的代码)中,可以“定义”结构:
struct pmpi_s {
uint16_t *data; // a pointer to the actual data array of uint16_t.
size_t sz; // the allocated size of data.
size_t used; // number of segments of data in use.
int sign; // the sign of the number (-1, 0, 1).
};
并轻松访问它的各个字段,而标头文件的用户无法执行此操作。
有关不透明指针的更多信息,请参见Wikipedia页面。
它的主要用途是向您的库用户隐藏实现细节。封装(尽管C ++人群会告诉您什么)已经存在很长时间了:-)
您只想在库中发布足够的详细信息,以便用户有效地利用它,而不再需要更多。发布更多内容会为用户提供他们可能依赖的详细信息(例如size变量sz
位于结构中的特定位置的事实,这可能会导致他们绕过控件并直接对其进行操作。
然后,当您更改内部结构时,您会发现客户苦苦抱怨。没有该结构信息,您的API仅限于您提供的内容,并且可以维护有关内部操作的自由。
xyzzy
,是。不透明的指针类型为pmpi
,不透明的结构为struct pmpi
。它的主要用途是与封装有关,该功能可以向用户隐藏实现细节。我将详细更新答案。
fopen
或者fclose
对FILE *
。是否FILE
真正不透明取决于您在其中找到的内容stdio.h
-如果已在此处完全声明它,而不仅仅是与该答案中类似的类型,则用户可以使用内部结构,因此只有经过双方同意,它才是不透明的:-)
typedef struct pmpi_s *pmpi;
不是理想的:有人可能会认为例如void f(const pmpi val)
其论点没有副作用,这是不正确的。
不透明指针用于编程接口(API)的定义。
通常,它们是指向不完整结构类型的指针,声明如下:
typedef struct widget *widget_handle_t;
它们的目的是为客户端程序提供一种对由API管理的对象的引用的方式,而不暴露该对象的实现(内存中的地址(指针本身)除外)。
客户端可以传递对象,将其存储在其自己的数据结构中,并比较两个这样的指针(无论它们是相同还是不同),但是它不能取消引用这些指针来窥视对象中的内容。
这样做的原因是为了防止客户端程序变得依赖于那些细节,以便可以升级实现而不必重新编译客户端程序。
由于输入了不透明指针,因此可以很好地测量类型安全。如果我们有:
typedef struct widget *widget_handle_t;
typedef struct gadget *gadget_handle_t;
int api_function(widget_handle_t, gadget_handle_t);
如果客户端程序混合了参数的顺序,则编译器将发出诊断信息,因为astruct gadget *
被转换为astruct widget *
而没有强制转换。
这就是为什么我们要定义struct
没有成员的类型的原因。每个struct
带有不同新标签的声明都会引入一个与先前声明的struct
类型不兼容的新类型。
客户变得依赖是什么意思?假设awidget_t
具有width和height属性。如果它不是不透明并且看起来像这样:
typedef struct widget {
short width;
short height;
} widget_t;
然后客户只需执行以下操作即可获得宽度和高度:
int widget_area = whandle->width * whandle->height;
而在不透明的范式下,它必须使用访问函数(未内联):
// in the header file
int widget_getwidth(widget_handle_t *);
int widget_getheight(widget_handle_t *);
// client code
int widget_area = widget_getwidth(whandle) * widget_getheight(whandle);
请注意,widget
作者是如何使用该short
类型来节省结构中的空间的,并且该类型已暴露给非透明接口的客户端。假设小部件现在可以具有不适合的大小,short
并且结构必须更改:
typedef struct widget {
int width;
int height;
} widget_t;
现在必须重新编译客户端代码以采用此新定义。根据工具和部署工作流程的不同,甚至可能存在未完成的风险:旧的客户端代码尝试使用新的库,并且通过使用旧的布局访问新的结构而行为不端。对于动态库,这很容易发生。库已更新,但相关程序未更新。
使用不透明接口的客户端可以继续工作而不做修改,因此不需要重新编译。它只是调用访问器函数的新定义。这些位于小部件库中,并且可以int
从结构中正确检索新键入的值。
请注意,从历史上(至今仍在此)存在使用该void *
类型作为不透明句柄类型的乏味做法:
typedef void *widget_handle_t;
typedef void *gadget_handle_t;
int api_function(widget_handle_t, gadget_handle_t);
在此方案下,您可以执行此操作,而无需任何诊断:
api_function("hello", stdout);
Microsoft Windows API是系统的示例,您可以在两种系统中同时使用它。默认情况下,各种句柄类型均为HWND
(窗口句柄)和HDC
(设备上下文)void *
。因此,没有类型安全性。一个HWND
可以通过其中HDC
的预期,按错。如果您这样做:
#define STRICT
#include <windows.h>
然后将这些句柄映射到互不兼容的类型以捕获这些错误。