其实我更爱姐汁...
posted on 2010-07-01 15:47 酿妹汁 阅读(3302) 评论(11) 编辑 收藏 引用 所属分类: C++ 、备忘
你的错误是因为dll的std::map跟你这里的std::map不是使用同一份代码,而是两份代码。所以不要拿stl的模板容器去跨dll。所以这种时候,你应该去包装一个不能再.h看到实现的StringValueMap然后暴露出来,或者不要用dll直接使用它的代码。 回复 更多评论
看到了dll导出了一个wrap std::string 的std:map,严重怀疑std:string的copy-on-write 使得两个模块引用了同一个stringbuffer,然后dll模块的unload或者exe模块的clear都有可能导致对方模块在进一步的操作中access violation. 回复 更多评论
dll导出函数 应该是纯C的 回复 更多评论
本人喜欢钻牛角尖,博主能否把测试代码发给我(alcoholyi@qq.com)。 另外,你下的结论有误,没有什么exe,dll模块堆空间一说,堆只跟进程有关系,可以简单的理解为同一个进程的dll和exe共享一个堆空间。 回复 更多评论
我觉得实际上是你的DLL接口设计有问题,从来就没有见到过接口有使用map的,一般接口的定义只使用C语言的接口,遵守资源谁分配谁释放的原则,如果使用C++的接口的话,比如map,资源的分配释放就分不清楚了. 回复 更多评论
@路人甲有道理 回复 更多评论
完全赞同vczh的观点。lz的ReadData肯定是在另一个库里面编译的,而那个库调用的STL lib与现在的项目不同。这跟模块没有任何关系。我最近也一直碰到这种情况。使用别人的第三方程序库,Release能跑,而Debug里面一碰到传递string就出错。郁闷。有谁知道如何能查看第三方库到底link了哪些dll么? 回复 更多评论
确实有一种情况,在window下遇到过,两个dll,在其中一个dll中new一个object,然后在另外一个dll delete,崩溃。环境是winxp vc6.很久之前了。但是你这种玩法是问题复杂化了。 回复 更多评论
@你的错误是因为dll的std::map跟你这里的std::map不是使用同一份代码,而是两份代码严重同意上述观点.template是源代码级的复用.请勿跨二进制使用. 回复 更多评论
回LS几位的话...释放内存的时候,系统提示为已经释放过的内存块或是在不同的堆中分配的内存。也许提示的不正确,但是本着谁分配谁释放的原则的话,就算在模块接口上使用std的容器也应该没什么问题。这方面只要注意在两个模块中使用同样的clib链接方式就可以,分为debug、release、static、dynamic的命名方式,项目中存在多种配置,都是统一的。 回复 更多评论
这个常见的错误,“2010-07-08 14:35 酿”说的对。原因在于dll和exe链接了不同基础lib导致,把它们全部设置成一样的,就没问题了。 回复 更多评论
Powered by: C++博客 Copyright © 酿妹汁