因为Long型可以用来作指针嘛！
再来看看工作流程，当我们用AddressOf CompareSalaryName做为函数指针参数来调用qsort时，qsort的形参pfnCompare被赋值成了实参CompareSalaryName的函数指针。这时，调用Compare来强制回调pfnCompare，就相当于调用了如下的VB语句：
Call CompareSalaryName(ArrayPtr + (i - 1) * nElemSize, _
ArrayPtr + (j - 1) * nElemSize, 0, 0)
这不会引起参数类型不符错误吗？CompareSalaryName的前两个参数不是TEmployee类型吗？的确，在VB里这样调用是不行的，因为VB的类型检查不会允许这样的调用。但是，实际上这个调用是API进行的回调，而VB不可能去检查API回调的函数的参数类型是一个普通的Long数值类型还是一个结构指针，所以也可以说我们绕过了VB对函数参数的类型检查，我们可以将这个Long型参数声明成任何类型的指针，我们声明成什么，VB就认为是什么。所以，我们要小心地使用这种技术，如上面最终会传递给CompareSalaryName函数的参数"ArrayPtr + (i - 1) * nElemSize"只不过是一个地址，VB不会对这个地址进行检查，它总是将这个地址当做一个TEmployee类型的指针，如果不小心用成了"ArrayPtr + i * nElemSize"，那么当i是最后一个元素时，我们就会引起内存越权访问错误，所以我们要和在C里处理指针一样注意边界问题。
函数指针的巧妙应用这里已经可见一斑了，但是这里介绍的方法还有很大的局限性，我们的函数必须要有四个参数，更干净的做法还是在VC或Delphi里写一个DLL，做出更加符合要求的API来实现和CallWindowProc相似的功能。我跟踪过CallWindowProc的内部实现，它要做许多和窗口消息相关的工作，这些工作在我们这个应用中是多余的。其实实现强制回调API只需要将后几个参数压栈，再call第一个参数就行了，不过几条汇编指令而已。
正是因为CallWindowProc的局限性，我们不能够用它来调用外部的函数指针，以实现上面说的第三种函数指针调用方式。要实现第三种方式，Matt Curland大师提供了一个噩梦一般的HACK方式，我们要在VB里凭空构造一个IUnknown接口，在IUnknown接口的vTable原有的三个入口后再加入一个新入口，在新入口里插入机器代码，这个机器代码要处理掉this指针，最后才能调用到我们给的函数指针，这个函数指针无论是内部的还是外部的都一样没问题。在我们深入讨论COM内部原理时我会再来谈这个方法。
另外，排序算法是个见仁见智的问题，我本来想，在本文提供一个最通用性能最好的算法，这种想法虽好，但是不可能有在任何情况下都“最好”的算法。本文提供的用各种指针技术来实现的快速排序方法，应该比用对象技术来实现同样功能快不少，内存占用也少得多。可是就是这个已经经过了我不少优化的快速排序算法，还是比不了ShellSort，因为ShellSort实现上简单。从算法的理论上来讲qsort应该比ShellSort平均性能好，但是在VB里这不一定（可见本文配套代码，里面也提供了VBPJ一篇专栏的配套代码ShellSort，非常得棒，本文的思想就取自这个ShellSort）。
但是应当指出无论是这里的快速排序还是ShellSort，都还可以大大改进，
因为它们在实现上需要大量使用CopyMemroy来拷贝数据（这是VB里使用指针的缺点之一）。其实，我们还有更好的方法，那就是Hack一下VB的数组结构，也就是COM自动化里的SafeArray，我们可以一次性的将SafeArray里的各个数组元素的指针放到一个long型数组里，我们无需CopyMemroy，我们仅需交换Long型数组里的元素就可以达到实时地交换SafeArray数组元素指针的目的，数据并没有移动，移动的仅仅是指针，可以想象这有快多。在下一篇文章《VB指针葵花宝典之数组指针》中我会来介绍这种方法。
后记：
我学习所以我快乐。
上一页 [1] [2] |
