C++析构函数与构造函数调用不匹配问题及资源管理疑问

问题背景 #

在研究C++资源管理机制，重点分析构造函数与析构函数的调用逻辑时，发现测试代码中每个值对应的myObj构造函数仅调用1次，但析构函数却调用了4次，预期的临时对象构造/析构次数应该匹配，想知道原因；另外如果myObj的构造函数负责打开文件或数据库连接、析构函数负责关闭，这种场景会不会引发问题？

测试代码 #

ylist.h #

#pragma once
template <class T>
struct ListNode
{
    T elem;
    struct ListNode* next;
    ListNode(T elem):elem(elem),next(nullptr) {}
};

template <class T>
class List
{
    ListNode<T> *head;

public:
    List() : head(nullptr)
    {

    }
    ~List()
    {
        ListNode<T>* cursor = head;
        while (cursor != nullptr)
        {
            ListNode<T>* next = cursor->next;
            delete cursor;
            cursor = next;
        }
    }
    void append(T item)
    {
        ListNode<T>* n = new ListNode<T>(item);
        if (head == nullptr)
        {
            head = n;
        }
        else
        {
            ListNode<T>* cursor = head;
            while (cursor->next != nullptr)
                cursor = cursor->next;
            cursor->next = n;
        }
    }
};

main.cpp #

#include <iostream>
#include "ylist.h"

using namespace std;

class myObj
{
    int val;
public:
    myObj(int val):val(val)
    {
        cout << "myObj@" << this << "(" << val << ")" << endl;
    }

    ~myObj()
    {
        cout << "~myObj@" << this << "(" << val << ")" << endl;
    }

};

int main()
{
    List<myObj> myList;

    for (int i = 0; i < 3; i++)
    {
        myList.append(myObj(i));
    } 
}

程序输出 #

myObj@00000039614FFAC0(0)
~myObj@00000039614FFAD0(0)
~myObj@00000039614FFAC8(0)
~myObj@00000039614FFAC0(0)
myObj@00000039614FFAC0(1)
~myObj@00000039614FFAD0(1)
~myObj@00000039614FFAC8(1)
~myObj@00000039614FFAC0(1)
myObj@00000039614FFAC0(2)
~myObj@00000039614FFAD0(2)
~myObj@00000039614FFAC8(2)
~myObj@00000039614FFAC0(2)
~myObj@0000019878DF6100(0)
~myObj@0000019878DF5F20(1)
~myObj@0000019878DF6200(2)

原因分析 #

构造/析构次数看似不匹配的核心原因是编译器生成的默认拷贝构造函数没有输出日志，导致你看不到隐式的构造行为，但这些对象确实被创建了，因此会触发对应的析构调用。

以单次循环myList.append(myObj(i))为例，实际发生了4次myObj构造：

1. 显式构造临时对象：myObj(i)，这是你能看到日志的那次构造；
2. 值传递拷贝构造append形参：append(T item)是值传递，会将临时对象拷贝到形参item中，编译器生成的默认拷贝构造无日志；
3. 值传递拷贝构造ListNode形参：ListNode(T elem)同样是值传递，将item拷贝到形参elem中，无日志；
4. 拷贝构造ListNode成员elem：ListNode的成员初始化列表elem(elem)会用形参elem拷贝构造成员变量elem，无日志。

对应的4次析构：

1. ListNode构造函数的形参elem生命周期结束，触发析构（输出中每个循环的第一次析构日志）；
2. append函数的形参item生命周期结束，触发析构（输出中每个循环的第二次析构日志）；
3. 临时对象myObj(i)生命周期结束，触发析构（输出中每个循环的第三次析构日志）；
4. 程序结束时List销毁，遍历删除ListNode，每个ListNode的成员elem触发析构（输出末尾的三次析构日志）。

因为后3次构造没有日志输出，所以你误以为构造只调用了1次，但实际4次构造对应4次析构，次数本质是匹配的。

资源管理场景的影响 #

如果myObj的构造函数负责打开文件/数据库连接、析构函数负责关闭，这种场景会引发严重问题：

• 默认拷贝构造是浅拷贝，多个拷贝出来的对象会共享同一个资源句柄（比如文件指针、连接ID）；
• 临时对象、函数形参这些短生命周期的对象析构时，会提前关闭资源，导致List中存储的对象持有的资源已经失效；
• 当List销毁时，对象再次关闭已经被关闭的资源，触发双重释放/关闭，属于未定义行为，可能导致程序崩溃、资源泄漏或数据损坏。

解决方案 #

1. 显式控制拷贝行为：要么实现深拷贝（让每个对象拥有独立的资源），要么用delete关键字禁用拷贝构造和拷贝赋值运算符，避免意外拷贝；
2. 改用移动语义：将append的参数改为右值引用T&& item，ListNode的构造函数改为ListNode(T&& elem):elem(std::move(elem))，用移动代替拷贝，减少不必要的资源创建/销毁；
3. 遵循RAII原则：用智能指针或自定义RAII类管理资源，确保资源的创建与销毁严格绑定到对象的生命周期，避免手动管理资源的错误。

内容的提问来源于stack exchange，提问作者yasar