Integrity RTOS 上 C++ 编译支持默认不开启，需显式启用 C++ 运行时并正确链接 libcxx.a；new/delete 需重载至确定性内存接口；任务函数须为 void()(void) 签名；std::thread/std::mutex 等标准并发设施不可用，应使用 Integrity 原生 API。
Integrity RTOS 上 C++ 的编译支持是否默认开启？
不开启。Integrity 默认 C++ 支持是关闭的，即使你写了 class 或用了 new，链接阶段大概率报 undefined reference to '__cxa_begin_catch' 这类符号缺失错误——这不是你代码写错了，是工具链没配对。
- 必须在构建配置中显式启用 C++ 运行时：在
integrity.xml或工程属性里勾选Enable C++ support（或等效的--enable-cxx编译器开关） - 对应地，
libstdc++.a或 Integrity 定制的libcxx.a必须被链接，且顺序不能错：C++ 库需放在用户目标文件之后、C 库之前 - 禁用异常（
-fno-exceptions）和 RTTI（-fno-rtti）是常见选择，否则会引入不可预测的堆分配和虚表查找，破坏实时性
Integrity 下 new / delete 能否直接用？
能声明，但默认行为危险。Integrity 的全局 operator new 通常指向 malloc，而 malloc 在多数 Integrity 配置中是禁用的（或映射到不可靠的池），运行时可能返回 nullptr 或触发 abort。
- 务必重载全局
operator new和operator delete，绑定到 Integrity 提供的确定性内存接口，例如Heap_Allocate/Heap_Free - 避免在中断上下文或高优先级任务中调用，即便重载后也不保证常数时间——Integrity 的堆管理仍可能有锁或遍历开销
- 更推荐方案：用
placement new配合静态/预分配缓冲区，例如char buffer[sizeof(MyClass)]; MyClass* p = new(buffer) MyClass;
Integrity C++ 任务函数为什么不能直接写成 void task_func()？
因为 Integrity 的任务启动机制要求入口函数签名严格为 void (*)(void*)，而普通 C++ 成员函数隐含 this 指针，类型不匹配。直接传 &MyClass::run 会编译失败或运行崩溃。
- 静态成员函数可以，但无法访问对象状态；解决方法是把
this作为参数传入：static void task_entry(void* arg) { static_cast<myclass>(arg)->run(); }</myclass> - 使用
std::function或 lambda 不可行——它们依赖动态内存和异常机制，Integrity 默认不支持 - 注意：任务栈大小需手动计算并预留足够空间，C++ 构造函数、临时对象、异常帧（若启用）都会吃栈，别照搬 C 任务的 2KB 栈配置
Integrity 的 std::thread 或 std::mutex 能用吗？
不能。Integrity 的标准库实现（如 Green Hills 的 libcxx）不提供 std::thread，也没有基于内核原语的 std::mutex 后端。这些头文件可能存在，但链接时必然失败。
立即学习“C++免费学习笔记（深入）”；
- 替代方案是 Integrity 原生 API：
Task_Create、Mutex_Create、Event_Wait等，它们才是确定性、可调度、可分析的 - 封装一层薄薄的 RAII 类没问题（比如
IntegrityMutexGuard），但内部必须调用Mutex_Take/Mutex_Release，而非尝试桥接std::mutex - 别碰
std::chrono——Integrity 时间单位是 tick，不是纳秒，std::this_thread::sleep_for无实现，硬用会卡死
真正麻烦的从来不是语法能不能过，而是每个 C++ 特性背后是否对应一个确定性的、可审计的 Integrity 内核原语。写两行模板不难，让编译器生成的虚表布局在所有优化等级下都稳定，才见真功夫。
