在API中公开不同的类型名称而不使用库本身的类型是否被认为是一种不好的做法?
如果有这样的库:
struct Internal {
int first;
float second;
};
int foo(struct Internal);
typedef enum {
VALUE_1,
VALUE_2
} INTERNAL_ENUM;
int bar(INTERNAL_ENUM);
它可以像这样链接头:
struct External {
int first;
float second;
};
int foo(struct External);
typedef enum {
VALUE_1,
VALUE_2
} EXTERNAL_ENUM;
int bar(EXTERNAL_ENUM);
如果我创建了一个使用另一个库的库，并且我不希望该库被暴露，那么为API使用不同的类型名称是否被认为是不切实际的?
由于项目当前设置(我继承了它)，有两组数据类型，其中一组由我维护，它反映了一些内部(静态链接)库中使用的数据类型。代码更复杂，充满了错误，我在问我的解决方案是否会更好?
在我创建使用另一个库的库的情况下，我不希望该库被公开，是否认为为API使用不同的类型名称是不切实际的?
"Impractical"可以用一个词来形容。
C的类型兼容性规则要求结构类型不仅要有匹配的成员列表，而且要有匹配的标签或在无标签的情况下匹配。对于联合和枚举也是如此。规则还要求同一对象或函数的所有声明都为其指定兼容的类型。*
这意味着按照您的描述进行操作会引发未定义的行为。在这种情况下，这不仅包括未定义的运行时行为，还包括未定义的编译时行为。
给定
application ---uses---> library 1 ---uses---> library 2
您可以选择library 1的标头是否将library 2的数据类型公开给application。如果您选择让它们这样做，那么对于结构和联合类型，您还可以选择是否将它们公开为不透明类型。但是，如果您想要定义良好的行为，那么您就不能选择重新标记library 2的结构、联合或枚举类型以供应用程序使用。不同的标签产生不兼容的类型，正如C使用的术语。
由于项目当前是设置的(我继承了它)，所以有两个集合在数据类型中，有一种是由我维护的，它反映了某些人使用的数据类型内部(静态链接)库。代码更加复杂和完整我在问我的解决方案是否会更好?
我不明白你认为继续"照镜子"会得到什么。内部库的数据类型，但具有不同的名称。听起来这会使你的问题在几个方面变得更糟，而不是更好。
但是你绝对应该想出一种方法来避免重复的数据类型定义。安排一种或另一种方式，使所有涉及的翻译单元对所使用的所有数据类型使用相同的定义(或根本不使用)。这就是头文件的目的。
当然，这假设你将从应用程序层通过库1传递对象到库2，这显然是你所描述的。这可能是个好计划，但不是你唯一的选择。
*这是关于类型本身的，而不是通过typedef声明的类型别名。