Delphi 製作 DLL 復用的最佳實踐建議

前言

在企業開發中，經常需要製作動態連結庫（DLL）以實現程式碼復用。因為 Delphi 開發效率高、語法簡潔，許多團隊選擇用它來建構 DLL。然而，若忽略介面設計規範，極易導致跨語言呼叫失敗或記憶體管理錯誤。本文針對 Delphi 製作 DLL 的常見陷阱，提出一套實戰驗證的設計建議。

核心原則：堅持使用標準 Win32 API 介面類型

DLL 的參數類型與返回類型絕不可使用 Delphi 專有類型，例如：

• string（AnsiString）
• 動態陣列
• 包含上述類型的記錄或物件

若呼叫端非 Delphi 程式（如 C++、C#、VB），使用這些類型必定報錯；即便雙方均為 Delphi，若專案檔首個引用單元不是 ShareMem，也會觸發記憶體存取違規。

替代方案

• 字串改用 PChar（PAnsiChar）傳遞。
• 動態陣列改用指標（@Array[0]）加長度參數傳遞。
• 複雜結構體僅包含基本類型（Integer、Double、Pointer 等）。

特殊情況：雙方皆為 Delphi 且不想轉型

若呼叫端與被呼叫端都是 Delphi，且為求開發便利不願做類型轉換，強烈建議改用運行時套件。BPL 內建正確的動態記憶體管理機制，且副檔名 .bpl 明確標示僅限 Delphi/C++Builder 使用，避免誤用。

避免匯出多載函式

DLL 匯出介面不應使用 overload。同一功能若有多種參數組合，請採用命名區分，如 CreateByDefaultFile、CreateDefault，參考 VCL 風格（FormatXXX、CreateXXX）。這能消除符號修飾差異帶來的跨語言連結問題。

提供標準化程式設計介面檔案

作為 DLL 提供方，務必隨附對應語言的介面檔：

• Delphi：.pas（含註釋）或 .dcu
• C/C++：.h 與 .lib

介面檔可採用靜態連結（external 'DllName' name 'FuncName'）或動態連結（LoadLibrary/GetProcAddress）。提供官方介面檔不僅專業（HiQoS），更能保證呼叫端正確性。

總結

1. 參數/返回值僅用標準 Win32 類型（PChar、指標、基本數值型）。
2. 需共享動態記憶體時，首選 BPL 運行時套件。
3. 拒絕 overload，採用語意化命名區分多態。
4. 隨附多語言介面檔，支援靜態/動態連結兩種模式。

遵循以上原則，您的 DLL 將具備極佳的跨語言相容性與長期維護性。