嵌入式C++禁用new/delete因裸机/RTOS缺乏可靠堆管理，易致nullptr、未定义行为、堆碎片、时间不可预测及线程同步问题；应优先用std::array等栈分配方案。
为什么嵌入式 C++ 中要禁用 new 和 delete
因为大多数裸机或 RTOS 环境没有可靠的堆管理器，new 可能返回 nullptr（且不抛异常），delete 可能触发未定义行为；更隐蔽的问题是堆碎片、分配时间不可预测、多线程下需额外同步——这些都违反实时性与确定性要求。
用栈数组替代 std::vector 的常见误判
直接写 std::vector<int> buf(128)</int> 仍会调用 operator new，除非你禁用其动态分配能力。正确做法是：使用固定大小容器或手动栈数组。
- 优先用
std::array<int></int>：编译期确定大小，纯栈分配，无运行时开销 - 避免
std::vector，除非你已重载其Allocator并绑定到静态内存池（见下一条） - 若必须用类似 vector 的接口，可封装
std::array+ size 计数器，例如：template<typename T, size_t N> struct static_vector { T data[N]; size_t size_ = 0; void push_back(const T& x) { if (size_ < N) data[size_++] = x; } };
如何安全地定制 std::allocator 绑定静态内存池
不是所有标准库实现都支持自定义 allocator，但若你用的是 libc++ 或裁剪过的 libstdc++，且确认其容器模板接受 allocator 参数，则可行。关键点在于：内存池地址必须在启动时就固定，且生命周期覆盖整个程序运行期。
- 定义一块全局对齐的静态内存：
alignas(std::max_align_t) static uint8_t pool_buffer[4096];
- 实现简易 allocator：
template<typename T> struct static_pool_allocator { using value_type = T; T* allocate(size_t n) { static_assert(sizeof(T) * n <= sizeof(pool_buffer), "pool overflow"); static uint8_t* ptr = pool_buffer; T* ret = reinterpret_cast<T*>(ptr); ptr += sizeof(T) * n; return ret; } void deallocate(T*, size_t) noexcept {} }; - 使用时显式传入：
std::vector<int static_pool_allocator>> vec;</int>—— 注意：某些 STL 实现会忽略 allocator 的deallocate调用，务必验证
构造函数中隐含的动态分配陷阱
看似无害的类成员初始化可能偷偷调用 new，比如 std::string、std::function、带默认参数的模板类。这些在嵌入式中应一律规避。
立即学习“C++免费学习笔记（深入）”；
- 用
std::array<char></char>替代std::string，配合std::string_view做只读视图 - 避免
std::function，改用函数指针或模板参数（如template<typename f> void set_handler(F f)</typename>） - 检查第三方库头文件：若其类内部含
std::vector或std::shared_ptr成员，不能直接使用 - 编译期拦截：在链接前加
-fno-builtin-new -fno-builtin-delete，再配合weak定义的operator new报错：void* operator new(size_t) = delete; void operator delete(void*) = delete;
静态分配不是“不用堆”，而是把内存布局决策前移到编译期或启动期；真正难的不是写死大小，而是识别哪些抽象（比如状态机上下文、协议解析缓冲区）能被建模为有界结构——这需要对数据流和最坏情况路径有足够清晰的建模。
