CArray添加元素异常引发的思考

最新推荐文章于 2026-06-14 11:42:36 发布

原创最新推荐文章于 2026-06-14 11:42:36 发布 · 2.1k 阅读

4 ·

本内容遵循CC 4.0 BY-SA版权协议

MFC 专栏收录该内容

1 篇文章

订阅专栏

本文分析了使用MFCCArray在VS2005 MFC环境下出现的诡异异常问题，特别是多次添加元素导致的随机码问题，并给出了正确的解决方法。

最近在使用MFC CArray的过程出现了一个比较诡异的问题，Add元素的时候居然出现了异常。

具体应用环境：VS2005 MFC XP SP3

在开始时使用了如下所示的类：

Class CPolyLine
{
       Public:
       CArray<Point, Point&> m_points;
}

具体使用情况如下图所示：

CPolyLine pyline;
//此处通过添加多个m_points，然后判断是否有环路，如果有环路则执行下面的操作。
//pyline.m_points.Add();
pyline.m_points.Add(pyline.m_points[0]);

当执行两次pyline.m_points.Add(pyline.m_points[0])；后发现了严重的异常问题，执行后按照想法结果应该如下图所示：(然而实际情况却并非如此，第一次add的时候是正常的，第二次add的时候发现最后一项变为了随机码)

以下为具体的调试步骤：

调试进入Add函数内部，具体代码如下图所示：

template<class TYPE, class ARG_TYPE>
AFX_INLINE INT_PTR CArray<TYPE,ARG_TYPE>::Add(ARG_TYPE newElement)
       {INT_PTR nIndex= m_nSize;
              SetAtGrow(nIndex,newElement);
              return nIndex; }

在此处的时候，发现newElement值为正常的(10，1)即pyline.m_points[0]正常。看来不是在这里出了问题。继续进入SetAtGrow源码，如下所示：

template<class TYPE, class ARG_TYPE>
void CArray<TYPE, ARG_TYPE>::SetAtGrow(INT_PTRnIndex, ARG_TYPEnewElement)
{
       ASSERT_VALID(this);
       ASSERT(nIndex>= 0);
      
       if(nIndex < 0)
              AfxThrowInvalidArgException();
 
       if (nIndex >= m_nSize)
              SetSize(nIndex+1,-1);
       m_pData[nIndex]= newElement;
}

这里也没啥好看的，直接追踪进入SetSize源码，最终找到如下图所示关键位置代码：

#ifdef SIZE_T_MAX
              ASSERT(nNewMax<= SIZE_T_MAX/sizeof(TYPE)); // no overflow
#endif
              TYPE* pNewData= (TYPE*) newBYTE[(size_t)nNewMax * sizeof(TYPE)];//CArray的容量不够了，这个是重新分配地址，明显这里应该不可能导致乱码的问题。
 
              // copy new data from old 将原来CArray里面的内容全部复制到新位置
              ::ATL::Checked::memcpy_s(pNewData,(size_t)nNewMax* sizeof(TYPE),
                     m_pData, (size_t)m_nSize * sizeof(TYPE));
 
              // construct remaining elements
              ASSERT(nNewSize> m_nSize);
              //将新添加元素的位置进行清零处理,这个显然不会有问题。
              memset((void*)(pNewData + m_nSize),0, (size_t)(nNewSize-m_nSize) * sizeof(TYPE));
              //不知道下面哥们到底在干啥，反正没影响我们的值。
              for( int i = 0; i < nNewSize-m_nSize;i++ )
#pragma push_macro("new")
#undef new
                     ::new( (void*)( pNewData + m_nSize+ i ) ) TYPE;
#pragma pop_macro("new")

//在下面这段代码未执行前的pyline.m_points值的内存布局如下图所示：

// get rid of old stuff (note: no destructors called)

delete[] (BYTE*)m_pData;

//执行上面这句代码之后,pyline.m_points值的内部布局如下图所示：

内存空间被释放了，看来是此处导致问题的产生，但是具体是什么原因导致了这种情况的出现呢？

总结：

关于CArray的工作原理简单说下，CArray开始申请一段内存用于存放Add进来的元素，当进来的元素超过CArray的当前的容量的时候，重新申请一块更大的新内存，然后将数据进行复制，然后将现有内存进行清理掉。

关于此问题的产生，要从CArray的声明说起，m_points的声明如下所示：

     CArray<Point, Point&> m_points;

而在CArray的Add实现代码如下所示：

       template<class TYPE, class ARG_TYPE>
AFX_INLINE INT_PTR CArray<TYPE,ARG_TYPE>::Add(ARG_TYPE newElement)
       {INT_PTR nIndex= m_nSize;
              SetAtGrow(nIndex,newElement);
              return nIndex; }

不知道你发现其中具体含义没有，可将上面的代码用Point，Point&用替换具体如下所示：

AFX_INLINE INT_PTR CArray<Point,Point&>::Add(Point&newElement)

从上图的代码中我们发现：

CArray的两个模板参数，第一个参数就是CArray类数组元素的变量类型，后一个是函数调用时的参数类型。

当我们在Add元素进CArray时，使用的添加元素的引用(即指针)。但是在执行过程中我们调用了delete操作，这个时候CArray原有值可能被释放掉了，新元素的引用指向的就是如上图释放后的eeef ee ef等随机码。

推荐做法将要添加的新元素放在一个临时变量中，这样就不会问题了。不过很神奇的是，这样的代码在WinCe平台上居然运行至今都没出现过问题，只能说是好运爆棚啦。