我想继续保留：兼容 MBCS / UNICODE 字符格式，
但又不想用 std::string 这些 STL 容器，
主要是担心其不同编译器厂商实现的源码不一致，怕有兼容性问题，
毕竟，我无法强迫调用 HugeCalc.dll 的用户必须得在 VC 下开发。
gxqcn 发表于 2020-2-4 13:43
我想继续保留：兼容 MBCS / UNICODE 字符格式，
但又不想用 std::string 这些 STL 容器，
这是个问题.
C++11里的Unicode支持力度还是挺大的. 有字符串字面量u8, u,U,char16_tchar32_t 类型,, u16string , u32string .还有codecvt库,支持各种转换.
不过,在C++17里,codecvt 库很多函数都废弃了.http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0618r0.html
不过, 有人说,不要慌:c++ : codecvt deprecated. panic?
https://dbj.org/c17-codecvt-deprecated-panic/
不过,讲真心话, 一旦涉及到unicode了,基本上都跟上层的UI扯上关系了, 这个时候,一般的UI库都会对unicode有大量丰富的支持,底层的库可以不用操心.
..
输入输出，向来是一个很繁琐的环节，且大多与平台相关。
我现在用的是 char 及 wchar 数组来表达字符串，
且 数字<-->字符 之间的相互转换，完全是由自己编写的代码来完成，以期获得足够高的效率。
不知，改用 std::string 或 std::wstring 之类的容器后，
若仅内部使用，自不成问题；
但在 DLL 导出时，是否有问题？
谁创建？谁拷贝？谁销毁？
拷贝的数据格式是否匹配？
如果使用VC，当心local heap问题。例如，如果在dll创建一个std::string,在exe中析构这个对象时可能导致程序崩溃。
嗯，正因为 DLL 有此限制（非 VC 的锅），所以我才决定导出的接口，必须是 POD 类型。
gxqcn 发表于 2020-2-5 09:10
嗯，正因为 DLL 有此限制（非 VC 的锅），所以我才决定导出的接口，必须是 POD 类型。
是的, std::string不是pod类型.
一般非pod类型的数据类型往往会因为编译器的实现不同 内存布局可能不同. 所以不宜作为跨语言的接口.
===
在我看来, 如果C++的API设计充分利用OOP, 以及RAII特性的话,就可以不用特别在意pod这种考虑了.
说两点，
第一、AVX512下,SSE2上有ADCX/ADOX， MULX等专注于大整数计算的指令，相对AVX512，支持的处理器，普及度是很高的
第二、汇编直接写独立汇编文件即可，64位下，win平台，linux平台各有一套自己的函数参数，寄存器规则调用，
而且64只有这两套，win的可以在微软网站查到，遵循这个规则，就可以无缝链接汇编和C++
这里有相关研究文档
这个网站专门研究汇编和处理器优化相关资料
Intel处理器文档卷1：Basic Architecture
Intel处理器文档卷2：Instruction Set Reference, A-Z
MULX是BMI2扩展
MULX ra, rb, r/m
rb:ra = (r/m)*(rdx|edx)
该指令4代haswell处理器架构引入
谢谢指点！
ADCX， MULX 将尽可能用上（我前年买的 i7-8550U 应该支持吧），
并有可能将此两个指令作为用户可用 CPU 必须支持的最低条件。
关于汇编，我打算先安装 Intel C++ Compiler，它允许内联汇编，看看效果；
如不行，再考虑独立汇编。
ADCX/ADOX是ADX扩展
ADCXr, r/m
CF:r = r + (r/m）+ CF
ADOXr, r/m
OF:r = r + (r/m）+ OF
该指令7代SkylakeX处理器架构引入