2009 年 04 月 的封存

對今年的NBA季後賽沒有多大的興趣了!

Posted by gordonliwei in 未分類 on 2009 年 04 月 29 日

Kevin Garnett是我個人自Michael
Jordan之後最喜歡的球員，看Garnett打球也是我最喜歡的休閒活動之一，但今年Garnett深受受傷之苦，到現在季後賽開打也一直沒有回來，因此今年我也沒什麼興致看NBA季後賽了，希望Garnett能夠儘快康復，再打幾年的好球吧。

不過心底卻有一種說不出來的淡淡憂愁 : 『狼王似乎漸老矣』。

1 則迴響

也許我不應該說的!

Posted by gordonliwei in 未分類 on 2009 年 04 月 28 日

自從不再是CG的正式員工之後，我也必須申請參加CG產品的Beta，獲得批准之後我才能拿到Beta的產品來測試。因此前一陣子我也和一些我的朋友一樣申請參加下一版C++Builder/Delphi的Beta，很幸運的我獲得了許可，也終於在最近拿到了Beta版來玩一玩，以便填補一下Diablo 3出來之前苦苦等待的真空時期。
下一版的C++Builder/Delphi在進行Beta測試早已不是新聞了，因為Delphi的產品經理Nick已經公開的討論了許多次，CG現在也在她的網站上公開歡迎有興趣的人申請參加，申請的URL如下:
事實上我也是在上述的URL中申請參加的。
那麼這篇文章到底是討論呢? OK，除了我希望把申請參加Beta的資訊和尚不知道的朋友分享之外，主要的原因就是我有許多已經參加Beta的朋友在測試新版Delphi時發現他們無法在XP下連結到MS SQL Server 2005或是2008，一旦新版Delphi在XP下試著連結2005或是2008時就會出現代號為340的錯誤:

 

我也在大陸的一些網站上看到許多人就開始批評下一版Delphi的DBX驅動程式有大臭蟲，又不穩定，連MS SQL Server都連不上，但我覺得很奇怪的是既然現在是Beta版那當然有臭蟲，否則進行Beta測試是做什麼的呢?不過我想說的是這個340錯誤並不是DBX的臭蟲，而是我的朋友們並不瞭解新的DBX對於MS SQL Server的驅動程式進行了大幅的改變，因此在使用下一版Delphi連結MS SQL Server 2005/2008之前，開發人員需要安裝一個軟體。那麼是什麼軟體呢? 在回答之前，我想順便談談如何進行有效的Beta測試並且以這個例子做為說明，一旦讀者掌握了之後就做個更好的Beta測試人員了。
事實上在我朋友告訴我並且詢問我這個問題之後，我也親自測試了一下，我果然也是遇到錯誤340，無法連結MS SQL Server 2005，但在我確定它是DBX的臭蟲之前，我決定再啟動RAD Studio 2007看看有什麼不同，結果我發現在RAD Studio 2007中，DBX4是使用oledb用戶端函式庫來連結MS SQL Server，如下所示:

 
但是在下一版Delphi中卻改變了使用的用戶端函式庫，DBX4改用了sqlncli10.dll，如下所示:

 

而sqlncli10.dll是MS SQL Server 2008的原生用戶端程式(Native Client)，而這也就是為什麼會出現340錯誤的原因，因為在下一版Delphi的DBX是改用了Native Client來連結MS SQL Server而不再使用oledb，出現340錯誤是因為我們的機器中沒有安裝MS SQL Server 2008的原生用戶端程式的原因。

因此，我到下列的URL中下載MS SQL Server 2008的原生用戶端程式:
http://www.microsoft.com/downloads/details.aspx?FamilyId=C6C3E9EF-BA29-4A43-8D69-A2BED18FE73C&displaylang=en

下載Microsoft SQL Server 2008原生用戶端安裝程式 : sqlncli.msi並且安裝它之後，就可以使用下一版Delphi來連結MS SQL Server 2005/2008了，也不會再出現340的錯誤了。

從上面的討論我們可以推論出下一版Delphi的DBX對於MS SQL Serevr有如下的特性:
  • 它支援最新的MS SQL Server 2008，因此理論上應該支援SQL 2008新的資料型態和功能
  • 由於它使用MS SQL Server 2008原生用戶端安裝程式來連結MS SQL Server 2008，因此它可向後支援MS SQL Server 2005
  • 使用sqlncli10.dll而不再使用oledb，因此下一版的DBX速度會比以前更快
嗯, 推論了上述3點之後我更喜歡新的DBX了。

15 則迴響

善用C++Builder 2009的Pre-Compiled header精靈

Posted by gordonliwei in 未分類 on 2009 年 04 月 21 日

也許是我的記憶已經很模糊了，我記得在C++Builder 5時能夠提供了背景編譯的能力，允許BCB的開發人員在IDE中編譯專案時能夠啟動在背景編譯，如此一來BCB的開發人員就可以在等待BCB編譯專案的同時在IDE中執行一些其他的工作，BCB之所以提供這個功能實則是因為C++是一個3-pass的編譯器，因此需要遠多於One-Pass的Delphi編譯器更多的編譯時間。但當時BCB 5的背景編譯有許多的限制，例如開發人員無法異動正在編譯中的專案，也無法異動編譯專案的圖形使用者介面設計等，因此大部份BCB開發人員使用背景編譯編譯BCB專案時，大都是在BCB的IDE中對其他的專案進行同時開發的工作。

另外一個BCB非常重要的功能就是Code Insight，這個功能能夠幫助開發人員大幅減少需要撰寫打字的程式碼，進而增加開發的生產力。但是我知道很多BCB的開發人員關閉了這項功能，因為在早期的BCB版本中這個功能實在太慢了，導致許多BCB的開發人員抱怨為什麼BCB無法像Delphi的Code Insight一樣那麼的快速。其實BCB的Code Insight太過緩慢的問題我個人也是感同身受，因為我記得每次在做BCB的活動時，為了避免在BCB編輯器中撰寫程式碼反應太過緩慢的問題，我也都是關閉了BCB的Code Insight功能。


 
最後一個我要討論的問題就是BCB的Pre-Compiler Header了，雖然BCB很早就提供了Pre-Compiler Header功能以加快編譯速度，但老實說早期BCB提供的Pre-Compiler Header雖然的確能夠幫助開發人員加快編譯速度，但這個Pre-Compiler Header在C++Builder 2009之前已經有數年沒有改善了，因此仍然有很大的進步空間。

OK，看到這裡您可能會想，為什麼同時敘述上述的三個問題呢?是它們有什麼共點嗎?不然這篇文章到目前看起來是令人摸不著頭緒的。OK，現在就讓我們回到本篇文章的正題。

下圖是我在RAD Studio 2009中的一個範例BCB專案，在沒有使用新的Pre-Compiled header精靈之前，在第一次編譯這個C++Builder專案時RAD Studio仍然會為這個專案建立Pre-Compiled header，如此一來當開發人員稍後再次編譯這個專案時，編譯速度就會加快。例如如果我修改下圖中的
this->Button1->Caption = "test";
為
this->Button1->Caption = "測試";

接著再次編譯，那麼此時C++Builder 2009需要再次編譯21281行的程式碼，雖然整個編譯速度算是相當快速，但仍然令人奇怪，為什麼只是修改一行的程式碼卻需要編譯21281行。

其實仔細觀察原始程式就可以發現問題所在，因為在原始程式中存在如下的程式碼:
#include <vcl.h>
#pragma hdrstop
#include "SecondForm.h"
#include "MainForm.h"
舊的BCB Pre-Compiled header精靈只把VCL.H相關的程式碼預先編譯，但再看看原始程式的表頭檔，我們卻發現了下面的程式碼:
#include <Classes.hpp>
#include <Controls.hpp>
#include <StdCtrls.hpp>
#include <Forms.hpp>
#include <DB.hpp>
#include <DBCtrls.hpp>
#include <DBGrids.hpp>
#include <ExtCtrls.hpp>
#include <Grids.hpp>

問題似乎就出現在這裡，因此我們需要一個能夠分析整個專案的Pre-Compiled header精靈幫助我們產生最佳的預先編譯表頭資訊，並且能夠讓開發人員進行客製化的調整。

C++Builder 2009新的Pre-Compiled header精靈就可以幫助我們完成這些工作，讓我們現在就來看看它的功效如何。
首先點選Tools|Pre-Compiled header Wizard…功能表啟動精靈，如下圖所示，如果你是第一次使用這個精靈，那麼請選擇第一個選項為專案進行一次完整的分析:

 
在精靈成功分析之後，它會顯示如下的對話盒，詢問你客製化的設定，例如你可以設定要包含那些表頭檔或是排除特定的表頭檔。
 
點選『Next>>』按鈕之後會顯示最後精靈進行的設定，它決定了預先編譯表頭檔中包含的資訊:
 
繼續點選『Next>>』按鈕，最後BCB會產生一個新的表頭檔pch1.h，例如在我的範例中最後的pch1.h包含如下的資訊:
/*
  This precompiled header include file was generated on 2009/4/21 下午 03:00:09
  by the RAD Studio Precompiled Header Wizard with the following settings:

  Project: G:MyBogs20090421DemospBCBDemo.cbproj
  AllowUnguarded = 0
  ExcludeProjectFiles = -1
  IncludePathsOn = -1
  IncludePaths =
  ExcludePaths =
  IncludeCount = 1
  ManageHeader = -1
*/

#ifndef pch1_H
#define pch1_H
#include <vcl.h>
#include <tchar.h>
#include <DB.hpp>
#include <DBClient.hpp>
#include <DBGrids.hpp>
#include <DBXMsSQL.hpp>
#include <Provider.hpp>
#include <SqlExpr.hpp>
#include <DBXInterbase.hpp>
#endif

在精靈產生了pch1.h並且加入到專案之中後，請先進行一次完整的專案Build讓BCB編譯器建立新的預先編譯表頭檔。有了新的預先編譯表頭檔之後如果我再回到前面修改:
this->Button1->Caption = "測試";
為
this->Button1->Caption = "第2次測試";

接著選擇make專案，那麼現在BCB只會編譯86行的程式碼，比使用舊的預先編譯方式快了好幾倍的速度。
更棒的是，使用新的Pre-Compiled header精靈之後由於它會產生最佳化的表頭資訊，因此此時如果你再使用BCB的Code Insight，你會發現Code Insight快速的不得了，例如在我的機器中此時再使用BCB的Code Insight功能，它的反應速度幾乎和Delphi的Code Insight一樣快了，現在我再也不需要關閉BCB的Code Insight功能了。

BTW，RAD Studio 2009的Update 3不但修改了許多的臭蟲，IDE的速度又加快了不少，例如對於相同的BCB專案，使用Update 3的編譯速度硬是比Update 1和Update 2又快了許多，絕對建議您儘快昇級到Update 3。

OK，解決了預先編譯和Code Insight的問題之後，最後就是BCB的背景編譯了，在C++Builder 2006/2007/2009中背景編譯都被移除了，因為舊的背景編譯限制太多，在BCB 5那時沒有多核CPU的時代，舊的背景編譯架構也無法利用現在最新的多核CPU，不過我知道下一版的BCB也許將提供全新的背景編譯技術，不但速度快，限制又少，甚至可以讓開發人員在背景編譯專案的同時又進行相同專案的持續開發，這對於大型的BCB專案來說實在太棒了。

試著想想，未來在BCB中我們將可結合預先編譯表頭，背景編譯和快速的Code Insight，那麼使用BCB來進行C++專案的開發將會非常的愉快，因為如此一來BCB即可讓C++的開發人員享受類似Delphi，C#和Java等快速開發的環境了。

7 則迴響