似乎，好像，大概，可能

无心人

也许
某些资料显示
查阅网络
猜测
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
由用户决定吧
==============
呵呵

无心人

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