C 管理来自多个供应商的冗余TypeDef

在C编程语言中，管理用于平台独立性的冗余TypeDef的最佳方法是什么

e、 g.：
target.h

/* inclusion lock etc */
typedef char CHAR;
typedef unsigned char BYTE;
typedef unsigned short int WORD;
/* ... more of the same ... */

/* inclusion lock etc */
typedef char CHAR;
typedef unsigned char BYTE;
typedef unsigned short int WORD;
/* ... more of the same ... */

#define BYTE VENDOR1_BYTE
#include <vendor1/types.h>
#undef BYTE

#define BYTE VENDOR2_BYTE
#include <vendor2/types.h>
#undef BYTE

typedef unsigned char BYTE;

操作系统类型.h

/* inclusion lock etc */
typedef char CHAR;
typedef unsigned char BYTE;
typedef unsigned short int WORD;
/* ... more of the same ... */

/* inclusion lock etc */
typedef char CHAR;
typedef unsigned char BYTE;
typedef unsigned short int WORD;
/* ... more of the same ... */

#define BYTE VENDOR1_BYTE
#include <vendor1/types.h>
#undef BYTE

#define BYTE VENDOR2_BYTE
#include <vendor2/types.h>
#undef BYTE

typedef unsigned char BYTE;

---

在某种程度上，编译器会识别出它有两个冗余的typedef符号，并带着一个错误退出，因为C中的定义根本不允许这样做。如果我必须要做些什么，我可能会忍住鼻子修改第三方头文件——可能会使用宏来获得有条件编译有问题的typedef

---

祝你好运。

一种方法是构建自己的“包装器”层，只提供每个中间件供应商所需的功能，尽管这可能需要大量工作。如果您将每个包装器保存在自己的编译单元（.c文件）中，那么您只需要在其中引用供应商的头文件。这为您提供了一种防止冲突类型“泄漏”到应用程序中的方法，因为您可以使用自己的typedef并将它们转换为包装器中特定于供应商的类型

---

正如Steve所建议的，修改头文件可能是最好的解决方案，这取决于供应商发布新版本产品的频率。开销可能会非常高。

在不修改供应商标题的情况下，一种可能的方法是使用预处理器和一些标题包装器，例如

mytypes.h

/* inclusion lock etc */
typedef char CHAR;
typedef unsigned char BYTE;
typedef unsigned short int WORD;
/* ... more of the same ... */

/* inclusion lock etc */
typedef char CHAR;
typedef unsigned char BYTE;
typedef unsigned short int WORD;
/* ... more of the same ... */

#define BYTE VENDOR1_BYTE
#include <vendor1/types.h>
#undef BYTE

#define BYTE VENDOR2_BYTE
#include <vendor2/types.h>
#undef BYTE

typedef unsigned char BYTE;

#定义字节VENDOR1#u字节
#包括
#未定义字节
#定义字节VENDOR2\u字节
#包括
#未定义字节
typedef无符号字符字节；

---

这将导致供应商的代码生成不同的typedef，但希望映射到相同的实际类型（示例中为unsigned char）。如果供应商使用相同类型名称的不同基础类型，那么该方法可能不起作用。

< P>如果您有选择使用C++编译来实现自己的代码（即使它本质上是C代码），那么您可以创建命名空间包装器： vendorA_target.h 请注意，

外部“C”

包装器如果在

\uucplusplus

宏条件中的头文件内部已经有了包装器，则它们是不必要的，但这不会有什么坏处

< P>使用C++编译C代码不会造成开销，但它有更严格的类型一致性检查，这对代码质量有好处，可能会导致其他问题；特别是如果第三方头包含了无效的C++代码。如果标头在

\uuucplusplus

宏条件中已经有

extern“C”

声明，那么它们已经准备好“C++-ready”，您可能不会遇到任何此类问题

---

不幸的是，这种方法无法解决同名预处理器宏的问题。如果您有这个问题，您可能必须在包含另一个标题之前取消定义一个标题中的宏，或者修改标题。

如果供应商对反馈做出响应，您可以请求他们将这些通用类型定义移动到单独的文件中，例如

types.h

。如果它们被隔离在一个单独的文件中，那么管理起来就容易多了。解决方案可以非常简单，只需删除它们的

类型.h

，然后添加您自己的特定于项目的

类型.h

，它可以在您的项目中执行任何需要执行的操作

更妙的是，请他们使用

stdint.h

中的标准C typedef，即

uint16\u t

否则，我建议对供应商头文件进行修改，尽可能干净，以便在下一次发布代码时可以轻松地重新执行。当然，这些都在你的VCS中，所以你可以准确地跟踪你所做的更改