最近打算使用Google CTemplate作为模板引擎，但是运行其主页上的例子居然出现了错误。程序运行的结果正常，但是在退出时导致了_CrtIsValidHeapPointer异常，主要是释放string变量时出现了错误。搜索了一下Google CTemplate的讨论组，说如果编译库文件所使用的CRT版本和编译程序所使用的CRT版本不一致会导致这个问题。DLL库采用的CRT是多线程DLL方式的，所以应用程序也必须使用这个方式，这就需要在应用程序的工程选项中将CRT由默认的单线程方式改为多线程DLL方式。如下图所示。

 

不过这有时不太方便，也可以把CTemplate所需要的文件直接加到工程中，好在文件不多：

• src\base\arena.cc
• src\htmlparser\htmlparser.cc
• src\htmlparser\jsparser.cc
• src\windows\port.cc
• src\htmlparser\statemachine.cc
• src\template.cc
• src\template_dictionary.cc
• src\template_from_string.cc
• src\template_modifiers.cc
• src\template_namelist.cc
• src\template_pathops.cc

记得在这些文件的编译属性中选择“不使用预编译头”，否则会出现编译错误。

2008年8月31日：以上介绍的是0.90版本，在0.91版本中src\template_from_string.cc 文件不存在了。
2008年9月15日：采用上面介绍的方法有个缺陷，就是会出现很多编译和链接的警告C4251和LNK4049、LNK4071。这主要是因为在CTemplate的代码中，定义了：

 

Code
#ifndef CTEMPLATE_DLL_DECL
# define CTEMPLATE_DLL_DECL  __declspec(dllimport)
#endif

所以需要在编译的命令行加上“/D CTEMPLATE_DLL_DECL=”。

今天早上遇到个小问题，VxWorks程序一下载就停在0%处不动了，但是没有死机。这是怎么回事？检查了一下Target Server，也成功了，但是显示了一个警告信息，说Memory Cach满了，需要使用-m选项设置Memory Cach的大小。在Configure Target Servers对话框中增加了一下Memory Cache Size的大小，就又可以下载了。

最近在指导学生开发VxWorks下的程序，其中要使用双向链表lstLib，由于所参考的VxWorks的书中没有给出例子。写了下面这个简单的例子。

 

今天收到一封来信：

“我的高级链路做了一部分了，而且所做的部分在做完之后已经及时保存。但是写完文档后关闭TAU G2的时候出现死机，我就强行关闭了TAU G2。以前也经常发生类似的情况，可是重新启动TAU G2是可以打开原来的U2文件的。

         可是这回，我再打开U2文件后出现了错误“Error: TNR0085: XML Parser: no element found (file ://D:\贼魔2\基站项目\LLC\LLC.u2, line 40981).”，和“Information: Session in ::[wpAu0I1UtXILmZZ6zELdUAvL]: TMI0760: Failed to load file D:\贼魔2基站项目\LLC\LLC.”的情况，原来的东西打不开了，而由于我的疏忽没有备份。因为我根本没有想到会出现这种情况。

我高级链路已经做了相当多了，快完成任务了，而且老师催得又特别紧，我无法想象重新返工会是多么可怕的事情。附件已经给您一块发来，不知道您能否把这个东西恢复出来。谢谢您了。我现在非常郁闷。”

 这的确够糟糕的。在此提醒大家一定要每天备份程序，最好使用CVS或SourceSafe工具进行程序管理。

 下面介绍一下我是怎么修复这个文件的，当然完全的修复不可能，因为有一部分内容没有存盘，已经彻底丢失了，但总归希望能找回一些，不要彻底重做。.u2文件实际上是一种XML文件，使用UltraEdit打开就可以看出，大致是这样的格式：

在XML中，大多数Tag都是成对出现的，比如<u2></u2>、<Class></Class>等。被破坏的文件没有了后面的这些行，所以TAU G2打开时会报告错误。本来想在网上找一个自动修复XML的工具，不过还没有找到。找到了一个小工具XmlShell，它可以检查XML文件中是否存在着 Tag不封闭的情况。这个工具很小，不到1M，倒是可以帮助解决问题。首先把.u2文件改名为.xml文件，然后使用XmlShell打开，它会报告有一些Tag没有封闭。将编辑光标移动到文件尾，输入“</”。你每次输入“</”，XmlShell都会帮助你自动封闭Tag，直到出现“</u2>”，所有Tag都封闭了，这时再用XmlShell检查文档，它报告这是一个合法的XML文件了。把文件存盘，然后再改回.u2。这时再使用TAU G2打开文件，TAU G2仍然会报告一些错误，但是这是在Model中已经可以看到一些东西了。至于能找回来多少，要看运气。

 类似的工具还有不少，如XML Spy或XmLBuddy。

这篇文章快要写完的时候收到了回信：
“我刚才看了文件，已经恢复了90%，就差2张图和一些函数定义。我昨天做的东西也有一部分恢复出来了。估计再有半天就可以补齐。如果没有您，我估计重新返工得1个月左右的时间。”

很有成就感。

在进行 TAU G2 编程时经常会遇到下面的错误信息：

*************************** ERROR **************************

Dereferencing of NULL pointer.

Pointer assigned new data area at address .

  有必要详细说明一下。

  一般出现这个问题，都是在访问一个类或结构的变量时出现的，例如下面是程序的片段。

在这个程序中，访问 D_attach_detach_group_identity_type 、 Group_identity_downlink_type 和 Group_identity_downlinks_type 这三个变量的成员时都会报告错误。虽然可以忽略这个错误继续运行，但是如果这个错误很多，却是非常麻烦。为什么会出现这个错误呢 ?

  最主要的原因是在 TAU G2 中，类或结构体变量都是看作指针的，如果在 WATCH 窗口看这些变量，在访问变量前，它们都是 null ，而在赋值之后会显示变量的地址，这和 C 语言对指针变量的处理基本相同。所以在给这些变量第 1 次赋值的时候就会报告访问空指针。如果想避免这个问题，就应该在赋值前先使用new 关键词分配空间。如：

这样就可以避免出现此类问题了。

TAU G2 的错误信息常常显得很诡异。不但帮助中找不到，而且字面的意思也不准确。今天又遇到一个：

text.ttp       Error          TSC0134: Transition must end with stop, nextstate or join action. GUID: *gUWtVDd*H5LUiy6sEYVQFxL

从字面的意思看，和状态图有关。但仔细检查以后，发现状态图没有错误，实际上是一个函数中忘了加 return 语句了。

最近在使用CT++这个软件时遇到这样一个问题：这个软件是在FREEBSD下开发的，虽然提供了C语言源程序，但程序在Visual Studio 2003下编译出现错误。检查原因，主要是因为源程序都是UNIX格式，每行的回车都是用一个0x0a字符表示的，而在WINDOWS/DOS下每行的回车都是用0x0d0a两个字符表示的，而该程序注释为俄文，影响了VS2003的处理，把大量的程序代码都当作注释了，所以编译就不能通过。要编译通过，必须先将UNIX文本格式转换为DOS格式的。UltraEdit的FILE菜单中提供了对单个文件进行这种转换的能力，但是一次只能转换一个文件，比较麻烦。经过一番研究，终于找到了一个批量实现转换的方法。在UE中选择Search | Search in files菜单，在Find框中填写^n（表示UNIX文件中的回车换行符号），在Replace with中输入^p（表示DOS文件中的回车换行符号），如下图所示。这样就可以实现批量替换了。

最近在研究如何开发一个编译器，初步决定使用ANTLR。从ANTLR的网站上下载了最新的2.77版本的安装程序（MSI的）。安装之后，使用Visual Studio.NET 2003编译它的C++例子时发现编译照常而链接总是错误。仔细看了一下链接错误，发现是_memcpy_s、___CxxFrameHandler3等函数找不到。memcpy_s是Visual C++ 2005中新增加的函数，主要是为了提高代码的安全性。所有判断2.77安装版本中所提供的库是Visual C++ 2005编译的，无法用到Visual C++ 2003中。看来必须下载源代码版本，自己重新编译库了，不能偷懒了。

从网站上又下载了源代码版本，解开后，发现所需要的C++文件都在lib/cpp目录中。该目录中有一个README文件，介绍了如何在Visual C++ 2003中进行编译，按照其介绍获得了成功。不过它的帮助文件中说需要使能Run Time Type Information，我没有修改相应的选项，目前看也没有什么关系。

     摘要: 今天移植以前用DriverWorks编写的一个驱动到x64平台上，编译时没有什么问题，但链接的时候发现无法找到KPciConfiguration::Enumerate，经过一段时间的探索，找到了一种临时解决方案。由于 KPciConfiguration 的构造函数中也使用了这个函数，而且程序中大量使用了KPciConfiguration类，这意味着要大量修改代码，真是头痛 检查D...  阅读全文 DriverWorks在安装之后不能立即使用，需要先编译库文件，然后才能正常使用。我以前在Windows 2000下使用过DriverWorks，感觉编译库文件非常容易，但这次在Windows Server 2003 SP1 DDK（3790.1830）下进行编译还是遇到一些困难，特别记录下来，以免忘记。
Windows XP以后的DDK越来越复杂，因为每个DDK都要支持多个操作系统和不同的CPU，其目录结构较Windows 2000 DDK有很大不同。
我以前都是在Visual C++ 6.0的集成环境中使用DriverWorks，这次也不例外。启动Visual C++ 6.0后，先点击菜单的DriverStudio | DDK Build Settings项，设置好DDK的路径。


然后打开C:\Program Files\Compuware\DriverStudio\DriverWorks\Source\vdwlibs.dsw，选择菜单的Build | Batch Build进行编译，32位的库(i386)都编译成功了，kndiswdm.lib也都编译成功，但是vdw_wdm.lib和vdw.lib的IA64和AMD64库都报错，没有成功。错误出现在stl库的_threads.h文件的442行:

# else        //*ty 11/24/2001 - added configuration check
#  error "Unknown thread facility configuration"
# endif

在Google上搜了一下，未果；又去驱动开发网上找了一下，没有什么有用的信息，一时陷入了困境。又看了一下帮助，发现它提到编译库一共有三种方法，而我用的只是其中的一种，决定再尝试一种。首先，使用Build | Set Active Configuration切换到Vdwlibs - Win32 AMD64 NT 4 Free项。


再选择DriverStudio | Build with BUILD.EXE，进行编译，没有任何错误，成功了
这真是出乎意料，我本来以为三种方法是一样的，现在看来，Build with BUILD.EXE可能是Compuware内部使用的比较多的选项，测试比较完善。Build with BUILD.EXE一次只能编译一个配置，所以还需要多次使用Build | Set Active Configuration才能完成所有的编译工作。