是D2010的更新真的有意義

Question

我想將我自己的項目遷移到delphi 2010。但它似乎是非常困難的。

1. 我對舊項目使用TntControls。如果我刪除這個庫，一些運行時功能必須由我自己重新實現。例如：將UnicodeString轉換爲指定的代碼頁。
2. 「SizeOf」，「Length」，FillChar（）仍然讓我困惑。如果SizeOf（）應該替換爲Length（），編譯器會發出警告。但我還沒有找到適合我的白癡安全教程。
3. 一個令人困惑的警告，當試圖將一個AnsiString強制轉換爲UnicodeString。這次談話不會導致數據丟失，是嗎？
4. 許多代碼（zip，string utils等）必須重新測試。

太多令人頭痛的事情......有人可以分享經驗，將現有項目從一個非常古老的delphi遷移到delphi 2010嗎？

Answer 1

1. 如果你使用TNT和你的代碼頁之間的轉換已經，那麼是的，切換到德爾福2010年將導致你額外的工作，因爲你需要刪除代碼的東西，現在德爾福本質上處理。最終，你的代碼會更簡單，但在此期間它將會很麻煩。

2. sizeof相似，長度和FillChar是非常基本的概念，你，作爲一個專業的軟件開發者，應該爲自己明白。要知道你是處理字符數據還是非字符數據，在處理後者時，不要使用與字符相關的類型。你有TBytes;用它。不要使用字符串作爲字節緩衝區。當你想知道你有多少個字節時，使用SizeOf;當你想知道你有多少「事物」時，使用Length。一般避免FillChar;無論如何，你今天使用它可能不需要它。由於無論如何，事物所填充的「字符」幾乎總是爲零，所以您可以考慮使用ZeroMemory。它具有更少的參數，並且與FillChar一樣快，特別是因爲Delphi支持函數內聯。

3. 編譯器從AnsiString類型轉換成的UnicodeString的時候，因爲它不是一個簡單的字符串賦值而是一個轉換，保證分配更多的內存，並在同一時間的所有內容複製一個字符發出警告。這是一個性能警告，而不是數據丟失警告。在相反的方向轉化是都（即使分配給UTF8字符串，這在技術上，如果它具有有效的Unicode字符不僅填補絕不會從一個的UnicodeString丟失數據時）。避免警告的最好方法是首先不要使用AnsiString。使用普通的舊字符串，除了代碼真的需要知道什麼代碼頁來編碼的東西。

4. 我不認爲「複檢」的說法是非常強的。特別是庫代碼應該有你每次重新編譯時都運行過的單元測試。重新測試是你一天做幾次的事情;除非出現問題，否則不需要付出特別的努力。

Answer 2

1. 轉換Unicode字符串到指定的代碼頁，只有德爾福：比以前更簡單。感謝String類能夠創建一個所需的代碼頁的字符串，並從一個代碼頁乾淨地轉換到另一個。
2. FillChar是字節，而不是字符，名稱現在是不幸的。這並不令人困惑。
3. 這個警告讓你思考，它做了什麼。任務完成。
4. 哦，是的。但重新測試和重新閱讀對我來說是最大的好處。

我已經遷移我的所有項目，德爾福2009/2010，發現的好處包括：

A.我的代碼進行徹底的重新閱讀帶來了，我需要把它清理乾淨（因爲它是一個很多方面臃腫的大量事故和增量代碼污泥，就像大多數RAD/delphi項目一樣），其中很少是純粹的unicode或端口相關的，但所有這些都使得產品更好地適應變化。 B.更清潔的世界，第三方組件更少。刪除TNT，以及一兩個第三方組件將使您的項目更小，更正交，更易於支持。

C.沒有理由將其移植到其中。我的項目中沒有一個港口實際上被永久移動到德爾福2009/2010。他們都在兩個世界建立得很好。我在任何需要它的地方廣泛使用UnicodeString類型，並且在Delphi 2007或更早版本上進行編譯時，我會對WideString進行typedef。

D. delphi2010 IDE在Windows Vista和Windows 7上運行良好，並且該語言非常適合使用。德爾福2009年和2010年不會崩潰，德爾福2007年和德爾福7經常爲我做。

如果你不需要支持Vista和Win7，並且你100％快樂和無故障運行TNT組件，並且你的應用不會讓你賺錢，那就把它留在原地。如果它讓你賺錢，投入你的時間，你很快就會看到獎勵。 Delphi 2010和2009是有史以來最好的delphi版本，唯一讓人頭痛的問題是，自從它們移除WinHelp格式幫助文件以來，文檔一直低於Delphi 7的質量。