我只知道,如果往dll里传入string参数,得uses sharemem,但是如果传入的参数是个record,包含了string类型的字段,又或者是类,比如TForm,这些都包含了string类型变量,需要uses sharemem吗?更或者,如果我传入的是pointer,指向的是一个string变量,在dll中转换为string类型变量使用,这样需要sharemem吗?为什么?谢谢。

解决方案 »

  1.   

    如果是string类型字段,要再增加一个字段标识该string字段实际存储的长度,以便根据此长度读取数据
    当然建议你别用string,干吗给自己找麻烦那
      

  2.   

    其实我是问,如果string变量不是直接参数,而是在class或record里,是否需要sharemem?
      

  3.   

    你要明白为什么要sharemem的本质:这是由于DLL间的字符串内存管理问题造成的,而不是仅仅是因为参数直接声明成string的原因,这只是一个特例。
      

  4.   

    建议使用FastMM内存管理,替换原自带的内存管理,好处见FastMM说明
      

  5.   

    内存管理器是保证内存的申请和释放的一致性!看一下ShareMem.pas单元即可
      

  6.   

    写成DLL的目的是使模块复用!
    如果在DLL中写一些由RTL来控制的类型(如string,动态数组等),其它语言怎么调?
      

  7.   

    所以在接口部分最好用一些基础数据类型,DLL内部使用string没有问题
      

  8.   

    你好,請改用pchar代替string,這樣可以減少不必要的問題發生,謝謝。
    只要調用到string就一定要將sharemm放在第一個。
      

  9.   

    楼主是用FastMM吧,彻底摆脱ShareMem的烦恼
    网上有下载,搜索下FastMM 在外国 Delphi 社区非常有名,其主要目的就是重新实现一个高效、安全、稳定的内存管理器(Borland 的内存管理器问题多多,如 Dll 和 Exe 间无法共享,多线程下效率底--一些情况下甚至于低一个数量级!),在代号为 Dexter 的 Delphi 2006 没 release 之前已经听李维大肆鼓吹说 Dexter 如何出色,还在 CSDN 上说他 Demo 证明 FastMM 在 Delphi 和 BCB 下能提高 NNN% 的效率!例子中在 Dll 和 Exe 之间传递 string 而不需要引用任何的 ShareMem 或 FastMM!
      

  10.   

    好的,我试试fastmm。因为看到这句话:This applies to all strings passed to and from your DLL--even those that are nested in records and classes,也就是说,基本上vcl控件做为参数,是离不开sharemem了?
      

  11.   

    谢谢各位。这几天网上查了下,好像用sharemem的主要目的是,保证string类型可以在exe内创建,而在dll内被安全释放,反之也然,如果这样,那如果代码可以保证string不会交叉释放,也就不会有问题了,是这样吗?我参考了以下说法:>> pascal编写的dll由其它语言编写的宿主程序调用时必须遵守下列原则: 
    >> 1.输出改为stdcall 
    >> 2.输出函数参数或结果不可以带有string类型,连shortstring都不行。 
    >> 如果是Pascal编写的DLL由Pascal编写的宿主程序调用时必须遵守下列原则: 
    >> 1.DLL主申请的资源不可以由宿主程序释放;反之亦然。 
    >> 2.不可以在DLL或宿主程序间传递自管理类型数据,例如字符串和数组。如果一定要传递 
    >> 则一定要在DLL的项目文件和宿主程序的项目文件的接口部分引用sharemem.pas单元,并 
    >> 在程序发布时一并发布borlndmm.dll。 
    >> 3.DLL中引用Forms单元时还有其它的规定。在DLL中Forms单元中的全局变量Application 
    >> 可以调用,但并没有向系统注册。要么执行Application的Initialize方法;要么将宿主 
    >> 程序的Application的Handle传递过来。 
    >> 
    >> 
    >> 需要说明的是:string类型有很多保留的空间用于管理。使用虽然方便但效率不如PChar高。 
    >> Borland也不推荐使用string的运行时类型信息(RTTI)内容。Delphi程序员应该形成一个 
    >> 习惯:在内部使用的时候用什么类型都可以,一旦涉及DLL间或者应用程序间(无论用什么 
    >> 语言编写)都一律改为PChar。   
      

  12.   


    呃~哪些不赞同呢?另外,你之前说的>>你要明白为什么要sharemem的本质: >>这是由于DLL间的字符串内存管理问题造成的,而不是仅仅是因为参数直接声明成string的原因,这只是一个特例。这个本质是什么呢?与dll之间内存管理有哪些问题?sorry,我基础差,想了解下本质的原因。
      

  13.   

    哦,我最主要觉得,如果EXE和各个DLL都是DELPHI自己用而已的话,我还是宁愿用string而不用pchar,管理起来很复杂的,尤其在涉及复杂参数(对象、记录等)传递的时候。为了一点效率而增加架构的复杂性,个人觉得得不偿失。也许是我还没有想到好的方法吧,学习。
      

  14.   

    从来没用过sharemem, 从来不往dll传string
      

  15.   

    呃,那也从来不在exe、dll之间传递vcl组件吗?一般vcl都要用到string的。