隐藏 C 中的类型定义

发布于 2025-01-05 15:51:05 字数 687 浏览 0 评论 0原文

我有一个 .c 文件（一个函数库），其中包含一个函数和如下定义：

typedef long double big;
big foo(int x) { ... }

我想创建该库的一个接口，一个 .h。所以我这样做：

typedef long double big;
big foo(int);

并从 .c 文件中删除 typedef long double big; 。但通过这样做，我放弃了接口中 big 的类型定义，因此它并不是一个真正干净的接口。有什么想法如何解决这个问题吗？

我知道我可以在我的 .c 文件中执行此操作：

struct foo {
  long double;
};

然后在 .h 文件中执行以下操作：

typedef struct foo big;
big foo(int);

但创建一个 struct 似乎很浪费仅针对一个字段，此外，每当我想读取 big 时，我都应该使用 . 运算符。

原文

I have a .c file (a library of functions) with a function and a definition like this:

typedef long double big;
big foo(int x) { ... }

I want to create an interface of this library, an .h. So I do:

typedef long double big;
big foo(int);

and remove the typedef long double big; from the .c file. But by doing so I give away the type definition of big in my interface, so it's not really a clean interface. Any ideas how to fix that?

I know I could do this in my .c file:

struct foo {
  long double;
};

and then in the .h file do:

typedef struct foo big;
big foo(int);

But it seems waste to create a struct for just one field, plus I should use the . operator whenever I want to read a big.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

过期以后 2025-01-12 15:51:05

如果类型永远不会变得比 long double 更复杂，那么可能不值得有更多隐藏它的想法。如果它可能需要变得更复杂，那么您可以考虑使用不透明类型。在公共标头 big.h 中，您使用：

#ifndef BIG_H_INCLUDED
#define BIG_H_INCLUDED
typedef struct big big_t;

extern big_t *foo(int);

...

#endif

所有函数都将获取并返回指向 big_t 类型的指针。这就是您对此类不完整类型所能做的全部事情。请注意，您的客户无法为自己分配任何 big_t 值；他们不知道该类型有多大。这意味着您最终可能会得到以下函数：

extern big_t *big_create(void);
extern void   big_destroy(big_t *value);

创建和销毁 big_t 值。然后他们将能够进行算术运算：

extern big_errno_t big_add(const big_t *lhs, const big_t *rhs, big_t *result);

等等。但是因为他们只有不透明的、不完整的类型，所以他们不能可靠地在 big_t 结构中乱搞。但请注意，您只能在接口中使用指针。传递或返回值需要完整的类型，如果类型完整，用户可以研究其内部工作原理。

在实现标头 bigimpl.h 中，您将拥有：

#ifndef BIGIMPL_H_INCLUDED
#define BIGIMPL_H_INCLUDED
#include "big.h"

struct big
{
    ...whatever the details actually are...
};

#endif

您的实现代码将仅包含 bigimpl.h，但包含 big.h.这里的主要问题是确保您知道如何处理内存分配。

有时这种技术是值得的。通常这并不是真正必要的。您需要自己进行评估。

If the type is never going to get more complex than long double, then it probably isn't worth having conniptions about hiding it more. If it might need to become more complex, then you can consider using an opaque type. In your public header, big.h, you use:

#ifndef BIG_H_INCLUDED
#define BIG_H_INCLUDED
typedef struct big big_t;

extern big_t *foo(int);

...

#endif

All the functions will take and return pointers to the big_t type. This is all you can do with incomplete types like that. Note that your customers cannot allocate any big_t values for themselves; they don't know how big the type is. It means you'll probably end up with functions such as:

extern big_t *big_create(void);
extern void   big_destroy(big_t *value);

to create and destroy big_t values. Then they'll be able to do arithmetic with:

extern big_errno_t big_add(const big_t *lhs, const big_t *rhs, big_t *result);

Etc. But because they only have an opaque, incomplete type, they cannot reliably go messing around inside a big_t structure. But note that you are constrained to using pointers in the interface. Passing or returning values requires complete types, and if the type is complete, users can investigate its inner workings.

In the implementation header, bigimpl.h, you'll have:

#ifndef BIGIMPL_H_INCLUDED
#define BIGIMPL_H_INCLUDED
#include "big.h"

struct big
{
    ...whatever the details actually are...
};

#endif

And your implementation code will only include bigimpl.h, but that includes big.h. The main issue here is making sure you know how the memory allocations are handled.

Sometimes this technique is worthwhile. Often it is not really necessary. You'll need to make the assessment for yourself.

回复收藏 0 原文