Visual C++ 2010 std::set 发现损坏
我正在从 Visual Studio 2008 转换 -> 2010 年,我在评估 std::set 指针上的查找时在代码中遇到了一个奇怪的错误。
我知道这个版本带来了一个变化,其中 set::iterator 与 set::const_iterator 具有相同的类型,以带来与标准的一些兼容性。但我不明白为什么这部分以前有效的代码现在会导致崩溃?
void checkStop(Stop* stop)
{
set<Stop*> m_mustFindStops;
if (m_mustFindStops.find(stop) != m_mustFindStops.end()) // this line crashes for some reason??
{
// do some stuff
}
}
PS m_mustFindStops 崩溃时为空。
编辑:感谢您的快速回复...我也无法用一个简单的案例来重现它 - 这可能不是设置本身的问题。我认为堆损坏可能是罪魁祸首 - 我只是希望我知道为什么更改编译器会突然导致相同代码和相同输入数据的损坏。
I'm changing over from Visual Studio 2008 -> 2010 and I've come across a weird bug in my code when evaluating a find on a std::set of pointers.
I know that this version brings about a change where set::iterator has the same type as set::const_iterator to bring about some compatability with the standard. But I can't figure out why this section of code which previously worked now causes a crash?
void checkStop(Stop* stop)
{
set<Stop*> m_mustFindStops;
if (m_mustFindStops.find(stop) != m_mustFindStops.end()) // this line crashes for some reason??
{
// do some stuff
}
}
PS m_mustFindStops is empty when it crashes.
EDIT: Thanks for the quick replies... I can't get it to reproduce with a simple case either - it's probably not a problem with the set its self. I think that heap corruption may be a culprit - I just wish I knew why changing compilers would suddenly cause corruption for the same code and same input data.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我唯一能想到的是你有多个线程,而 m_mustfindStops 实际上是成员或全局变量,而不是该函数的本地变量。如果正确且单独考虑,上面的代码不会导致问题。
如果您有多个线程,则读取访问与写入访问并发将导致随机错误 - 即使容器看起来是空的,但在
find
调用开始时可能还不是空的。另一种可能性是其他一些代码损坏了堆,但在这种情况下,使用堆内存的任何代码都可能发生故障。考虑到这一点,如果总是这种逻辑被打破,我的赌注将是线程问题。
顺便说一句 - Visual C++ v10 中的
std::set
绝对没有任何问题 - 您的代码一定有错误。The only thing I can think of is that you have multiple threads, and
m_mustfindStops
is in fact a member or global variable and not a local to this function. There is no way the code above can cause problems, if correct and taken in isolation.If you have multiple threads, then read access concurrent with write access will cause random errors - even if the container looks empty, it might not have been when the
find
call started.Another possibility is that some other code has corrupted the heap, in which case however any of your code that uses heap memory could malfunction. With that in mind, if it's always this logic that breaks, my bet would be on a threading issue.
btw - there is absolutely nothing wrong with
std::set
in Visual C++ v10 - your code must have a bug.