11 个解决方案
#1
什么情况?应该与STL没有关系。没有讲清楚场景。
#2
珍惜生命,远离扩展dll,只使用纯C接口的标准dll
#3
dll中stl版本必须保证和调用方的stl版本完全一致
#4
我遇到的问题是跨lib调用STL内存混乱……
STL这玩意果然不能太过相信……
STL这玩意果然不能太过相信……
#5
遇到过,所以不敢用stl模板对象进行参数传递。但有时又发现没问题。
用std::map传参没问题,std::vector传参就乱了。
用std::map传参没问题,std::vector传参就乱了。
#6
我不认为在dll的接口中涉及stl元素是个好主意,除非是完全一个ide(同样的sdk)编译出来的配套的exe和dll,但是dll总是有可能给比人使用,换了编译器的版本或sdk的版本可能会造成问题。
dll中完全可以使用stl,但是不要出现在接口层面。
纯C的dll接口是很好的,C++的dll接口也不赖(但是不要涉及stl)
dll中完全可以使用stl,但是不要出现在接口层面。
纯C的dll接口是很好的,C++的dll接口也不赖(但是不要涉及stl)
#7
本来就不应该这么使
接口纯C,不要跨模块分配释放内存
接口纯C,不要跨模块分配释放内存
#8
跨dll内存分配释放本来就是禁止的事情,不用STL照样有这种问题.
#9
STL跨dll最好使用代理class
或者使用指针作为成员变量。
void *m_ptr;
或者使用指针作为成员变量。
void *m_ptr;
#10
总结了下大家的回复,基本上与我的总结的差不多:
首先不要让STL的容器出现在接口中
其次不要跨dll分配和释放内存
最终结论:还是要改善设计
首先不要让STL的容器出现在接口中
其次不要跨dll分配和释放内存
最终结论:还是要改善设计
#11
lib应该不至于吧。。。
#1
什么情况?应该与STL没有关系。没有讲清楚场景。
#2
珍惜生命,远离扩展dll,只使用纯C接口的标准dll
#3
dll中stl版本必须保证和调用方的stl版本完全一致
#4
我遇到的问题是跨lib调用STL内存混乱……
STL这玩意果然不能太过相信……
STL这玩意果然不能太过相信……
#5
遇到过,所以不敢用stl模板对象进行参数传递。但有时又发现没问题。
用std::map传参没问题,std::vector传参就乱了。
用std::map传参没问题,std::vector传参就乱了。
#6
我不认为在dll的接口中涉及stl元素是个好主意,除非是完全一个ide(同样的sdk)编译出来的配套的exe和dll,但是dll总是有可能给比人使用,换了编译器的版本或sdk的版本可能会造成问题。
dll中完全可以使用stl,但是不要出现在接口层面。
纯C的dll接口是很好的,C++的dll接口也不赖(但是不要涉及stl)
dll中完全可以使用stl,但是不要出现在接口层面。
纯C的dll接口是很好的,C++的dll接口也不赖(但是不要涉及stl)
#7
本来就不应该这么使
接口纯C,不要跨模块分配释放内存
接口纯C,不要跨模块分配释放内存
#8
跨dll内存分配释放本来就是禁止的事情,不用STL照样有这种问题.
#9
STL跨dll最好使用代理class
或者使用指针作为成员变量。
void *m_ptr;
或者使用指针作为成员变量。
void *m_ptr;
#10
总结了下大家的回复,基本上与我的总结的差不多:
首先不要让STL的容器出现在接口中
其次不要跨dll分配和释放内存
最终结论:还是要改善设计
首先不要让STL的容器出现在接口中
其次不要跨dll分配和释放内存
最终结论:还是要改善设计
#11
lib应该不至于吧。。。