DLL编程问题
我用常规MFC-DLL，也能正常导出基于MFC的派生类，并且接口也可以是MFC的，这样做的缺点就是这个DLL就不能被那些非MFC程序所调用了，不过我用MFC程序调用还没遇到问题，请问这样做还有什么问题，其次，即然这样也能导出MFC派生类和MFC接口，而且选项可以选成静态或动态链接到MFC，那扩展MFC的DLL的作用岂不是完全可以被这处方式给替代了吗？请高手指教
作者: righthook8 发布时间: 2011-06-15
静态链接，会导致生成的执行文件很大。。。。。。。。。。。。。。。
作者: zhouganghao 发布时间: 2011-06-15
骗人，我简单试的，还不到30K，这不是主要原因吧
作者: righthook8 发布时间: 2011-06-15
求回答！！如果可以代替，那问题就成了，为什么导出MFC的派生类，一定要动态链接到MFC，其实这也就要求调用这个DLL的EXE也必须是动态链接到MFC的，为什么，静态的我在我的机器上试的也是可以的呀，
作者: righthook8 发布时间: 2011-06-15
选用动态连接, 那么这些库会存着系统的库更新而得到更新
但选择静态连接, 那么这些库就永远不会更新了, 除非你下载最新库以后重新编译.
导致MFC的派生类出来, 对于MFC来说是可以使用的, 因为虚表是操持一至的. 但不应该这样做的. 这样做的问题多着...
应该变换成接口的形式发布出来. 而且类型只能够使用系统的基本类型, 这样才能够保证非MFC程序调用没有问题, 还要注意采用__stdcall定义函数, 否则cdecl这种协议, 在非MFC环境下, 不一定支持的
但选择静态连接, 那么这些库就永远不会更新了, 除非你下载最新库以后重新编译.
导致MFC的派生类出来, 对于MFC来说是可以使用的, 因为虚表是操持一至的. 但不应该这样做的. 这样做的问题多着...
应该变换成接口的形式发布出来. 而且类型只能够使用系统的基本类型, 这样才能够保证非MFC程序调用没有问题, 还要注意采用__stdcall定义函数, 否则cdecl这种协议, 在非MFC环境下, 不一定支持的
作者: dfasri 发布时间: 2011-06-15