缥缈峰

根据ISO/IEC 14882:2003(E)对C++的标准定义来看,第15页到19页,一个integer后缀可以为:
uU, fF, lL

不过,微软扩展了一些后缀：
http://msdn2.microsoft.com/en-us/library/00a1awxf.aspx
iN (N=8, 16, 32, 64), LL, ll

比如：-1i16, 256i32等等……


让人疑惑的是这个iN。

对于iN的修饰的整型长度为N位，比如sizeof(0i8), sizeof(0i16), sizeof(0i32), sizeof(0i64) 的值分别为1, 2, 4, 8。

你可以将i8理解为(char), 所以 0i8 == (char)(0)。 (当然ui8就是unsigned char, 0ui8 == (unsigned char)0)

请看下面程序：


全部都是等价的操作。


那么，为什么微软要加这样一个定义呢？

来看看常用的地方：

我个人感觉就是避免了一个显式转换而已，其实也可以定义为：


HOHO~

再来看个例子：
问A等于多少？

要搞清楚这个问题就要知道运算符的优先顺序，"-"是修饰32768还是修饰32768i16的。试验的结果是后者。
所以 -32768i16 被编译器理解为 -(32768i16)。所以 a = -((short)(32768));

不过编译器不支持 (-32768)i16，因为()是表达式了，而i只能修饰定义的常量……

还有一个很让人疑惑的地方就是：


把编译开关设置为 /W4，结果是第一行没有产生警告信息，第二行有丢失数据的警告信息。 我想到的原因就是，常量赋值的时候，编译器很容易做结果检查，所以就自动帮程序员转换成正确的类型了。(你可以试试 char a = 128i32; 就会产生警告信息)。

结论：Compiler is smart enough!

两个文件
A) \Windows\HandCalendar.dll
B) \Storage\HandCalendar\HandCalendar.dll

A是系统的今日插件，已经被Load到内存中了。
B是准备升级的文件。

他们两个都有一个对外函数UINT32 GetVersion()

于是，我先LoadLibrary(A); 获取GetVersion函数地址，调用之得到A的版本号
然后LoadLibrary(B), 这个时候怪事情出来了， LoadLibrary(B)返回的地址还是刚才A的那个（我确信hInst已经被FreeLibrary过，并设置为NULL了）。

然后B的GetVersion的结果更让我确信LoadLibrary(B)的结果的确是返回的A的Handle。

Why?

没有时间去研究这个了，我把B改一个文件名就对了。
\Storage\HandCalendar\HCToday.dll

用CVSnt-2.5.01.1927 + TortoiseCVS-1.9.12，发现无法同步。
其实解决很简单，原因在于两个版本带的cvs.exe版本不同，把CVSnt-2.5.01.1927的cvs若干文件全部覆盖掉TortoiseCVS-1.9.12的即可。屡试不爽~

一段代码发布了很久了，也经历了有限个用户的测试，不够我感觉上始终有问题，于是用Python+IE把Javascript的程序标准集做了出来，好几十MB的TXT啊(跑了好多个小时才跑完-_-)……用来简单一跑，呵呵，问题查出来了，修复之~

做了一次完备性测试，心里踏实多了~ HOHO~

睡觉了~过几天发布掌心万年历的新版本吧~