604
社区成员
发帖
与我相关
我的任务
分享CB下的DLL工程，接口中使用VCL类会不会有什么隐患？
比如DLL的导出函数中，有TFrom *，TApplication *之类的参数，会不会有什么隐患？
不考虑其他语言兼容性，我目前这样用还没发现什么问题，但是之前通过它们来跨模块操作STL容器遇到了一些问题，虽然已经想办法绕开，但是开始担心VCL库是否也会有这方面问题，比如静态变量之类的
如果不安全，使用BPL是不是个好主意？我有动态加载和隐藏库中内容的需要，但是exe对库来说是开放的
不考虑其他语言兼容性，我目前这样用还没发现什么问题，但是之前通过它们来跨模块操作STL容器遇到了一些问题，虽然已经想办法绕开，但是开始担心VCL库是否也会有这方面问题，比如静态变量之类的
如果不安全，使用BPL是不是个好主意？我有动态加载和隐藏库中内容的需要，但是exe对库来说是开放的
...全文
请发表友善的回复…
发表回复
hind24 2011-01-12
- 打赏
- 举报
那么有很多用DLL封装窗体的应用，是不是同样面临这些隐患呢
ccrun.com 2011-01-12
- 打赏
- 举报
我的建议是在DLL内部可以使用VCL，但是如果要在EXE中使用DLL内部创建的对象指针，这个就一定要注意了。我曾经有一个工程就遇到了这样的问题，在一个单元中写好了一个类，将这个单元直接添加到工程中编译，一切正常，将这个单元封装到DLL中，再调用的时候，就出现Font不能Assign的经典异常，后来不得不改了改才能正常调用。
hind24 2011-01-12
- 打赏
- 举报
[Quote=引用 2 楼 ccrun 的回复:]
涉及到内存共享方面，有很严重的问题，打个比方，在DLL内部new了一个VCL对象，然后在App内部使用这个对象指针，可能会涉及偏移不一样的问题导致成员访问失败。目前的解决方法好像只有一个：带包编译，也就是Build with runtime package
[/Quote]dll和exe在同一IDE中编译，也就是分别把相同的包编译进自己，是不是就没有这个问题了？
毕竟暂时用DLL只是为了把代码分割开，同时隐藏一部分代码，其实都是在一个开发环境中编译，只不过可能由不同的人来完成不同部分而已，两者可以保证使用的VCL库一致
涉及到内存共享方面，有很严重的问题，打个比方，在DLL内部new了一个VCL对象，然后在App内部使用这个对象指针，可能会涉及偏移不一样的问题导致成员访问失败。目前的解决方法好像只有一个：带包编译，也就是Build with runtime package
[/Quote]dll和exe在同一IDE中编译，也就是分别把相同的包编译进自己，是不是就没有这个问题了？
毕竟暂时用DLL只是为了把代码分割开，同时隐藏一部分代码，其实都是在一个开发环境中编译，只不过可能由不同的人来完成不同部分而已，两者可以保证使用的VCL库一致
ccrun.com 2011-01-12
- 打赏
- 举报
涉及到内存共享方面，有很严重的问题，打个比方，在DLL内部new了一个VCL对象，然后在App内部使用这个对象指针，可能会涉及偏移不一样的问题导致成员访问失败。目前的解决方法好像只有一个：带包编译，也就是Build with runtime package
zzbinfo 2011-01-12
- 打赏
- 举报
既然不考虑其他语言兼容性，应该没有什么问题
ccrun.com 2011-01-12
- 打赏
- 举报
DLL中封装窗体这种情况,反而没有出现过我说的问题.所以你不必担心太多.
