关于 HugeCalc 的bug/意见/建议反馈

eMath

首先，非常感谢您选用 HugeCalc 算法库，愿它能给您带来方便快捷的服务！

如果您发现了 bug，请您及时将 bug 描述、软硬件环境等信息反馈给作者（若同时附上相关截图则更好），以便及时修正

如果您可以提供更好的算法、资料（如网上链接）等，请您与作者联系交流，以便共同进步

如果您在使用过程中，发现有不合理之处、或有好的建议，也请您及时与作者讨论，以便逐步完善

对于善意的批评和建议、对于有价值的反馈，作者将会特别致谢，并免费提供注册码（或注册版）。

lijeki

算法库需要用到哪个版本的编译器？我用Dev-C++编译好象不能通过

gxqcn

我用的是VC6.0，没用过Dev-C++，也是第一次听说编译不过的问题。
你检查一下看是不是缺少头文件支持？

lijeki

可能是两个版本不兼容吧，我把main(){}里面的内容去掉，只留下头文件还是不行，我下载VC试试

mathe

今天用了一下
CHugeInt& CHugeInt::InvertMod(CONST CHugeInt& hugeInvertBase, CONST CHugeInt& hugeMod);
看了下文档说明，说hugeMod是模，hugeInvertBase是底，返回模逆数。
所以我就以为用法是
r=CHugeInt::InvertMod(base, mod);
结果链接出错，我才知道，使用方法应该是
r.InvertMod(base,mod);
这里文档说明容易让人误解，最好修改一下。
至少那么UINT32版本是static函数，这些区别也应该写出来。

此外还有比较奇怪的是使用
CHugeInt u=u1*p1+u2*p2;
编译会报错(VC2005下面)
但是使用
CHugeInt u(u1*p1+u2*p2);
不会报错(其中u1,p1,u2,p2都是CHugeInt)
这两种格式应该都是允许的。
其实构造函数
CHugeInt::CHugeInt(COSNT CHugeInt& x);
不应该加上explicit声明。
实际上，我觉得除了CHugeInt和CHugeIntX之间转化需要explicit以外，其他简单整数类型
转化到CHugeInt和CHugeIntX也没有必要加explicit。

gxqcn

关于第一个问题，
之所以定义返回为引用，而非对象，是为了省掉一个潜在的构造拷贝过程，一切为效率着想！
类似的函数还有：PreviousPrime、NextPrime、Gcd系列、Lcm系列、GcdEx、InvertMod和PowMod系列，
这些函数在 namespace HugeCalc 中，与 class CHugeInt（或 class CHugeIntX）中的定义确实存在略微差异，
确实应该在帮助文档中强调一下。谢谢提醒，等下一版吧。。。

关于第二个问题，即 explicit 关键字限定问题，
因为有系统自带的数据类型，也有库新定义的大数类型，很容易混淆，加该限定是防止编译器进行隐式转换，以防出现错误的构造方式或不必要的构造，比如已有函数：
CONST BOOL operator <( CONST CHugeInt& left, CONST SINT32 s32Num );
CONST BOOL operator <( CONST CHugeInt& left, CONST UINT32 u32Num );
CONST BOOL operator <( CONST CHugeInt& left, CONST CHugeInt& right );
当用户调用 (left < 3)?true:false 时，不希望错误地编译成代价最高昂的第三种形式。
这个例子可能举得不很贴切，但加explicit 关键字归根结底是为了编译行为的可控制（宁可犯编译错误也不要犯运行错误）。
况且，正如楼上所说可以用拷贝构造模式，来替换“赋值”模式即可。
对用户的麻烦是某些时候必须多敲入一些类名来显示地定义一些中间结果的类型，但并不影响性能。

mathe

不过对于大部分用户来说，使用方便比性能更加重要。
所以像GMP的设计，如果要性能，可以用C接口，而C++接口最主要还是为了使用方便

gxqcn

关于 explicit 关键字的限定，
未来也许会采用“外松内紧”的模式：即库内部加强限制，外部调用减弱限制；核心类加强限制，代理类消弱限制。
当初普遍采用加 explicit 关键字限定，一是为了防止算法库编译行为的可控制，二是仅出于整齐美观考虑

无心人

大数寄存器，临时的变量
就是类似内存池的东西

但存在不同
1、数量有固定限制，比如说128个
2、是全局的，且带隐含标志，表明使用的状态
3、销毁属于延迟销毁，在复制，比较等完成后销毁
   销毁时机属于不好控制的东西
   就是小GC算法了

你算法里的是什么情况？

gxqcn

记得曾与楼上的已讨论过这个问题，而在这个主题下交流似乎略有不适合。

我一直没闹明白“大数寄存器”是指什么？
因为一个大数能有多大？可以几个字节，也可几百MB，所以根本没法通过静态空间去实现，
也无法预测用户一次性需要的“大数”数目，所以即便用有限变量去追踪变量存活周期也不现实，

况且我用的是DLL实现的，它有更多的限制，
DLL入口函数DllMain只是在Windows系统里注册的一个回调函数（call back），
在系统初始化DLL的时候，它（PE Loader）会自动定义一个进程内的global lock，
防止进程里的其他线程同时运行函数里的代码，或者说是它要线性化(serialize)对DllMain的调用。
所以，DllMain中只应该进行一些简单的初始化，而不要调用LoadLibrary(Ex)，或者可以引起线程/进程载入DLL的API，比如：
    CreateProcess / CreateThread
    GUI API (载入gdi32.dll或user32.dll)
    Registry API (advapi32.dll)
    CoInitiaklize(Ex), CoUnInitialize (ole32.dll)
    malloc / calloc / free (msvcrt.dll)
    GetModuleFileName, GetModuleHandle, 等等：尽管它们不载入DLL，但会引起系统产生一个Lock，因此有可能产生死锁（deadlock）。
    ExitThread：如果你在DllMain里调用它，则会再次进入DllMain，你当然明白这意味着什么。
    I/O（输入输出）函数，可能会引起等待。
在我为多核写代码时，发现线程池初始化可以在普通的UI程序OnInitDialog()中，但DLL中在DllMain函数中初始化却不能。
当时百思不得其解，后来查资料才知道是上述原因。

初始化的时机尚难，确定销毁时机则更难！

现在正面回答楼上的问题：“你算法里的是什么情况？”
还是那句话：我内核用的是C++，变量的初始化/销毁是由构造函数与析构函数自动完成的。再具体的细节，则涉及到编译器和操作系统了，我可就答不上来了。