随着摩尔定律的失效，CPU的计算能力不再是可以廉价获得的无限资源了。在多核时代，提高系统的运行速度，采用并发的多线程无疑是最重要的手段了。

在多核系统中，采用何种并发制御方式会极大的影响系统的运行效率，这两天做了一些实验。通常来说，多线程的并发制御主要分为两大类，一类是Polling的轮询方式，也就是Sleep， SwitchToThread，还有一类就是Blocking的阻塞方式，比如Mutex，WaiteForSingleObject这类方式。

简单实验的结果，发现系统的CPU数目越多，并发的线程数越多，使用阻塞方式进行同期制御的程序会更快一些，同时因为不需要轮询，所以CPU的占用率更低。反之，CPU和并发线程数少的时候， Polling的方式更有优势。

为了测试比较多线程的性能，这次用了Intel的Vtune中的Thread Profiler，发现还是相当好用的，不过要注意Intel Profiler无法直接监视基于内存变量的同期制御。这时要调用Profiler的API来告诉Profiler，同期计数器开始，结束，取得，释放的时间点才行。

前两天坐自动扶梯的时候，脚下拌蒜，结果来个后空翻，右边肋骨被磕了一下，这两天好痛，起床都要运半天气。幸好还没有骨折，算是不幸中的万幸。好痛苦呀

这两天在写一个C++类的单元测试，为了确认运行结果，需要访问C++类的Private成员，

为了不修改被测试的C++类的源代码，比较猥琐地使用宏定义将private改成public，

#define private public

#include <xxx.hpp>

...

#undef private

 测试static函数，就比较麻烦了

首先要Include相应的c文件，有时交叉引用会导致无法编译通过，相当麻烦。

注意在C的头文件中要加上下面的宏定义

#ifdef __cplusplus
extern "C" {
#endif

C函数定义

#ifdef __cplusplus
}
#endif

或者

extern "C" {

#include "aaa.h"

...

}

今天在编译一个程序时，发生了下面的错误。

libcmt.lib(sprintf.obj) : error LNK2005: _sprintf already defined in msvcrtd.lib(MSVCR80D.dll)

调查发现，编译程序中调用的DLL是使用动态链接进行编译的，但是这个程序又链接了一个使用静态链接的库，这两个库恰好又同时用到了sprintf这个函数，这就导致了命名冲突的问题，将两个库都使用动态链接后就改好了这个问题。

MSDN上有一篇文章讲了静态和动态链接的区别。

http://msdn.microsoft.com/en-us/library/abx4dbyh%28VS.80%29.aspx

一个开源的矢量绘图工具Inkscape

Delphi本身是不直接支持写Printf这样的变参函数，Format这样的函数类似于Printf，但是还是要多写两个括号，

我觉得太麻烦，其实我们可以间接的实现这样的函数，懒得解释，贴了段程序

program TestVar;

{$APPTYPE CONSOLE}

uses
  SysUtils, Windows;

type
  VA_FN = function(const par1{, ...}: PAnsiChar): Boolean; cdecl varargs;

vsnprintf和wvsprintf的唯一区别就是wvsprintf函数不能处理浮点格式化字符串。

倒霉的是Delphi自带的Windows.pas里面只提供了wvsprintf的定义。要想使用vsnprintf，我们需要引用MSVCRT.dll中的

vsnprintf函数

function _vsnprintf(buffer: PAnsiChar; count: size_t; format: PAnsiChar): Integer; cdecl;varargs; external 'MSVCRT.DLL' name '_vsnprintf';

在Delphi2010的Windows.pas有下面的API定义

function CloseTouchInputHandle; external user32 name 'CloseTouchInputHandle' delayed;

CloseTouchInputHandle这个API是Windows7特有的API，在以前的Delphi版本中，一旦我们的程序使用了这个API，并且在Window7以外的操作系统上运行时，在加载的阶段就会报错。但是在Delphi2010上由于使用Delayed这个属性，则在运行时真正调用到了这个API的时候才会抛出异常。

这两天为程序添加一个接收资源管理器中拖放过来的文件功能，结果发现一个问题，在Vista上通常权限的情况下，可以正常接收资源管理器的拖放，但是一旦程序提成权限为管理员时，就不能接受拖放了，查了一下原来是Vista的权限管理禁止在不同权限的进程间使用基于COM的拖放，这样会有安全漏洞。