阅读一些C ++代码我遇到了我称之为函数宏的“功能”使用大致如下(这是一个完全风格化的例子来说明这一点):
#define TOP_LEVEL(ARG1) \
ARG1("foo1","bar1") \
ARG1("foo2","bar2")
#define NEXT_LEVEL(ARG2A, ARG2B) \
cout << ARG2A << " and " << ARG2B;
TOP_LEVEL(NEXT_LEVEL)
我对这门语言比较陌生,起初我无法解决这个问题,但后来我只通过预处理器(g++ -E
)运行它并且看到它解析为:
cout << "foo1" << " and " << "bar1"; cout << "foo2" << " and " << "bar2";
你看到它在那里做了什么吗?它将Macro NEXT_LEVEL 像函数指针一样传递给宏TOP_LEVEL。看到这可能有多大用处,我想了解更多信息:将函数传递给其他函数是pretty sophisticated stuff,并且必须至少有更多关于该技术的说法。
尽管有大量谷歌搜索,但我找不到证据表明预处理器的这个功能甚至存在,更不用说任何接近文档的内容:here,here,here和{{ 3}}只是宏教程的四个例子,可以跳过这个;最后一个甚至有一个名为“高级宏技巧”的部分 - 当然这有资格!?
(请注意,这与仅使用另一个已评估的函数宏作为参数调用函数宏完全不同 - FOO(BAR(2))更直接。)
我的问题是:
答案 0 :(得分:4)
这个想法是“X-Macro”。一些定义将不包括您的特定示例(X-macro通常涉及更多,包含文件),但任何相关信息。关于这将在搜索时属于该术语。
作为评论中提到的chris,Boost.Preprocessor使用这个想法产生了很大的效果。常用的用途是:BOOST_PP_REPEAT
,BOOST_PP_LIST_FOR_EACH
,最有力的:BOOST_PP_ITERATE
。
BOOST_PP_ITERATE
是一个“真正的”X-Macro;包括单个文件将扩展为依赖于之前定义的宏的内容。我在这个other answer中展示了一个更“恰当”的骨架框架,但是一个例子是:
// in xyz_data.def
DEFINE_XYZ(foo, 1, "Description A")
DEFINE_XYZ(bar, 5, "Description B")
DEFINE_XYZ(baz, 7, "Description C")
然后,当我只想要第1列时,我可以这样做:
#define DEFINE_XYZ(name, number, desc) some_func(name)
#include "xyz_data.def"
在其他我想为每个人生成一些功能的地方,我可以这样做:
#define DEFINE_XYZ(name, number, desc) \
int BOOST_PP_CAT(get_number_for_, name)() \
{ \
std::clog << "Getting number, which is: " desc << std::endl; \
\
return number; \
}
#include "xyz_data.def"
然后,您可以生成名称等于数字等的枚举
当我想添加一个新的xyz时,我只需将它添加到一个位置,它就会神奇地显示在它需要的任何地方。我在一个非常大的代码库中做了类似的事情,将一些书签数据保存在一个中心位置,但各种属性在不同位置的使用方式不同。
请注意,通常没有办法解决这个问题;我所拥有的是语法上不同的,因此没有其他语言功能可以将它推广到该级别,只有宏。宏不是邪恶的。
你所拥有的实际上是一个X-macro,其中.def文件的自包含程度足以成为#define
。换句话说,#include "xyz_data.def"
只是TOP_LEVEL
。
这只有一个很大的缺点,具有讽刺意味的是,它不是使用X-macro本身,而是它们对C和C ++编译器的影响。问题是预处理器允许我们在每次包含文件时更改文件的预处理结果,即使文件内容完全相同。
您可能听说过,与现代语言相比,C和C ++的编译速度很慢,这也是原因之一。它没有适当的模块/包装系统,只是临时包含其他文件。我们刚学会了,一般来说这是无法避免的。哎呀。 (也就是说,编译器很聪明,例如,当你在文件中包含防护装置时会注意到,并且避免多次处理它。但这是情境化的。)
也就是说,使用X-Macros本身不应该是真正程序编译时间的巨大贡献者。只是因为他们纯粹的潜在存在可以触及到真正的单词并且与编译器的头部相混淆。
答案 1 :(得分:1)
以下是一些讲座:C is purely functionnal,