最近打算使用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才能完成所有的編譯工作。