C++生成DLL不导出友元类引发栈损坏异常如何解决

这个栈损坏错误没有任何玄学，纯粹是跨DLL使用C++类时，两侧的类内存布局完全不匹配导致的，和友元声明本身没有关系。

看你写的复现项目就能直接定位问题：你在测试EXE里自己手写了一份dll.hpp重新定义DLL里的类，这份定义和DLL内部真实的类结构差得非常远：

• DLL内部真实的AddC类包含一个std::string类型的成员变量_fake_string_，64位程序下这个成员通常占32~40字节，整个AddC类的大小和string成员占用空间一致；
• 你在EXE侧定义的AddC是空类，按照C++标准空类的实例大小只有1字节。

这直接导致两侧对CTestDLL类的内存布局认知完全错位：

• DLL侧认为CTestDLL的内存排布是：开头是占几十字节的AddC addc成员，后面才是int result成员，整个类大小有四十多字节；
• EXE侧认为CTestDLL的内存排布是：开头是4字节的int result，后面是占1字节的空类AddC addc，算上内存对齐整个类也就8字节左右。

崩溃的逻辑非常直白：

1. 你在main函数栈上创建CTestDLL test变量时，EXE的编译器只按照自己认知的8字节大小在栈上分配空间；
2. 调用DLL导出的CTestDLL构造函数时，构造函数会按照DLL侧认知的四十多字节大小，往这块栈内存里写数据，直接越界覆盖了test变量后面的栈保护字段、返回地址等数据；
3. main函数退出时，栈安全检查逻辑检测到栈内存被非法改写，直接抛出Run-Time Check Failure #2 - Stack around the variable was corrupted异常。

你最开始写的简化复现（只有带友元声明的A类）也是同一个问题：只要导入侧的类定义和DLL内部的类定义不完全一致（漏成员、顺序错、对齐参数不一样、条件编译开关不一致），都会触发这类内存错误，和友元关键字没有任何关系。

• 最基础的要求：不要自己在调用侧重写、修改DLL导出类的定义。DLL导出C++类时，必须直接给调用方提供编译DLL时用的那份准确头文件，保证两侧看到的类定义一字不差，成员顺序、类型、对齐选项完全一致。你现在手写的头文件不仅漏了AddC的string成员，还把result和addc的顺序写反了，内存布局不可能匹配。
• 如果不想暴露DLL内部的私有实现细节（比如内部的AddC类、私有成员），就不要直接导出整个C++类，换用更安全的跨模块接口方案：
  • 导出纯虚抽象接口：对外只暴露没有任何非静态成员变量的纯虚基类，DLL内部返回接口指针，所有实现逻辑完全藏在DLL内部，调用方不需要知道实现类的内存布局；
  • 用PIMPL（指针到实现）模式：导出的公开类里只放一个指向私有实现的不透明指针，所有私有成员、内部类全部放在DLL的cpp文件里定义，公开类的大小永远是一个指针的长度，不会出现布局错配；
  • 直接导出C风格的普通函数接口，完全规避C++跨模块的内存布局、名称修饰、CRT版本不一致等一堆兼容问题。

注意：C++标准没有规定不同编译单元里的同个类定义不一致时要给你报错，只要能链接通过，编译器就会生成程序，这类布局错配问题不会在编译阶段暴露，跑起来会随机出现崩溃、数据错乱，没有任何侥幸空间。

内容的提问来源于stack exchange，提问作者Jidcoo