在公司里有一些需要制作DLL的场合，因为熟悉、方便和简易，大多数使用Delphi来制作。现在就这个主题提出一些个人建议。
尽量使用标准DLL接口。指的是传递的参数类型及函数返回类型不能是Delphi特有的，比如string（AnsiString），以及动态数组和含有这些类型成员的复合类型（如记录），也不能是包含有这些类型成员数据成员的对象类型，以避免可能的错误。如果使用了string类型或动态数组类型，且调用方不是Delphi程序，则基本上会报错。如果调用方是Delphi但调用方或被调用方没有在工程文件的第一包含单元不是ShareMem，也可能会出错。
如果调用方是Delphi应用程序，则可能可以使用不包含禁止类型（string, 动态数组）数据成员的对象作为参数或返回值，但也应尽量避免。
如果调用方与被调用方都是Delphi程序，而且要使用string或动态数组作参数，则双方工程文件的第一包含单元必须是ShareMem。（C++Builder程序的情况可能与此相同，不过没有测试过。）
如果调用方不是Delphi程序，则string、动态数组、包含string或动态数组的复合数据类型及类实例，都不能作为参数及返回值。
因此，为了提高DLL的复用范围，避免可能存在的错误，应当使用标准WIN32 API标准参数类型，以前使用string的变量，可以使用PChar(s)转换。动态数组则转换为指针类型（@array[0]），并加上数组的长度。
如果因为调用方与被调用方都是Delphi程序，为了编写方便，不想进行上述转换，则推荐使用运行时包的形式。运行时包可以保证动态分配数据的正确释放。这样因为其扩展名（.bpl），显出该文件仅限于Delphi/C++Builder使用（不象DLL）。
其次，尽量避免使用overload的函数/过程作输出，如果同一操作有多个方式，则可以让函数/过程名有少许差别，类似于Delphi中的FormatXXXX、CreateXXXX等函数及方法，如CreateByDefaultFile, CreateDefault。
最后，作为DLL的提供者，应当提供直接编程的接口文件，如Delphi中的.pas或.dcu（最好是.pas，因为可以有注释）、C及C++中的.h和.lib。而不是让使用者们自己创建。如果非要有overload的函数/过程，这一点显得特别重要。另外，作为Delphi应用，提供的.pas文件可以是提前连接的（使用external指定DLL中的输出函数），也可以是后期连接的（使用LoadLibrary、GetProcAddress），DLL提供者提供编程接口文件，既显得正式（或HiQoS），又有保障。
 【责编:Lili】 |
 |
|
|
|
