linux内核模块开发不能直接用c++，因内核不链接c++运行时，禁用异常/rtti，需重载operator new/delete，必须用extern "c"避免符号修饰，并规避std::string等依赖运行时的类型。
Linux内核模块开发不能直接用C++，不是语法不支持，而是内核构建系统、运行时约束和社区规范共同拒绝“开箱即用”的C++。
内核不链接C++运行时，new、delete、异常表全失效
内核空间没有libstdc++或libc++，也没有C++ ABI所需的全局__cxa_begin_catch、__gxx_personality_v0等符号。哪怕你写了一个空的class，只要启用了异常或RTTI，insmod就会报Unknown symbol in module错误。
- 编译必须加
-fno-exceptions -fno-rtti -fno-threadsafe-statics -
operator new和operator delete默认调用malloc/free，而内核里只有kmalloc/kfree——你得自己重载它们，且不能依赖std::allocator - 连
std::string这种基础类型都不能用，因为它的构造/析构隐含内存分配和异常逻辑
extern "C"不是可选项，是加载失败的分水岭
内核模块加载器只认C风格符号名。g++默认对函数名做name mangling（比如hello_init变成_Z10hello_initv），导致module_init()宏找不到入口点，insmod直接报Invalid module format。
- 所有被内核调用的函数（
init/exit、file_operations回调等）必须包在extern "C"块里 - 类成员函数无法直接注册为回调，必须用静态自由函数做跳板，再通过
this指针转发 - 模板实例化生成的符号同样会被mangling，除非显式
extern "C"导出，否则无法从C代码引用
内核头文件与C++标准库根本互斥
#include <linux></linux>这类头文件大量使用GNU C扩展（如__attribute__((section(...)))、typeof、语句表达式({...})），而这些在C++中要么不合法，要么语义不同。更麻烦的是，C++预处理器会把class、template等关键字当作标识符，导致linux/types.h里的typedef unsigned int __u32等定义被破坏。
- 必须用
extern "C"包裹所有#include <linux></linux>，否则编译失败 - 不能混用
std::vector和struct list_head——前者依赖堆分配和异常安全，后者是纯C的侵入式链表 -
printk替代std::cout不是风格问题，是std::ostream构造函数会触发静态初始化，而内核禁止全局对象的动态初始化
真正难的不是让C++代码编译过去，而是让每个new、每个虚函数调用、每个模板特化都经得起中断上下文、无页错误、无锁竞争的考验。很多看似“能跑”的C++模块，一进中断处理就因隐式内存分配或未屏蔽中断而死锁——这些坑不会报错，只会静默崩溃。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
