加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 大数据 > 正文

Delphi DLL与其他编程语言兼容

发布时间:2020-12-15 09:10:14 所属栏目:大数据 来源:网络整理
导读:我想构建一个DLL,导出返回字符串的函数.这个DLL应该与其他编程语言一起使用!! 我找到了各种令人讨厌的解决方案/黑客,最好的方法是让我的函数返回Pchar,然后调用同一DLL中包含的另一个函数(让我们称之为ReleaseMemory)来释放为PChar保留的内存. 无论如何,最近
我想构建一个DLL,导出返回字符串的函数.这个DLL应该与其他编程语言一起使用!!
我找到了各种令人讨厌的解决方案/黑客,最好的方法是让我的函数返回Pchar,然后调用同一DLL中包含的另一个函数(让我们称之为ReleaseMemory)来释放为PChar保留的内存.

无论如何,最近我发现了FastShareMem库.它说它可以完全按照我想要的方式完成调用ReleaseMemory.另一方面,FastMM似乎做同样的AS LONG,因为DLL和应用程序都使用FastMM作为内存管理器.这会立即杀死使用FastMM作为我的通用DLL的内存管理器的机会.对?

====================

FastShareMem(http://www.codexterity.com/fastsharemem.htm),Delphi 7,Windows XP 32位,Windows 7 64位

解决方法

您正在混合两种不同的场景:

>使用Delphi DLL的Delphi应用程序
>任何使用Delphi DLL的应用程序

在第一种情况下,除非你混合Delphi版本或做一些奇怪的事情,内存管理器是相同的,编译器也是如此.因此,有共享内存管理器的方法,然后编译器能够正确处理分配/解除分配.这就是FastMM和FastShareMem都可以工作的情况 – 而且只有这一个.

在第二种情况下,应用程序和DLL将使用不同的内存管理器,可能是非常不同的内存管理器,并且通常无法共享一个.在这种情况下,最好的方法是永远不要返回在DLL内部分配的PChar,即使你提供了一个释放函数,因为你不能确定调用语言将在以后与你的PChar一起做什么,如果调用者有机会在编译器/解释器之前调用正确的释放例程. COM在你说的方式上有所作为,但它通过自己的内存管理器强制执行内存分配/释放,因此它是安全的.您不能使用普通的DLL强制执行它,因此它不安全.

最好的方法是让调用语言通过一个足够大的缓冲区,并在那里写你的PChar.当然,您需要有一些方法告诉调用者缓冲区的大小.这就是Windows本身的工作方式,并且有很好的理由让他们做出这样的选择.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读