C++中“能用”的AOP是通过模板、宏、RAII和函数对象在编译期或调用点织入横切关注点；典型做法是用RAII封装TimerAspect，构造时记录开始时间、析构时计算并输出耗时，兼具零开销与异常安全。
什么是C++里“能用”的AOP
C++没有语言级AOP支持（比如Java的AspectJ），但可以通过模板、宏、RAII和函数对象组合出轻量级切面逻辑——本质是把横切关注点（如日志、计时、权限）在编译期或调用点“织入”，不侵入业务函数本身。
关键不是模拟Spring AOP，而是解决实际问题：比如给某个process_data()自动加计时，又不想改它内部实现。
用RAII + 模板封装“进入/退出”逻辑
这是最稳定、零运行时开销的做法。把切面逻辑写进一个作用域类，在构造时执行前置（如记录开始时间），析构时执行后置（如打印耗时）。
-
std::chrono::steady_clock::now()比clock()更可靠，避免系统时间跳变影响 - 切面类必须是栈对象，不能
new出来，否则析构时机不可控 - 如果业务函数可能抛异常，RAII天然支持异常安全——析构仍会被调用
struct TimerAspect {
TimerAspect(const char* name) : name_(name), start_(std::chrono::steady_clock::now()) {}
~TimerAspect() {
auto end = std::chrono::steady_clock::now();
auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(end - start_).count();
std::cout << name_ << " took " << ms << "ms\n";
}
private:
const char* name_;
std::chrono::steady_clock::time_point start_;
};
<p>void process_data() {
TimerAspect ta("process_data"); // 构造即开始计时
// ... 业务逻辑
}用宏简化切面调用（谨慎使用）
宏能减少重复代码，但会隐藏控制流，调试困难。只建议用于明确、固定模式的切面（如统一日志入口）。
立即学习“C++免费学习笔记（深入）”；
- 宏展开后所有参数被多次求值，禁止传入带副作用的表达式，比如
LOG_ENTRY(func(), x++)会导致x++执行两次 - 不要在宏里用
return，否则破坏原函数控制流 - 优先用
do { ... } while(0)包裹多行逻辑，避免if (cond) LOG_ENTRY(...); else ...出错
#define LOG_ENTRY(name) \
LogAspect __log_aspect__(name, __FILE__, __LINE__); \
std::cout << "[ENTER] " << name << " at " << __FILE__ << ":" << __LINE__ << "\n"
<p>struct LogAspect {
LogAspect(const char<em> f, const char</em> file, int line) : func<em>(f), file</em>(file), line<em>(line) {}
~LogAspect() { std::cout << "[LEAVE] " << func</em> << "\n"; }
const char<em> func_;
const char</em> file<em>;
int line</em>;
};为什么不用std::function或虚函数做通用切面
看似灵活，实则引入间接调用开销和对象生命周期管理负担，违背C++零成本抽象原则。
-
std::function有类型擦除开销，且无法内联；虚函数调用破坏CPU分支预测 - 若切面需捕获局部变量，容易引发悬空引用（比如lambda捕获了栈变量，但切面对象活得比函数长）
- 真正需要动态切换切面的场景极少——大多数日志/监控策略在编译期就确定了
真要动态织入，优先考虑编译期SFINAE或constexpr if判断，而不是运行时多态。
