在哪里放置C宏实现的实施模板?
我想要一个带有宏观修复的C库,具体取决于类型。
标题文件的一个非常简单的示例:
#define PAIR_TEMPLATE(Type) \
typedef struct { Type a[2]; } PAIR_ ## Type; \
Type Pair_ ## Type ## _Sum (PAIR_ ## Type *pPair);
PAIR_TEMPLATE (char)
PAIR_TEMPLATE (int)
这应该扩展到
typedef struct { char a[2]; } PAIR_char;
char Pair_char_Sum (PAIR_char *pPair);
typedef struct { int a[2]; } PAIR_int;
int Pair_int_Sum (PAIR_int *pPair);
sum
的实现,也可以被模板:
#define PAIR_Sum_TEMPLATE(Type) \
Type Pair_ ## Type ## _Sum (PAIR_ ## Type *pPair) { \
return (Type) (pPair->a [0] + pPair->a [1]); \
}
请注意,这只是一个非常简单的示例。我的真实模板将具有其他多个功能,并且也适用于几乎任何struct
类型。将其视为动态阵列的模板。
我的库本身将对某些数据类型使用此模板。另一方面,库的用户还应该能够将此模板用于其他类型。
现在,我面临着一个设计问题:如何确保在同一翻译单元中使用相同名称的typedef
template的多个扩展(因为编译器不允许使用)?也许该库的用户将为某些类型的某些类型的typedef
-platpl展开,但他看不出在库标题中已经完成了哪种类型。此外,可以一天更新库,并在内部添加更多类型,以便在更新后可以将新的冲突添加到用户的代码中。库手册是否应需要定义一个具有特定名称的宏,例如#define pair_template_defined_ [type]
在每个扩展之后,并需要将每个扩展放入#ifndef ... #endif ?还是有更好的解决方案?
另一个问题如下:
如果我将实现模板(不是标题模板!)放入单独的代码文件中,该文件应该在翻译单元中与用户代码不同,则用户很难扩展实现模板对于他自己的类型。
另一方面,如果我将实现模板放入库标题文件中,以便我的库的用户将在同一翻译单元中扩展实现,那么他将遇到困难,以确保每种类型的最多都有一个实施扩展。
这场冲突有很好的设计解决方案吗?谢谢。
I want a write a C library with macro-templates depending on a type.
A very simplified example for the header file:
#define PAIR_TEMPLATE(Type) \
typedef struct { Type a[2]; } PAIR_ ## Type; \
Type Pair_ ## Type ## _Sum (PAIR_ ## Type *pPair);
PAIR_TEMPLATE (char)
PAIR_TEMPLATE (int)
This should expand to
typedef struct { char a[2]; } PAIR_char;
char Pair_char_Sum (PAIR_char *pPair);
typedef struct { int a[2]; } PAIR_int;
int Pair_int_Sum (PAIR_int *pPair);
The implementation for Sum
can also be templated:
#define PAIR_Sum_TEMPLATE(Type) \
Type Pair_ ## Type ## _Sum (PAIR_ ## Type *pPair) { \
return (Type) (pPair->a [0] + pPair->a [1]); \
}
Please note that this is only a very simplified example. My real template will have multiple other functions and will be also applicable for almost any struct
type. Think of it as of a template for a dynamic array.
My library itself will use this template for some data types. On the other hand, the user of the library should also be able to use this template for other types.
Now I am facing a design problem: How to ensure that there will not be multiple expansions of the typedef
-template with the same name in the same translation unit (because this is not allowed by the compiler)? Maybe the user of the library will expand the typedef
-template for some types himself, but he does not see for which types this is already done in the library headers. Moreover, the library could be updated one day and add more types internally such that new conflicts might be added to the user's code after an update. Should the library manual require to define a macro with a certain name like #define PAIR_TEMPLATE_DEFINED_[Type]
after each expansion and require to put every expansion into #ifndef ... #endif
? Or is there a better solution?
Another problem follows:
If I put the implementation template (not the header template!) into a separate code file which is supposed to be compiled in a translation unit different from the user's code, it will be difficult for the user to expand the implementation template for his own types.
On the other hand, if I put the implementation template into the library header file such that the user of my library will expand the implementation in the same translation unit, then he will have difficulties ensuring that, for every type, there is at most one implementation expanded.
Is there a good design solution for this conflict? Thank you.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论