按照之前写c/c++、java的习惯，这里肯定是等于-3。但是python下返回的结果竟然是1！

为什么会有不同的表现呢？先从取余操作本身说起：

关于取余(modulo operation)

取余的定义

由于不同的架构有不同的数字表示法和运算法，因此他们对于取余的定义也有可能略有不同。

一般来说，公认的取余操作（被除数a、除数n、商q以及余数r，n % a = r）需要满足以下三条：

然而这个定义是非常宽泛的。以 -3 % 4为例：

-3既可以表示为：-3 = 4 * -1 + 1

也可以表示为：-3 = 4 * 0 + (-3)

这两种表示法分别对应了两种实现方法：Truncated Division及 Floored Division。两种实现方法的求商方式不同，导致其最终结果也不同。

Truncated Division

在Truncated Division下，求商时，采用的是q = trunc(a/n) ，即将算数除法结果的小数部分移除，余下的整数部分作为商。

（也有一种更形象的说法，除法取整时，是朝着靠近0的方向取整）

以-3 % 4为例：

q = trunc(-3/4) = trunc(-0.75) = 0

因此，余数r = a - nq = -3 - (0 * 4) = -3

此实现有如下特点：

1. 余数的符号与被除数相同

2. 这种实现在某些地方被称之为取模

Floored Division

在Floored Division下，求商时，采用的是q = ⌊a/n⌋，即将算数除法结果进行向下取整作为商。

以-3 % 4为例：

q = ⌊-3/4⌋ = ⌊-0.75⌋ = -1

因此，余数r = a - nq = -3 - (-1 * 4) = 1

此实现有如下特点：

1. 余数的符号与除数相同

2. 这种实现在某些地方被称之为求余

关于语言标准

由上可知，存在着多种实现方式，那么具体地，c和python是如何选取的呢？

C语言标准中关于取余运算的说明

C89中，并未做严格规定：

When integers are divided and the division is inexact, if both operands are positive the result of the/ operator is the largest integer less than the algebraic quotient and the result of the % operator is positive. If either operand is negative, whether the result of the / operator is the largest integer less than the algebraic quotient or the smallest integer greater than the algebraic quotient is implementation-defined, as is the sign of the result of the % operator. If the quotient a/b is representable, the expression (a/b)*b + a%b shall equal a.

而C99，明确指定了需要使用Truncated Version：

When integers are divided, the result of the / operator is the algebraic quotient with any fractional part discarded.⁸⁸⁾ If the quotient a/b is representable, the expression (a/b)*b + a%b shall equal a.

_{88) This is often called "truncation toward zero".}

Python标准中关于取余运算的说明

Python 2：从说明中关于余数符号的部分，可以推断出其指定了Floored Version

The % (modulo) operator yields the remainder from the division of the first argument by the second. The numeric arguments are first converted to a common type. A zero right argument raises the ZeroDivisionError exception. The arguments may be floating point numbers, e.g., 3.14%0.7 equals 0.34 (since 3.14 equals 4*0.7 + 0.34.) The modulo operator always yields a result with the same sign as its second operand (or zero); the absolute value of the result is strictly smaller than the absolute value of the second operand [2].

The integer division and modulo operators are connected by the following identity: x == (x/y)*y + (x%y). Integer division and modulo are also connected with the built-in function divmod(): divmod(x, y) == (x/y,x%y). These identities don’t hold for floating point numbers; there similar identities hold approximately where x/y is replaced by floor(x/y) or floor(x/y) - 1 [3].

Python 3：和2一样，可推断出指定Floored Version

The % (modulo) operator yields the remainder from the division of the first argument by the second. The numeric arguments are first converted to a common type. A zero right argument raises the ZeroDivisionError exception. The arguments may be floating point numbers, e.g., 3.14%0.7 equals 0.34 (since 3.14 equals 4*0.7 + 0.34.) The modulo operator always yields a result with the same sign as its second operand (or zero); the absolute value of the result is strictly smaller than the absolute value of the second operand [1].

The floor division and modulo operators are connected by the following identity: x == (x//y)*y + (x%y). Floor division and modulo are also connected with the built-in function divmod(): divmod(x, y) == (x//y, x%y). [2].

结论

一些推断及其他

最后，来小小地猜测一下，为什么c语言和python会选取不同的实现方案。

对于c：

在X86架构下，对于整数的除法和取余操作，都是通过同一个指令进行的（有符号除法使用idiv，而无符号为div），商和余数会同时作为结果返回在寄存器AX和DX中。

这个特性被c的库函数divmod所利用，导致编译器有可能会将除法及取余操作都优化为使用一个指令完成。

这样一来，通过如下三条：

1. c的除法正好为trunc除（即Truncated Version中取商的方式）

2. 通常程序里除法出现的频率都远远高过取余的频率，取余可能会被优化为一个指令

3. c语言设计风格为性能和简洁优先，而c++又要与c兼容

因此c语言采用了Truncated Version。

而这也为一个常用的判断埋下了坑：

如果你想判断一个数是否是奇数，

会埋下大坑（对负数存在bug）

而需要写成

对于python：

不会像c那样将性能放到第一位，会比c有更多的语法糖，更贴近常用思维，因此使用Floored Version会更加适合。

参考文献

https://en.wikipedia.org/wiki/Modulo_operation#Remainder_calculation_for_the_modulo_operation

https://docs.python.org/2/reference/expressions.html#arithmetic-conversions

http://stackoverflow.com/questions/3609572/does-either-ansi-c-or-iso-c-specify-what-5-10-should-be

http://stackoverflow.com/questions/11630321/why-does-c-output-negative-numbers-when-using-modulo

于是就做出了这么一个玩意……

其原理是，利用GetForegroundWindow()来获取正在使用的窗口句柄，然后根据句柄找进程所对应的exe文件名

用GetLastInputInfo()来判断闲置

x掉以后会缩在墙角的任务栏里偷偷写日志记录

顺便也做了日志的导入功能，考虑到明文可看性，没有用二进制来写。不过目前只能按天来导入嗯（日志文件是按天数分的，只做了单文件的）

看着诸如devenv之类的记录名也感觉哭笑不得，不过懒得再加自定义映射模块了，反正自己用也没大碍

当然只有如我这样极端缺乏记忆力和行动力的人才会想到做这种东西吧╮(╯_╰)╭

界面用的是qt，以前做界面一直很苦手，用gdi画图，代码又啰嗦还丑；又不想重复发明轮子，于是借此机会正好熟手一个界面库

大家都说mfc又复杂又难学，正好我mfc零基础，直接就扔掉了；剩下的guichan，gtk+，qt，前者名气不够大，gtk+又是c为主，就选了qt。再说qt名字读起来好萌，cute啊

但是做这么一个小程序完全没法掌握qt的精髓，也没有可供对比的经验，所以也就无从而谈使用体会了。顺带说下，qt的dll体积非常大（vc编译好的两个主要dll加起来要超过10M，我的exe才70k），可能是因为其支持跨平台的特性导致的。而我这个程序从设计上就是windows only= =

有触手说做windows程序干脆用c#得了，但是我觉得自己开坑的语言实在太多了= = 再说c#大概有两年没碰过了

这次的总结有三：

1.设计还没明确就开工了，导致很多功能都是测试时才确定下来的。但是测试只能看到短期需求，具体使用是长期需求口牙

2.选了个不怎么搭配的库，浪费了qt的跨平台特性

3.代码还是一团乱啊一团乱，模块没划分好+写出了长函数。就算是小程序也要认真对待啊

先试着对三位进行介绍，再进行基于超级不正规测试的能力大比拼！

说来STL想学好，还是必须要看书呀。学期初借的那本《泛型编程与STL》没看完，《STL源码剖析》没得借又觉得可能会有点难，真是微妙的心情

介绍先行：

1.vector

擅长随机访问、尾部插入/删除操作；不擅长尾部以外位置的插入/删除操作；有点畏惧海量数据

实现原理：类似原生数组一样的连续空间用来存放数据，所以具备原生数组的特点：随机访问，在插入/删除操作时会涉及大规模的数据移动

当容量不够时，会重新分配一个较大的容量（比如说大小为之前容量*2），然后进行内存拷贝、释放旧容量。因此在面对海量数据时，不仅要关注是否有如此大的连续空间，还要考虑在数据增长时重分配空间带来的额外大量拷贝、释放操作。有reserve()方法预分配一定大小的内存，可缓解一些额外操作。

2.list

基本不支持随机访问；擅长对各个位置的插入/删除操作；遍历时取址操作多；数据量不管怎么增长，效率都不会有太大起伏

实现原理：本质是双向链表，所以对各个位置的插入/删除操作游刃有余，也不用担心连续空间的分配问题；但是遍历时有额外取址操作，存储时每个对象也要额外存两个指针

3.deque(double-ended queue)

支持随机访问；擅长头部和尾部的插入/删除操作；

实现原理：可视为是vector与list的中间态，是STL里stack和queue的默认容器。在STL中一般的实现方式是：以一小段连续内存作为整体单位的双向链表，即用一小段连续内存代替了链表中的节点。当遇到连续增长的数据时，也可以用小段连续内存为单位进行分配，比起vector来说平缓温和得多，限制也少。

能力大比拼：

(">"表示优于，测试平台为vs2008 release模式，电脑配置为cpu T4300，内存2G)

1.内存管理

测试方式：插入1000个对象，查看构造函数调用次数：

结果数据：vector 2024  |   list 1001  |  deque 1008

测试结果：list>deque>>vector

2.随机访问速度

测试方式：插入1000个int，分别用[]和::at()随机访问一亿次的毫秒数（使用::at()会额外检查下标越界、异常处理）

结果数据（每次都使用rand()）：vector[]  2750  |  vector::at() 3438  |  deque[] 3390  |  deque::at() 3547  ;

结果数据（预先生成随机数表）：vector[] 141   |   vector::at() 1062  |  deque[]1047   |  deque::at() 1047 ;

测试结果：vector>deque>>list

3.头部插入速度

测试方式：push_front 一百万个int的毫秒数

结果数据：list 1594  |  deque 438

测试结果：deque>list>>vector

4.中间插入/删除速度

测试方式：在已有1000个int数据的情况下，从第500个位置开始插入十万个int、再删除十万个int的毫秒数

结果数据：list插入 157   |  deque插入 1218  |   list删除 1532  |  deque删除 1172

测试结果：list>deque>>vector

（为啥deque的删除会比list快呢，有疑问）

5.iterator遍历操作

测试方式：在已有十万个int数据的情况下，使用iterator顺序遍历1000遍的毫秒数

结果数据：vector 1016  |   list 1437  |  deque 1203

测试结果：vector>deque>list

===================================================================

测试的时候再一次发现了stl在debug和release下的速度巨大差异，说来当初就是这个使自己对stl产生兴趣的

现在想想，大概主要是debug下没有inline吧！毕竟stl基本操作都是函数

但是vs的参数让人感觉还是不够自由，还是要换平台试试sgi stl为好

今日程老师的课刚好提到运算符重载，正好小小应景一下

主要内容来源是《Effective C++》和《More Effective C++》这两本书

================================================================

一、继承“=”时的小陷阱

对父类重载了“=”运算符，子类却没有继承过来!

究其原因，竟是系统自动生成的拷贝赋值函数（即对“=”的重载），覆盖了父类的同名函数

想原汁原味地继承对“=”的重载目前也找不到什么好方法

当然其他的运算符重载无论是继承还是virtual，都遵守普通成员函数的规则

二、重载“=”时请返回引用

因为有连等的情况出现，例如：

a=b=c=d=5，实际上是a=(b=(c=(d=5)))

所以至少要有返回值。那返回对象还是返回对象引用呢？当然是return *this的形式返回引用了！

不然的话，每次都要生成临时变量，进行构造、析构，电脑都觉得累~

顺便说一下，同理要返回引用的还有[]、+=系列、前置的++等。

从返回引用与返回对象的效率对比上，还可以推出另一个好用技巧：

无论什么函数，当函数的参数是较复杂的变量时（比如你自定义的某个类对象），将函数的参数类型改为const & 同样可以提高效率！道理一样是节省构造、析构，前面的const还能保证调入者方面的安心，并保留了值传递时不改动原有对象的特性

最后在重载“=”时别忘了处理自身赋值的情况，比如a=a这样的，把拷贝构造新对象放在析构旧对象的语句之前就好了

三、重载“()”的妙用：传说中的函数对象（伪函数）

是的，“()”也可以重载，比如：

Class Sum{

    int operator ()(int value1, int value2){

        return (value1+value2);

    }

}

然后Sum sum;cout<<sum(2,3)就可以看到5了，调用起来和函数指针一模一样

但是具备了几个函数指针不具备的特征：

1.方便实现inline

inline是在编译期的动作，像函数指针这种运行时的行为不太容易做到inline，但是在以成员函数的方式声明的函数对象想inline还是很容易的。

在VC下，可能会发现qsort比sort还慢，难道那个q不是quick的意思？！

其实是因为qsort使用了函数指针，sort使用了伪函数，因而在内联优化上后者会胜出

2.更多的辅助存储，干掉全局变量！

因为是以成员方法的形式调用的，即是说这个对象的其他成员属性可以拿来做辅助存储，代替了全局变量的作用

3.可以加virtual关键字实现多态

运算符重载的本质是静态链接，而virtual则会导致动态链接，于是这二者在此结合于一身了

四、前置的++与后置的++

1.不同的参数以进行重载函数的区分

二者都是单目运算符，但是运算符重载时需要用不同参数进行区分，后置的要给一个int参数

前置的++：type& operator ++(){...};

后置的++：const type operator ++(int){...};

2.前置++请返回引用

道理同上文提到的“=”重载，同样这也能允许++++i 这样的写法

3.后置++请返回const对象

后置++返回对象应该没什么争议，因为在返回时，原对象的值已经改变了。想要达到“原对象自增一，返回自增前的值”只能返回一个新对象了。

为什么要加const呢？因为如果不这样的话，i++++ 这样的写法过后，先不管能不能编译通过，就算能通过，i只是自增了1次而非两次

因为返回值是新对象，所以链式调用里第二次自增的不是i 而是刚刚产生的新对象

既然无论如何达不到目的，干脆就以编译器报错的方式告诉用户不能这么写好了

4.后置++的实现请调用前置++

因为在 “对原对象自增1” 的操作上，二者是完全一致的，所以后置++就直接调用前置++好了

5.后置++比前置++慢

因为要多生成新对象所以慢。只想要自增效果的话就调用前置++好了，我也没把握编译器会不会帮你把孤零零的后置++优化为前置++

五、基础四则运算也有小技巧!

这回轮到加减乘除了

小技巧就是请返回const对象

这样做的好处是，当你把if (a*b==c)误写成了if (a*b=c)的时候，编译器会显式地指出你这个错误

另外由于运算得到了新值，所以要生成新对象，不能返回引用。

当然如果你写成了a=a+5，不妨改为a+=5： “+=” 的操作符返回的是引用，效率更高

六、重载&&、||前请三思

&&和||有着非常好用的短路特性

比如说if (p!=null && strlen(p)>8)这种写法，你完全不必担心strlen取了一个空的p，因为p为空的话在p!=null后就会立刻跳转了，不会执行第二个逻辑判断条件

但是如果要重载&&和||的话，这个短路特性就要丢失咯

因为重载的本质就是函数，函数调用的时候，无论如何你也无法阻止编译器把传递的参数一个个计算好然后压进栈，更糟糕的是你还可能无法控制在入栈之前各参数计算的顺序。

同理还有逗号运算符，逗号运算符是从左向右依次执行的，重载后这个特性也将丢失

================================================================

其实还有更多技巧未能总结过来，比如说隐式转换对运算符重载带来的危害、operator new和new operator的区别等等，有兴趣的童鞋可以自行翻阅相关书籍

例如： abcd12345循环右移5位，得到12345abcd

第一次遇到这个问题，还是一个朋友当成考研题来问我的，并给出了进一步的限制：时间复杂度为O（N），且只允许使用两个附加变量。

后来在《编程珠玑》、《编程之美》上都看到了这道题

想来按照那个限制的难度，肯定是不会出现在考研卷上的吧，不适合做考题，所以就先无视这个限制

抛开各种算法不谈，就题目本身，也可以得到一些优化信息：
1.虽然题目是右移，但是左移的话也可以一样完成（数组长度为N，右移K位相当于左移N-K位）
在这种情况下，可以分别写出左移和右移的算法，然后根据K与N-K的大小关系，调用移动较少的那个
2.在K大于N的情况下，可以将右移K位简化为右移K%N位

自己当初也想出了多种烂算法，就当抛砖引玉啦，后面会附上几个大牛给出的做法
共有3个自己想的烂算法，3个大牛算法

==============================================================

烂算法1：

是自己最先想到的算法，时间复杂度O(N)，空间复杂度O(1)

实际上是普通排序算法的变异，以两数交换为主，只不过临时变量做了小改动

还是以abcd12345右移5位为例：

a右移5位，跑到2的位置，同时临时变量记录2，此时原串变为abcd1a345

再从2的位置右移5位（位置取模），让2跑到b的位置，同时临时变量记录b，此时原串变为a2cd1a345

再从b的位置右移5位，让b跑到3的位置，同时临时变量记录3……

如此循环数组长度N次之后即可，有个缺点是取模运算比较多

==============================================================

烂算法2：

想要避免取模运算，该怎么办呢？

干脆直接把数组叠两遍，变成abcd12345abcd12345，然后从第5个位置开始截取一段连续的就行了！

其实最后一个元素不用叠，到abcd12345abcd1234就足够了

需要三次memcpy，空间复杂度比其他算法高，需要新开辟空间

==============================================================

烂算法3：

应该是最原始的算法，每次将原数组循环右移一次

temp=a[0];

for (i=0;i<length-1;++i)

    a[i]=a[i+1];

a[length-1]=temp;

移动距离为K就这么做K次
时间复杂度O(K*N)

===================笨蛋和牛人的分界线=========================

牛人提供的算法4：

如果有频繁的移位操作需求的话，干脆做一个封装用来获取元素，而不是直接取下标

这样的话所有的访问都从封装走，每次位置取个余就行了，直接一步到位了
时间复杂度O(1)，空间复杂度O(1)

==============================================================

牛人提供的算法5：（个人认为是最佳算法）

对于abcd12345，将其根据位移长度（5）分为两部分，第一部分为第1个元素至第N-K个元素：

abcd和12345

然后先将这两个部分内部分别倒序，得到dcba 54321

然后再将整个数组倒序，就能得到结果12345abcd

这个大概是符合那位同学所说的“时间复杂度为O（N），且只允许使用两个附加变量”变态要求的答案了。

其原理为UV=((V-1) (U-1))-1（-1为上标，表示取逆）

真是太巧妙了。

顺便说一下，STL里面的rotate函数<algorithm>，就是用这种方法实现的

template<class _BidIt> inline
void _Rotate(_BidIt _First, _BidIt _Mid, _BidIt _Last,   bidirectional_iterator_tag)
{
    std::reverse(_First, _Mid);
    std::reverse(_Mid, _Last);
    std::reverse(_First, _Last);
}

===============================================================

牛人提供的算法6：（很长很长，涉及数学理论，只好一股脑转载了。这也是一个时间复杂度O(N)的算法）
（将此算法与烂算法1进行对比，可深刻体会笨蛋与牛人的区别）
循环置换分解定理：对于给定数组A[0..N-1]向后循环换位N-K位运算，可分解为恰好gcd(K,N-K)个循环置换，且0,...,gcd(K,N-K)-1中的每个数恰属于一个循环置换。其中gcd(x,y)表示x和y的最大公因数。

我们从头开始分析这个问题，对于数组A[0..n-1]，要将其向后循环移动k位元素。因为每个元素右移n位后又回到了原来的位置上，所以右移k位等于右移k mod n位。考虑每个元素右移k位后的最终位置，比如对于A[0]，右移k位后在k mod n位置上，原来在k mod n位置上的元素右移k位后到了2*k mod n的位置上，把如此因为A[0]的移动而受到连环影响必须移动的位置列出来，就是下面这样一个位置序列：0,k,2*k,...,(t-1)k。其中每一项都是在模n的意义下的位置。t*k mod n 的结果是0。t是使得t*k mod n的结果为0的最小正整数。

这个位置序列实质上是模n加法群中由元素k生成的一个循环子群。由群论中的结论(该结论的证明见最后)知，循环子群(k)的周期为n / gcd(k,n)，元数为n / gcd(k,n)，其陪集个数为gcd(k,n)。换句话说，A[0..n-1]循环右移k位的结果是循环子群(k)以及它的所有陪集循环右移一位。例如，将A[0..5] = {1,2,3,4,5,6}循环右移4位，这里n = 6, k = 4, gcd(k, n) = 2。A[0]的最终位置是4,A[4]的最终位置是2,A[2]的最终位置是0，这样，位置0,4,2便是由k=4生成的循环群，周期为6 / gcd(4,6) = 6 / 2 = 3，这样的循环子群共有gcd(4,6) = 2个。

完整代码如下：
// 数组的循环移位

#include <cstdio>

int gcd(int m, int n) {

    int r;

    while(r = m % n) {

        m = n; n = r;

    }

    return n;
}

void shiftArray(int A[], int n, int k) {

    // 因为左移的代码比右移的代码好实现的多，而右移k位

    // 等价于左移-k位，-k = n - k。以下代码是通过左移-k位来实现右移k位

    k = n - (k % n);

    for(int i = 0, cnt = gcd(n, k); i < cnt; i++) {

        int t = A[i], p = i, j = (k+i) % n;

        while(j != i) {

            A[p] = A[j]; p = j; j = (k + p) % n;

        }

        A[p] = t;

    }

}

void printArray(int A[], int n) {
    for(int i = 0; i < n; i++) {

        printf("%-3d", A[i]);

        if((i+1)%10 == 0) printf("/n");

    }

}

int main() {

    int A[] = {1,2,3,4,5,6, 7};

    shiftArray(A, 7, 4);

    printArray(A, 7);

    return 0;

}

上述所用到的那个群论结论的证明：

结论：设G是一个循环群，其中一个生成元素为a，若r和n的最大公约数为d，则a^r的周期为n / d。

在模n加法群中，1是一个生成元素，任意元素k=1*k，所以任意元素k生成的循环子群(k)的周期为n / gcd(k,n)。因为gcd(k,n)=gcd(k,n-k)，所以也可以写成n / gcd(k, n-k)。

一般来说这两个函数应该算是最早接触的那一批才是，但是其参数数目可变的特殊性却被我忽略了好久，直到前一阵程老师上课才发现

于是就稍微整理下好了，主要是va_list, va_start, va_arg, va_end的使用

不多说，直接上代码：

sum是一个求和的函数，其第一个参数为参数数目，后面是要求和的数

#include <stdio.h>
#include <stdarg.h>

int sum(int num,...);

int main(void)
{
    int a=sum(8,2,5,3,6,4,7,8,5);
    int b=sum(4,5,1,2,3);
    printf("a=%d, b=%d\n",a,b);
    getch();
    return 0;
}

int sum(int num,...){
    va_list ap;
    int s=0;
    va_start(ap,num);/* ap初始化，从num开始*/
    while (num>0){
        s+=va_arg(ap,int);/*从参数里取一个新值，同时ap向后移至下一个参数的位置*/
        --num;
    }
    va_end(ap);
    return s;
}

输出结果为a=40,b=11，好用

可变参数函数的声明特点是，参数列表里有“...”出现，表示此处可以接纳无限多个参数

我们都知道函数传参的时候是从右往左依次压栈的，所以参数的地址是连续的，只要从头往下一直移啊移的又不越界，多少个参数的值都能取得到。

在具体代码里，首先定义一个va_list指针ap，取各个参数的值就靠他了；

va_start给ap的地址初始化；注意此时ap指向的地址其实是num的下一个参数

之后每次调用va_arg时，会返回ap指向的参数的值，同时ap会移动至下一个参数的地址

所以在调用va_arg时要传入你要读入的变量的类型（即大小）使之能移动合适的距离

最后使用va_end来释放资源。

通过翻头文件，发现其实va系列的全都是宏：

va_list的：

typedef char * va_list;

（原来就是一个char*的指针啦）

va_start的：

#define va_start(ap,v)  (ap = (va_list)&v + _INTSIZEOF(v))

（可以看到ap指向的是v的地址+v的大小，即v的下一个参数）
va_arg的：

#define va_arg(ap,t) (*(t *)((ap += _INTSIZEOF(t)) - _INTSIZEOF(t)))

（可以看到，会让ap挪到下一个参数，同时返回ap挪之前那个参数的值）
va_end的：

#define va_end(ap) (ap = (va_list)0)

（看上去好像没什么用，但是说不准哪个平台下va_list是分配的堆内存，那届时这里的释放操作就很必要了，所以va_end不能省）
同时注意到他取变量的大小，使用的不是sizeof而是另一个宏_INTSIZEOF：

#define _INTSIZEOF(n) ( (sizeof(n) + sizeof(int) - 1) & ~(sizeof(int) -1))

n的大小都取整到int的倍数了

这意味着就算你输入了va_arg(ap,char)，他也会向后移4个字节指向下一个变量。即：传进来的char变量，实际上占用了int的大小！

令人不禁想起之前提到的struct内存对齐。

上网查询资料，得到了“默认参数提升”（Default Argument Promotions）这个说法：

当函数的参数数量不定时，会发生默认参数提升。默认参数提升，会使char,short变量转换为int类型再压进栈，而float变量会转换为double类型再压进栈。

这样就可以理解为什么printf里%d同时支持int到char，%f同时支持float和double了。scanf里面有%lf来对应double，是因为scanf传递的是地址而不是变量，不受默认参数提升的影响。

#include "stdio.h"

printit(a,b,c){
printf("%u\n%u\n%u\n",sizeof(a),sizeof(b),sizeof(c));
}

int main(void)
{
float a=3.45f;
char b='C';
double c=6.6;
printit(a,b,c);
return 0;
}

最后关于默认参数提升的编译器细节实现，可以移步看某位大牛的博客：

C语言中变长参数中的一个有趣的现象。关于默认参数提升（default argument promotion）

就我个人感觉来看，已经达到平均水准以上了。稍稍留意了一下，无论是习惯、用语、节奏，都是与我一直接触的老师们别无二样；

作为和他一届的同学真是倍感压力。

啊话题扯远了，临下课前老师借由#pragma提到了struct字节对齐的内容，我也只是不久前刚了解的，真是堪堪赶上教学进度~于是写这篇日志总结顺便再温习一下。

给出这样一段代码：

struct test{
    char a;
    long b;
};
void main(){
    struct test t1,t2;
    memset(&t1,0,sizeof(struct test));
    t2.a=0;
    t2.b=0;
    if (memcmp(&t1,&t2,sizeof(struct test))==0){
        printf("yes\n");
    }else{
        printf("no\n");
    }
    printf("%d\n",(int)sizeof(struct test));
}

struct s1{
    char a;
    long b;
};
struct s2{
    char a;
    struct s1 s;
    char b;
};

#pragma的哪个功能最常见？

我凭借印象回答说是once，老师没点我；在黑板上写下#pragma pack(1)，引出struct的内存对齐。

不过凭印象里面，的确是#pragma once比较常见呀，还有去掉warning、链接lib什么的。可能和老师精通嵌入式开发有关

于是在这里整理下#pragma的几种常见用途好了

1.#pragma pack(x)

表示接下来的struct内存对齐以x字节为标准单位（即内存对齐长度不会小于x字节）。使用#pragma pack()来恢复使用默认对齐方式

2.#pragma once

加入这个之后，可使头文件在被多次include的情况下只编译一次，避免重复定义等麻烦事；

当然有一个传统的做法是#ifndef xxx -> #define xxx  -> 代码段 -> #endif，用途一样

二者的差异是：

#pragma once编译速度快一些，不用怕想出的宏名冲突，对整个文件有效；

#ifndef支持性更好（特别是非vs编译器上），可针对文件内的部分代码生效

3.#pragma comment( comment-type ,["commentstring"] )

这里的功能比较多，光是comment-type就可以分为5种：compiler，exestr，lib，linker，user

其中lib用的最多，#pragma comment(lib,"bass.lib") 就把bass.lib加入到工程里了，这样就不需要再从工程配置文件里进行设置

其他的就不多提了，这方面的文章一搜一堆~

4.#pragma warning( warning-type , warning-number...)

可以控制编译器的警告输出！比如某个警告一出一大堆你又看着碍眼，就可以利用这个屏蔽掉

warning-type可填once、error、disable、enable、default等，分别对应：显示一次、按错误处理、不显示警告、显示警告、默认设置

warning-number就是警告的代号。当然填法还是多样的，可以几个处理填到一行里，比如：

#pragma warning( disable :  4100 4511 4512 4663 4245 4018 4514)

#pragma warning( disable : 4507; once : 4385; error : 164 )

#prama warning只对所在的头文件、以及包含该头文件的有效

其他的一些用法比如显示编译消息的#pragma message()、开发驱动会用到的#pragma code_seg()、引入资源的#pragma resource ，以及一些针对特定编译器的用法，就不多提了

注释也懒得写了；一个期望半小时搞定的程序竟然拖了三天，真是让人充满了鲨欲

第一天：先在有符号数的移位上卡了一阵，后来出现了未知原因，debug到晚上1点也未有进展

第二天：情绪低落中（这种情况哪能不郁闷啊！），后来元气稍稍恢复，推倒重写，在vs上取得了成功；但是tc怎么就是跑不对，我能想到的只有变量长度，也不知道这个该死的wintc怎么debug。继续郁闷中

第三天：在其他电脑上gcc编译了下，发现是64位系统，稍作改动后也成功了；于是果断决定抛弃wintc，太纱布了；加入了对大小4G以上文件的处理功能

至此总算是填上坑了。

说来做sha1的目的一是温习文件操作，二是克服对数学的恐惧。如今看来文件操作方面根本没什么温习到的，数学的恐惧则又加深了一层……

顺带也引出了个小坑：怎么方便地用define来判断操作系统位数呢？自己找到的一个看上去比较巧妙的解决办法是#define OS_BITS (((int)((int *)0 + 1)) << 3)，但是这个起不到判断的效果啊

接下来就是opencv的helloworld和坑了老久的三角形了（望天

舍友开始晚上跑步了，我也考虑要不要一起跑。唯一的阻力是洗澡不方便，我多么想要一个热水器……

最初只因DXSDK文档里说了句推荐用Vertex Buffer而不要用DrawPrimitiveUP（C#里叫DrawUserPrimitive），DrawPrimitiveUP很快被描绘成传说 中的瘟疫，人人都在警告不要接近它。估计有人会想过，既然DrawPrimitiveUP这么不好，为什么还要提供它，难道只是为了显示DX也可以像 OpenGL一样简单地画三角形？

记得当年我就是抱着这种想法在网上狂搜，功夫不负有心人，还真找到了。不过看了很不好意思，人家上来就批判不实际测试、以讹传讹的问题，我也比较懒，没动手测一下。那么为了和我一样的懒人，我把问题用中文解释一遍。

首 先，DrawPrimitiveUP内部其实就是一个dynamic vertex buffer（动态顶点缓冲），和我们自己实现一个动态顶点缓冲没区别。一般情况下，DrawPrimitiveUP和用动态顶点缓冲的效率也没多大区 别。也就是说DrawPrimitiveUP其实很高效的，而且简单易用。Irrlicht引擎几乎所有绘制都用的DrawPrimitiveUP，也很 快的。

那为什么不推荐用？

原因一：DX8发布时显存容量已经有了很大提高，静态顶点缓冲可以缓存在显存或AGP内存里，从而节省带宽占用。所以推荐能用静态顶点缓冲的一定要用静态的。静态的可以比DrawPrimitiveUP和动态顶点缓冲都快很多。

原 因二：DrawPrimitiveUP相对动态顶点缓冲而言，需要将用户内存里的顶点数据复制到内部动态顶点缓冲，即多了一次复制，如果顶点数量较大，复 制开销也会加大。但很多程序里的动态缓冲设计并不太好，为了抽象或方便使用，也会复制一次数据。所以便丧失了这条优势。

原因三：这个比较 复杂，我们知道一帧内Batch（批）的数量直接影响CPU的占用率，1G处理器30FPS下每帧700Batch左右就会占用100%CPU。每个设置 设备状态到发出绘制命令的转换都将产生一个Batch。动态顶点缓冲的推荐使用模式是一个可以合并Batch的模式，即不断地填充顶点数据，但不立刻绘 制，在缓冲填满时才提交绘制一次，当然能合并的前提是各个batch都使用相同的设备状态，即纹理、材质、RenderStates、变换矩阵等。

原因四：DrawPrimitiveUP只支持一个顶点流。这其实是个不算是原因的原因。当然是只用一个顶点流时才用它。

综上所述，这其实是个优化问题，用动态顶点缓冲有可能做更多的优化，但如果做得不好，会比DrawPrimitiveUP差。如果正确使用了，但没有进一步的优化或者引擎的用法不具备可优化的特性，那么也就和DrawPrimitiveUP效率相当。

但 事实上用动态顶点缓冲做错了的也很多，最常见的就是没有正确使用Lock标志位，用锁定静态缓冲的方法锁定，根本得不到动态缓冲的效果。另外用C#和 MDX的，如果用返回数组的Lock方法重载，也完全没有意义，因为在内部整个缓冲被复制到数组，Unlock时再复制回去。即使用 GraphicsStream写顶点数据也很慢，因为会导致大量的Boxing，只有直接用指针写数据才能发挥动态缓冲的优势。

怎么才算做得好，DXSDK里有明确的样例，为了懒人，我帖出来：
// 用法 1
// 每次绘制抛弃整个顶点缓冲内容并重新填充几千个顶点
// 可能包含多个物体，有可能需要按设备状态分几次DrawPrimitive

// 计算需要填充的字节数
UINT nSizeOfData = nNumberOfVertices * m_nVertexStride;

// 抛弃并重新填充
CONST DWORD dwLockFlags = D3DLOCK_DISCARD;

// 锁定顶点缓冲内存
BYTE* pBytes;
if( FAILED( m_pVertexBuffer->Lock( 0, 0, &pBytes, dwLockFlags ) ) )
return false;

// 将顶点数据复制到顶点缓冲
memcpy( pBytes, pVertices, nSizeOfData );
m_pVertexBuffer->Unlock();

// 绘制
m_pDevice->DrawPrimitive( D3DPT_TRIANGLELIST, 0, nNumberOfVertices/3)

// 用法 2
// 对多个物体复用一个顶点缓冲

// 计算需要填充的字节数
UINT nSizeOfData = nNumberOfVertices * m_nVertexStride;

// 如果顶点缓冲内的剩余空间可以容纳要填充的顶点数量，则指定不覆盖原有数据
DWORD dwLockFlags = D3DLOCK_NOOVERWRITE;

// 检查顶点缓冲空间是否用光
if( m_nNextVertexData > m_nSizeOfVB - nSizeOfData )
{
// 没有足够的空间，抛弃原有数据重新开始
dwLockFlags = D3DLOCK_DISCARD;
m_nNextVertexData = 0;
}

// 锁定顶点缓冲内存
BYTE* pBytes;
if( FAILED( m_pVertexBuffer->Lock( (UINT)m_nNextVertexData, nSizeOfData,
&pBytes, dwLockFlags ) ) )
return false;

// 将顶点数据复制到顶点缓冲
memcpy( pBytes, pVertices, nSizeOfData );
m_pVertexBuffer->Unlock();

// 绘制
m_pDevice->DrawPrimitive( D3DPT_TRIANGLELIST,
m_nNextVertexData/m_nVertexStride, nNumberOfVertices/3)

// 计算下一次的写入位置
m_nNextVertexData += nSizeOfData;

当 然，这只是个正确用法样例，优化起来可还是会面目全非的。如果你的D3D功夫不够剑豪剑圣级别，大可安心地用DrawPrimitiveUP，对付一些杂 碎三角面，也大可不必杀鸡用牛刀，用DrawPrimitiveUP剁几下就行了。另外注意测试的时候一定要用硬件模式测，软件模式的结果是完全不同的。