C++无法直接模拟Python的@decorator语法，因其预处理器仅做文本替换，不支持AST层节点重写，故所有“装饰器”方案均需显式调用、模板推导或RAII辅助，而非语法原生支持。
为什么 C++ 没法直接模拟 @decorator 语法
C++ 预处理器不支持“在函数定义前插入修饰符并自动包裹”的语法糖，@decorator 本质是 Python 解释器在 AST 层做的节点重写，而 C++ 编译器在宏展开阶段根本看不到函数签名、参数列表或返回类型——宏只是文本替换，连括号匹配都靠人手动数。所以任何“看起来像装饰器”的方案，都得靠显式调用、模板推导或 RAII 辅助，而不是语法层面的等价。
MAKE_DECORATED 宏 + 函数对象：最可控的包装方式
用宏把原函数名、参数、返回类型和装饰逻辑绑定在一起，避免手写重复的 lambda 或 functor。核心是让宏生成一个同名但带包装逻辑的替代函数：
#define LOG_CALL(fn) \
template<typename... args> \
auto fn(Args&&... args) -> decltype(::original_##fn(std::forward<args>(args)...)) { \
std::cout (args)...); \
}
// 原函数必须先定义，并加前缀
int original_add(int a, int b) { return a + b; }
LOG_CALL(add)
</args></typename...>
注意点：
- 原函数必须用
original_前缀定义，否则宏展开会递归调用自己 - 返回类型用
decltype推导，不能硬写int，否则引用/void/模板函数会崩 - 参数必须用
Args&&...+std::forward，不然右值会被转成左值 - 这个宏只适用于非重载、非模板函数；重载需额外加标签参数
用 std::function + 包装类做运行时装饰：适合策略切换
如果装饰行为（比如计时、日志、权限检查）需要动态开关或配置，硬编码进宏就僵化了。此时更适合定义一个可调用对象包装器：
template<typename f>
class TimerDecorator {
F f_;
public:
explicit TimerDecorator(F f) : f_(std::move(f)) {}
template<typename... args>
auto operator()(Args&&... args) -> decltype(f_(std::forward<args>(args)...)) {
auto t0 = std::chrono::steady_clock::now();
auto r = f_(std::forward<args>(args)...);
auto t1 = std::chrono::steady_clock::now();
std::cerr (t1-t0).count()
<p>关键限制：</p>
<ul>
<li>不能直接装饰已有函数名（如 <code>add</code>），只能包装 lambda 或 <code>std::function</code>
</li>
<li>每次调用都有额外对象构造开销，高频小函数慎用</li>
<li>无法获取被包装函数的原始符号名，日志里只能打 <code>#f</code>（即 lambda 的字面量，通常显示为 <code>operator()</code>）</li>
</ul>
<h3>最容易踩的坑：宏展开与作用域、链接性冲突</h3>
<p>试图用宏“覆盖”已定义函数时，常见错误不是语法错，而是 ODR（One Definition Rule）违规或链接失败：</p>
<ul>
<li>在头文件里无保护地使用 <code>LOG_CALL</code>，多个 TU 包含后导致重复定义：必须加 <code>inline</code> 或 <code>static</code> 限定（C++17 起 <code>inline</code> 函数允许多定义）</li>
<li>宏里调用的 <code>::original_foo</code> 如果没声明就定义，GCC 可能静默忽略，Clang 直接报 <code>use of undeclared identifier</code>
</li>
<li>装饰器逻辑里捕获局部变量（比如日志用的 <code>std::string tag</code>），但宏展开后该变量不在作用域内——必须把上下文全塞进宏参数，或改用闭包对象</li>
<li>返回类型推导失败时，编译器不会提示“装饰器有问题”，而是报 <code>decltype(...) is void but function returns int</code> 这类误导信息，得倒查宏展开结果</li>
</ul>
<p>真正难的从来不是写个能跑的宏，而是让宏在模板嵌套、SFINAE、constexpr 上下文、跨模块链接中依然可靠——这时候往往发现，不如老老实实写个命名明确的 <code>timed_add</code> 和 <code>logged_add</code>。</p></args></args></typename...></typename>
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
