重启大整数库 HugeCalc 的研发工作

gxqcn

我想继续保留：兼容 MBCS / UNICODE 字符格式，

但又不想用 std::string 这些 STL 容器，
主要是担心其不同编译器厂商实现的源码不一致，怕有兼容性问题，
毕竟，我无法强迫调用 HugeCalc.dll 的用户必须得在 VC 下开发。

wayne

gxqcn 发表于 2020-2-4 13:43
我想继续保留：兼容 MBCS / UNICODE 字符格式，

但又不想用 std::string 这些 STL 容器，

这是个问题.

C++11里的Unicode支持力度还是挺大的. 有字符串字面量u8, u,  U,char16_t  char32_t 类型,, u16string , u32string .还有codecvt库,支持各种转换.
不过,在C++17里,codecvt 库很多函数都废弃了.  http://www.open-std.org/jtc1/sc2 ... s/2017/p0618r0.html
不过, 有人说,不要慌:c++ : codecvt deprecated. panic?
https://dbj.org/c17-codecvt-deprecated-panic/

不过,讲真心话, 一旦涉及到unicode了,基本上都跟上层的UI扯上关系了, 这个时候,一般的UI库都会对unicode有大量丰富的支持,底层的库可以不用操心.

..

gxqcn

输入输出，向来是一个很繁琐的环节，且大多与平台相关。

我现在用的是 char 及 wchar 数组来表达字符串，
且 数字<-->字符 之间的相互转换，完全是由自己编写的代码来完成，以期获得足够高的效率。

不知，改用 std::string 或 std::wstring 之类的容器后，
若仅内部使用，自不成问题；
但在 DLL 导出时，是否有问题？
谁创建？谁拷贝？谁销毁？
拷贝的数据格式是否匹配？

liangbch

如果使用VC，当心local heap问题。例如，如果在dll创建一个std::string,在exe中析构这个对象时可能导致程序崩溃。

gxqcn

嗯，正因为 DLL 有此限制（非 VC 的锅），所以我才决定导出的接口，必须是 POD 类型。

wayne

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处理器架构引入

gxqcn

谢谢指点！

ADCX， MULX 将尽可能用上（我前年买的 i7-8550U 应该支持吧），
并有可能将此两个指令作为用户可用 CPU 必须支持的最低条件。

关于汇编，我打算先安装 Intel C++ Compiler，它允许内联汇编，看看效果；
如不行，再考虑独立汇编。

无心人

ADCX/ADOX是ADX扩展
ADCX  r, r/m
CF:r = r + (r/m）+ CF

ADOX  r, r/m
OF:r = r + (r/m）+ OF

该指令7代SkylakeX处理器架构引入