Visual C++ 2010 std::set 发现损坏

发布于 2024-10-04 02:19:16 字数 589 浏览 1 评论 0原文

我正在从 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

ゝ杯具 2024-10-11 02:19:16

我唯一能想到的是你有多个线程,而 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文