问个和sharemem有关的问题,请高手相助。 我只知道,如果往dll里传入string参数,得uses sharemem,但是如果传入的参数是个record,包含了string类型的字段,又或者是类,比如TForm,这些都包含了string类型变量,需要uses sharemem吗?更或者,如果我传入的是pointer,指向的是一个string变量,在dll中转换为string类型变量使用,这样需要sharemem吗?为什么?谢谢。 解决方案 » 免费领取超大流量手机卡,每月29元包185G流量+100分钟通话, 中国电信官方发货 如果是string类型字段,要再增加一个字段标识该string字段实际存储的长度,以便根据此长度读取数据当然建议你别用string,干吗给自己找麻烦那 其实我是问,如果string变量不是直接参数,而是在class或record里,是否需要sharemem? 你要明白为什么要sharemem的本质:这是由于DLL间的字符串内存管理问题造成的,而不是仅仅是因为参数直接声明成string的原因,这只是一个特例。 建议使用FastMM内存管理,替换原自带的内存管理,好处见FastMM说明 内存管理器是保证内存的申请和释放的一致性!看一下ShareMem.pas单元即可 写成DLL的目的是使模块复用!如果在DLL中写一些由RTL来控制的类型(如string,动态数组等),其它语言怎么调? 所以在接口部分最好用一些基础数据类型,DLL内部使用string没有问题 你好,請改用pchar代替string,這樣可以減少不必要的問題發生,謝謝。只要調用到string就一定要將sharemm放在第一個。 楼主是用FastMM吧,彻底摆脱ShareMem的烦恼网上有下载,搜索下FastMM 在外国 Delphi 社区非常有名,其主要目的就是重新实现一个高效、安全、稳定的内存管理器(Borland 的内存管理器问题多多,如 Dll 和 Exe 间无法共享,多线程下效率底--一些情况下甚至于低一个数量级!),在代号为 Dexter 的 Delphi 2006 没 release 之前已经听李维大肆鼓吹说 Dexter 如何出色,还在 CSDN 上说他 Demo 证明 FastMM 在 Delphi 和 BCB 下能提高 NNN% 的效率!例子中在 Dll 和 Exe 之间传递 string 而不需要引用任何的 ShareMem 或 FastMM! 好的,我试试fastmm。因为看到这句话:This applies to all strings passed to and from your DLL--even those that are nested in records and classes,也就是说,基本上vcl控件做为参数,是离不开sharemem了? 谢谢各位。这几天网上查了下,好像用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。 呃~哪些不赞同呢?另外,你之前说的>>你要明白为什么要sharemem的本质: >>这是由于DLL间的字符串内存管理问题造成的,而不是仅仅是因为参数直接声明成string的原因,这只是一个特例。这个本质是什么呢?与dll之间内存管理有哪些问题?sorry,我基础差,想了解下本质的原因。 哦,我最主要觉得,如果EXE和各个DLL都是DELPHI自己用而已的话,我还是宁愿用string而不用pchar,管理起来很复杂的,尤其在涉及复杂参数(对象、记录等)传递的时候。为了一点效率而增加架构的复杂性,个人觉得得不偿失。也许是我还没有想到好的方法吧,学习。 从来没用过sharemem, 从来不往dll传string 呃,那也从来不在exe、dll之间传递vcl组件吗?一般vcl都要用到string的。 我想在工具栏某个按钮的右上区域动态显示数字,类似360软件管家、软件升级图标上提示的数字 提个有点异想天开的问题,看现实不? 关于delphi下的Data Module 简单问题,快来那分? 在窗体上显示多幅图像,如果能完全解决问题,赠送当挡书店或其他网上书店任选书四本。 一个小问题折腾了我一天----帮帮我 能不能获取ftp站点下的某一目录下的文件列表? 谁有DELPHI的TAPI.PAS头文件!!!!!(急…急…………) 怎样确定光盘的存在及盘符???????? 如何隐藏主窗体?part2 ReleaseCapture 问题一问 如何使DBGRID可以显示出树形结构
当然建议你别用string,干吗给自己找麻烦那
如果在DLL中写一些由RTL来控制的类型(如string,动态数组等),其它语言怎么调?
只要調用到string就一定要將sharemm放在第一個。
网上有下载,搜索下FastMM 在外国 Delphi 社区非常有名,其主要目的就是重新实现一个高效、安全、稳定的内存管理器(Borland 的内存管理器问题多多,如 Dll 和 Exe 间无法共享,多线程下效率底--一些情况下甚至于低一个数量级!),在代号为 Dexter 的 Delphi 2006 没 release 之前已经听李维大肆鼓吹说 Dexter 如何出色,还在 CSDN 上说他 Demo 证明 FastMM 在 Delphi 和 BCB 下能提高 NNN% 的效率!例子中在 Dll 和 Exe 之间传递 string 而不需要引用任何的 ShareMem 或 FastMM!
>> 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。
呃~哪些不赞同呢?另外,你之前说的>>你要明白为什么要sharemem的本质: >>这是由于DLL间的字符串内存管理问题造成的,而不是仅仅是因为参数直接声明成string的原因,这只是一个特例。这个本质是什么呢?与dll之间内存管理有哪些问题?sorry,我基础差,想了解下本质的原因。