添加std::cout语句为何消除SharedPtr的内存损坏错误？

Yep, I’ve run into this exact head-scratcher before—those bugs that disappear when you add debug output are the absolute worst, right? Let’s break down what’s going on here.

首先，问题的根源 #

Your core issue is undefined behavior (UB) caused by not nulling out the source object’s raw_ptr_ and ref_count_ in the move constructor. When you move from a SharedPtr, the source object should be left in a "valid but unspecified" state—ideally, one where its destructor doesn’t try to free memory or modify a reference count that’s now owned by the new SharedPtr. Without nulling those pointers:

• The source object’s destructor will attempt to decrement the same ref_count_ as the new object, leading to an incorrect reference count (and eventually a double-free when it hits zero).
• It might also dereference raw_ptr_ during destruction, which is now a dangling pointer pointing to memory the new SharedPtr controls.

UB is unpredictable by definition—sometimes it crashes immediately, sometimes it corrupts data silently, and sometimes... it just seems to work.

为什么加std::cout会让它"正常运行" #

那个看似无关的cout根本没修复问题，只是刚好改变了程序的执行状态，让内存 corruption 没在这次运行中爆发而已。最可能的原因有这几个：

1. 编译器优化被干扰
   现代编译器会对代码做激进优化，尤其是对移动后看似"无用"的对象。没有cout时，编译器可能会重排操作顺序、复用存储源对象指针的寄存器，甚至提前销毁源对象。而cout引入了可见的副作用，编译器会保守地放弃这些优化，改变了操作的时序或内存布局，刚好避开了崩溃点。
2. IO操作改变了执行时序
   std::cout是慢且阻塞的IO操作，它会迫使程序等待操作系统处理输出，这直接改变了内存操作的执行顺序。原本可能存在的竞态条件（或对同一引用计数/内存的重叠访问），现在变成了无害的先后执行顺序。
3. 栈布局被改变
   cout语句会在栈上创建临时对象（比如流操作器、内部缓冲结构），这改变了栈的内存布局。原本源对象析构时的野指针访问，现在指向的是一块无害的内存区域，而不是关键数据结构或已释放的堆内存。

关键结论 #

这只是巧合而已——你的bug依然存在。唯一真正的修复方式，是在移动构造函数里正确置空源对象的指针：

SharedPtr(SharedPtr&& other) noexcept
    : raw_ptr_(other.raw_ptr_), ref_count_(other.ref_count_) {
    // 重置源对象，使其析构时不会操作已移交的资源
    other.raw_ptr_ = nullptr;
    other.ref_count_ = nullptr;
}

内容的提问来源于stack exchange，提问作者Apollys supports Monica