C 结构信息隐藏(不透明指针)
C struct information hiding (Opaque pointer)
我目前对 C 结构的信息隐藏概念有点困惑。
本题背景是一个嵌入式c项目,对OOP的了解几乎为零
到目前为止,我总是在相应模块的头文件中声明我的 typedef 结构。
所以每个想要使用这个结构的模块都知道结构类型。
但是在 MISRA-C 检查之后我发现了中等严重性警告:MISRAC2012-Dir-4.8
- 结构的实现不必要地暴露给翻译单元。
经过一些研究,我发现了通过将结构成员的可见访问限制在私有范围内来隐藏 C 结构信息的概念。
我立即尝试了一个简单的示例,如下所示:
struct_test.h
//struct _structName;
typedef struct _structName structType_t;
struct_test.c
#include "struct_test.h"
typedef struct _structName
{
int varA;
int varB;
char varC;
}structType_t;
main.c
#include "struct_test.h"
structType_t myTest;
myTest.varA = 0;
myTest.varB = 1;
myTest.varC = 'c';
这会产生编译器错误,即 main.c myTest 的大小未知。
当然,main.c 只知道 structType_t 类型的结构存在,没有其他信息。
所以我继续研究并偶然发现了不透明指针的概念。
所以我尝试了第二次尝试:
struct_test.h
typedef struct _structName *myStruct_t;
struct_test.c
#include "struct_test.h"
typedef struct _structName
{
int varA;
int varB;
char varC;
}structType_t;
main.c
#include "struct_test.h"
myStruct_t myTest;
myTest->varA = 1;
我收到编译器错误:取消引用指向不完整类型的指针 struct _structName
所以显然我还没有理解这种技术的基本概念。
我主要的困惑点是struct对象的数据会放在哪里?
到目前为止,我了解到指针通常指向数据类型的 "physical" 表示和相应地址上的 reads/writes 内容。
但是使用上面的方法,我声明了一个指针 myTest 但从未设置它应该指向的地址。
我从这个 post 中得到了这个想法:
What is an opaque pointer in C?
在 post 中提到,访问是用 set/get 接口方法处理的,所以我尝试添加一个类似这样的方法:
void setVarA ( _structName *ptr, int valueA )
{
ptr->varA = valueA;
}
但这也行不通,因为现在他告诉我 _structName
是未知的...
那么我只能借助额外的接口方法访问结构吗?如果可以,我如何在我的简单示例中实现这一点?
我更大的问题仍然是我的结构对象在内存中的位置。
我只知道指针概念:
varA - 地址:10 - 值:1
ptrA - 地址:22 - 值:10
但是在这个例子中我只有
myTest - 地址:xy - 值:??
我无法理解相应 myTest
指针的 "physical" 表示位于何处?
此外,在我作为模块的生产者和消费者的相对较小范围的嵌入式项目中,我看不到这样做的好处。
谁能解释一下这种方法是否真的适用于 1-2 名开发人员使用代码的中小型嵌入式项目?
目前,制作所有这些接口指针方法似乎比仅仅在我的头文件中声明结构要付出更多的努力。
提前致谢
My main point of confusion is where the data of the struct object will?
重点是您不使用其他翻译单元中的 struct
表示(即它的大小、字段、布局等),而是调用为您完成工作的函数。你需要为此使用一个不透明的指针,是的。
how can I achieve this in my simple example?
您必须将所有使用结构字段(真正的结构)的函数放在一个文件(实现)中。然后,在 header 中,仅公开接口(您希望用户调用的函数,以及那些采用不透明指针的函数)。最后,用户将使用 header 来调用 仅 那些功能。他们将无法调用任何其他函数,也无法知道结构内部的内容,因此尝试执行此操作的代码将无法编译(这就是重点!)。
Furthermore I can not see the benefits of doing it like this in relatively small scope embedded projects where I am the producer and consumer of the modules.
这是一种强制模块相互独立的方法。有时它用于向客户隐藏实现或能够保证 ABI 稳定性。
但是,是的,对于内部使用,它通常是一种负担(并且阻碍优化,因为除非您使用 LTO 等,否则一切都变成编译器的黑匣子)。在 C++ 等其他语言中,像 public
/private
这样的句法方法要好得多。
但是,如果您一定要遵循 MISRA 到这种程度(即,如果您的项目必须遵循该规则,即使它只是建议性的),您也无能为力。
Can someone explain me if this method is really reasonable for small to mid scale embedded projects with 1-2 developers working with the code?
这取决于你。有非常 的大项目没有遵循该建议并取得了成功。通常,私有字段的注释或命名约定就足够了。
正如您所推断的那样,当使用像这样的不透明类型时,主源文件无法访问结构的成员,并且实际上不知道结构有多大。因此,您不仅需要 read/write 结构字段的访问函数,还需要一个函数来为结构分配内存,因为只有库源知道结构的定义和大小。
因此您的头文件将包含以下内容:
typedef struct _structName structType_t;
structType_t *init();
void setVarA(structType_t *ptr, int valueA );
int getVarA(structType_t *ptr);
void cleanup(structType_t *ptr);
此接口允许用户创建结构的实例、获取和设置值以及清理它。库源代码如下所示:
#include "struct_test.h"
struct _structName
{
int varA;
int varB;
char varC;
};
structType_t *init()
{
return malloc(sizeof(structType_t ));
}
void setVarA(structType_t *ptr, int valueA )
{
ptr->varA = valueA;
}
int getVarA(structType_t *ptr)
{
return ptr->varA;
}
void cleanup(structType_t *ptr)
{
free(ptr);
}
请注意,您只需要定义一次 typedef
。这既定义了类型别名又向前声明了结构。然后在源文件中出现了没有 typedef 的实际结构定义。
调用者使用 init
函数为结构分配 space 并 return 指向它的指针。然后可以将该指针传递给 getter / setter 函数。
所以现在你的主要代码可以像这样使用这个接口:
#include "struct_test.h"
int main()
{
structType_t *s = init();
setVarA(s, 5);
printf("s->a=%d\n", getVarA(s));
cleanup(s);l
}
In the post it is mentioned, that the access is handled with set/get interface methods so I tried adding one similiar like this:
void setVarA ( _structName *ptr, int valueA )
{
ptr->varA = valueA;
}
But this also doesn't work because now he tells me that _structName
is unknown...
类型不是 _structName
,而是 struct _structName
或(按定义)structType_t
。
And my bigger question still remains where the object of my struct is located in memory.
有了这种技术,就会有一种方法可以 returns 这样一个不透明对象的地址。它可以静态或动态分配。当然也应该有释放对象的方法。
Furthermore I can not see the benefits of doing it like this in relatively small scope embedded projects where I am the producer and consumer of the modules.
我同意你的看法。
我目前对 C 结构的信息隐藏概念有点困惑。
本题背景是一个嵌入式c项目,对OOP的了解几乎为零
到目前为止,我总是在相应模块的头文件中声明我的 typedef 结构。 所以每个想要使用这个结构的模块都知道结构类型。
但是在 MISRA-C 检查之后我发现了中等严重性警告:MISRAC2012-Dir-4.8 - 结构的实现不必要地暴露给翻译单元。
经过一些研究,我发现了通过将结构成员的可见访问限制在私有范围内来隐藏 C 结构信息的概念。
我立即尝试了一个简单的示例,如下所示:
struct_test.h
//struct _structName;
typedef struct _structName structType_t;
struct_test.c
#include "struct_test.h"
typedef struct _structName
{
int varA;
int varB;
char varC;
}structType_t;
main.c
#include "struct_test.h"
structType_t myTest;
myTest.varA = 0;
myTest.varB = 1;
myTest.varC = 'c';
这会产生编译器错误,即 main.c myTest 的大小未知。 当然,main.c 只知道 structType_t 类型的结构存在,没有其他信息。
所以我继续研究并偶然发现了不透明指针的概念。
所以我尝试了第二次尝试:
struct_test.h
typedef struct _structName *myStruct_t;
struct_test.c
#include "struct_test.h"
typedef struct _structName
{
int varA;
int varB;
char varC;
}structType_t;
main.c
#include "struct_test.h"
myStruct_t myTest;
myTest->varA = 1;
我收到编译器错误:取消引用指向不完整类型的指针 struct _structName
所以显然我还没有理解这种技术的基本概念。 我主要的困惑点是struct对象的数据会放在哪里?
到目前为止,我了解到指针通常指向数据类型的 "physical" 表示和相应地址上的 reads/writes 内容。
但是使用上面的方法,我声明了一个指针 myTest 但从未设置它应该指向的地址。
我从这个 post 中得到了这个想法: What is an opaque pointer in C?
在 post 中提到,访问是用 set/get 接口方法处理的,所以我尝试添加一个类似这样的方法:
void setVarA ( _structName *ptr, int valueA )
{
ptr->varA = valueA;
}
但这也行不通,因为现在他告诉我 _structName
是未知的...
那么我只能借助额外的接口方法访问结构吗?如果可以,我如何在我的简单示例中实现这一点?
我更大的问题仍然是我的结构对象在内存中的位置。 我只知道指针概念:
varA - 地址:10 - 值:1
ptrA - 地址:22 - 值:10
但是在这个例子中我只有
myTest - 地址:xy - 值:??
我无法理解相应 myTest
指针的 "physical" 表示位于何处?
此外,在我作为模块的生产者和消费者的相对较小范围的嵌入式项目中,我看不到这样做的好处。
谁能解释一下这种方法是否真的适用于 1-2 名开发人员使用代码的中小型嵌入式项目? 目前,制作所有这些接口指针方法似乎比仅仅在我的头文件中声明结构要付出更多的努力。
提前致谢
My main point of confusion is where the data of the struct object will?
重点是您不使用其他翻译单元中的 struct
表示(即它的大小、字段、布局等),而是调用为您完成工作的函数。你需要为此使用一个不透明的指针,是的。
how can I achieve this in my simple example?
您必须将所有使用结构字段(真正的结构)的函数放在一个文件(实现)中。然后,在 header 中,仅公开接口(您希望用户调用的函数,以及那些采用不透明指针的函数)。最后,用户将使用 header 来调用 仅 那些功能。他们将无法调用任何其他函数,也无法知道结构内部的内容,因此尝试执行此操作的代码将无法编译(这就是重点!)。
Furthermore I can not see the benefits of doing it like this in relatively small scope embedded projects where I am the producer and consumer of the modules.
这是一种强制模块相互独立的方法。有时它用于向客户隐藏实现或能够保证 ABI 稳定性。
但是,是的,对于内部使用,它通常是一种负担(并且阻碍优化,因为除非您使用 LTO 等,否则一切都变成编译器的黑匣子)。在 C++ 等其他语言中,像 public
/private
这样的句法方法要好得多。
但是,如果您一定要遵循 MISRA 到这种程度(即,如果您的项目必须遵循该规则,即使它只是建议性的),您也无能为力。
Can someone explain me if this method is really reasonable for small to mid scale embedded projects with 1-2 developers working with the code?
这取决于你。有非常 的大项目没有遵循该建议并取得了成功。通常,私有字段的注释或命名约定就足够了。
正如您所推断的那样,当使用像这样的不透明类型时,主源文件无法访问结构的成员,并且实际上不知道结构有多大。因此,您不仅需要 read/write 结构字段的访问函数,还需要一个函数来为结构分配内存,因为只有库源知道结构的定义和大小。
因此您的头文件将包含以下内容:
typedef struct _structName structType_t;
structType_t *init();
void setVarA(structType_t *ptr, int valueA );
int getVarA(structType_t *ptr);
void cleanup(structType_t *ptr);
此接口允许用户创建结构的实例、获取和设置值以及清理它。库源代码如下所示:
#include "struct_test.h"
struct _structName
{
int varA;
int varB;
char varC;
};
structType_t *init()
{
return malloc(sizeof(structType_t ));
}
void setVarA(structType_t *ptr, int valueA )
{
ptr->varA = valueA;
}
int getVarA(structType_t *ptr)
{
return ptr->varA;
}
void cleanup(structType_t *ptr)
{
free(ptr);
}
请注意,您只需要定义一次 typedef
。这既定义了类型别名又向前声明了结构。然后在源文件中出现了没有 typedef 的实际结构定义。
调用者使用 init
函数为结构分配 space 并 return 指向它的指针。然后可以将该指针传递给 getter / setter 函数。
所以现在你的主要代码可以像这样使用这个接口:
#include "struct_test.h"
int main()
{
structType_t *s = init();
setVarA(s, 5);
printf("s->a=%d\n", getVarA(s));
cleanup(s);l
}
In the post it is mentioned, that the access is handled with set/get interface methods so I tried adding one similiar like this:
void setVarA ( _structName *ptr, int valueA ) { ptr->varA = valueA; }
But this also doesn't work because now he tells me that
_structName
is unknown...
类型不是 _structName
,而是 struct _structName
或(按定义)structType_t
。
And my bigger question still remains where the object of my struct is located in memory.
有了这种技术,就会有一种方法可以 returns 这样一个不透明对象的地址。它可以静态或动态分配。当然也应该有释放对象的方法。
Furthermore I can not see the benefits of doing it like this in relatively small scope embedded projects where I am the producer and consumer of the modules.
我同意你的看法。