使用动态数组结构的一个好处
作者：朱金灿
来源：http://www.cnblogs.com/clever101
请注意，这里我所说的动态数组不是指你自己new出来的数组，而是指STL中的std::vector和MFC中的CArray之类的容器。开始以为使用std::vector不过是免除动态内存之苦。免除自己手动开辟和释放内存是一方面，实际上在使用的过程中你会逐渐发现使用std::vector的好处。今天我就发现了一个好处。
今天我修改别人写的一个图像匹配算法，所谓图像匹配就是找出两幅图像中相同的地方，在我这个算法中就是找出匹配结果点。别人的代码大致是这样的：
代码\brief 匹配点信息结构体
*/
struct PointInfo
{
long x;
long y;
long Geo_x;
long Geo_y;
PointInfo()
{
x= 0;
y=0;
Geo_x = 0;
Geo_y = 0;
}
};
/*!
\brief 匹配两幅图像，返回匹配结果点数组
\param pLeftImg 左图像文件句柄
\param pRightImg 右图像文将句柄
\param lVaildNum 返回的匹配结果点个数
\return 匹配结果点数组
*/
PointInfo* ImageMatch(FILE* pLeftImg,FILE* pRightImg,long &lVaildNum)
{
long Imgwidth = 0;
long ImgHeight= 0;
// 获取左图像宽高，具体代码不写
// 开辟一个整幅图像大小的数组
PointInfo* pResultPt = new PointInfo[Imgwidth*ImgHeight];
// 开始图像匹配，具体代码不写
return pResultPt;
}
说实话我不喜欢这种函数的设计，为什么呢？因为我觉得为了很好地避免内存泄露的话，最好遵循这样一个原则：函数外部申请的内存函数外部释放，函数内部申请的内存在函数内存释放，如果像上面的函数设计，用户往往会忘记释放pResultPt 的内存，而且这种释放也令人感觉不自然。开始我想这样改为这样设计：
代码\brief 匹配两幅图像，返回匹配结果点数组
\param pLeftImg 左图像文件句柄
\param pRightImg 右图像文件句柄
\param pResultPt 输入的匹配点数组
\param InitPtNum 输入的匹配点数组的个数
\param lVaildNum 返回的匹配结果点个数
\return 无
*/
void ImageMatch(FILE* pLeftImg,FILE* pRightImg,PointInfo* pResultPt,long InitPtNum,long &lVaildNum)
{
// 具体实现代码省去
}
调用这个函数的部分代码：
代码// 打开左右图像
FILE* pLeftImg;
FILE* pRightImg;
long Imgwidth = 0;
long ImgHeight= 0;
// 获取左图像宽高，具体代码不写
long InitPtNum = Imgwidth*ImgHeight;
PointInfo* pResultPt = new PointInfo[InitPtNum];
long lVaildNum = 0;
ImageMatch(pLeftImg,pRightImg,pResultPt,InitPtNum,lVaildNum);
上面的代码符合了函数外部申请的内存函数外部释放，函数内部申请的内存在函数内存释放的原则，但是依然给人别扭的感觉，首先是要找匹配点，先得开一个整幅图的大数组（满足找匹配点的需要，担心不够用），然而匹配点往往只占图像的一小部分；其次是输入的函数的参数增多了，除了输入匹配点数组指针，还得输入数组的难度，输入参数增多往往增加了用户的使用难度，比如用户可能会搞不清楚long InitPtNum这个参数所代表的意义。
最后我想比较理想的设计是什么呢？用户只需要输入两幅图像的文件句柄和动态数组，调用后返回这个数组就行。于是我想到了下面这个设计：
代码\brief 匹配两幅图像
\param pLeftImg 左图像文件句柄
\param pRightImg 右图像文件句柄
\param VecPt 输入和匹配点数组
\return 无
*/
void ImageMatch(FILE* pLeftImg,FILE* pRightImg,std::vector<PointInfo> &VecPt)
{
}
这样设计，首先免去开辟和释放内存之累，其次你再也不用开辟一大块内存去应对一个不确定的情况，三是别人使用起来非常自然。由此看来，适当使用现成的动态数组结构可以使我们的设计更为合理。
