似乎，好像，大概，可能

无心人

也许 某些资料显示 查阅网络 猜测 C++ 0x STD扩展TR1可能加入无限整数 呵呵

无心人

现在问题 x = 9么？

无心人

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1744.pdf

gxqcn

上面那个文档中标记的日期是：2005-01-13 记得几年前 CSDN 上也曾有人提及此事，当时我就发现其头文件声明的与我的及其相似。 可惜刚才我去搜那个帖子未得。 但估计成为标准是很困难的，因为大数运算的算法还有许多可挖掘之处， 即便完成估计也只能适用于小规模的大数计算，因为其预定的复杂度并不够好。

无心人

底层小规模的运算缺少硬件支持很难做的 但如果加入GMP的帮助 也许能改善

gxqcn

近期我一直在脑袋里规划未来的 HugeCalc，下面抛出一些构想： 1、底层用标准 C 写；最后才用 C++ 包装； 2、让用户预先设定运算规模，依规模而切换不同的数据类型（比如2进制系统中，可能用2^32，也可能用2^24作进制）； 3、核心层为与硬件相关的函数，依用户硬件环境自动切换函数指针； 4、而后是多核的全面支持：基本的加、减、乘等； 5、将十进制/二进制内核系统不同的基本函数（加、减、乘等）用一个函数指针数组包装，方便切换，类似于 OpenSSL； 6、上层不再用 HugeInt/HugeIntX 区分，而是指定其内核类型，除非用户指定转换系统内核，否则保持不变； 7、这样功能更强大，比如允许不同系统内核的变量混合运算； 8、win32/win64 尽量用同一套代码。

无心人

1、建议增加汇编，和 C平行就可以了 核心保持同一套函数接口，使用自动切换 8、我想，如果能做到核心接口的一致，这个也能做到 关键在内核的设计 2、我想大数据运算，还是2^32合适吧 4、多核支持，我觉得不应该在内核实现 应该在算法级实现 6、上层建议使用C++的强大功能，实现一个统一接口 不同环境的定制，可借助类的静态变量作标志来切换

gxqcn

上述观点基本认同。 但“多核支持”应用时机上： 大数算法，很多并不容易切分任务以合理分配给多核运算，尤其是不限定核数时， 倒是最基本的算法 + - * 等方便任务切分，同时在线程池设计上更容易。 将“多核支持”应用在最基本的算法 + - * 上的另一个好处是： 全面提升算法库效率，而不是单个函数的效率， 且后者在线程池的维护上也会非常麻烦。

无心人

你会后悔的 =============== 好吧 你设定个开关 能决定是否开启这个功能 =============== 否则，某些运算可能非常 消耗资源，但会被不消耗 资源的运算抢占CPU 由用户决定吧 ============== 呵呵

无心人

另外，我觉得核心功能要高度精简 越少函数，越少功能越好 连错误检查和参数检查，通用性都 不要在内核进行，内核必须假定输 入正确，假定资源充足 ==================== 多核计算在上层未必损失效率