You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

是否需在QSharedData子类及主类中显式声明析构函数以避免内存泄漏?

Do you need explicit destructors for Employee and EmployeeData to avoid memory leaks?

Great question! Let's break this down step by step based on how QSharedData works and your code structure.

1. EmployeeData absolutely needs an explicit destructor

Your EmployeeData has a raw pointer member EmployeeInfo* info that's dynamically allocated (new EmployeeInfo() in Employee's constructor). The default compiler-generated destructor for EmployeeData will not automatically delete this pointer—it only destroys the pointer itself, not the object it points to. This would leave the EmployeeInfo instance hanging in memory, causing a memory leak.

Your explicit ~EmployeeData() is necessary, but you should move the cleanup of info into it instead of handling it in Employee's destructor (this is better for responsibility separation):

class EmployeeData : public QSharedData { 
public: 
    EmployeeData() : info(new EmployeeInfo()) {} // Initialize directly here for cleaner code
    ~EmployeeData() {
        delete info; // Let EmployeeData manage its own resource cleanup
    } 
    EmployeeInfo *info; 
};

This way, whenever an EmployeeData instance is destroyed, it takes care of freeing its own EmployeeInfo automatically.

2. Employee's explicit destructor depends on how you manage EmployeeData

Right now, your Employee manually holds a raw EmployeeData* data and deletes it in the destructor. This works for a single Employee instance, but it's risky if you ever copy Employee objects (e.g., Employee e2 = e1;). In that case, both e1 and e2 would point to the same EmployeeData, and when they're destroyed, you'd get double deletion of data (and info, if you left that cleanup in Employee's destructor)—leading to undefined behavior like crashes or memory corruption.

The better approach: Use QSharedDataPointer

QSharedData is designed to work with QSharedDataPointer (a smart pointer that handles reference counting for shared data). If you switch to using QSharedDataPointer<EmployeeData> in Employee, you don't need an explicit destructor for Employee at all:

#include <QSharedDataPointer>

class Employee {
public:
    Employee() : data(new EmployeeData()) {}
    // No need for ~Employee()—QSharedDataPointer handles cleanup automatically

private:
    QSharedDataPointer<EmployeeData> data;
};

QSharedDataPointer tracks how many Employee instances share the same EmployeeData. When the last Employee using that data is destroyed, it automatically deletes the EmployeeData instance, which in turn triggers ~EmployeeData() to free info.

If for some reason you must use a raw EmployeeData*, you do need an explicit ~Employee() to delete data—but you also need to implement proper copy constructors and assignment operators to handle shared data safely (otherwise, you'll run into double deletion issues). This is error-prone, so using QSharedDataPointer is strongly advised.

Final Summary

  • EmployeeData: Yes, you need an explicit destructor to delete the info pointer and avoid memory leaks. Always let the class that owns a dynamic resource clean it up.
  • Employee: No, you don't need an explicit destructor if you use QSharedDataPointer (the intended way to work with QSharedData). If you use raw pointers, you do need one—but this approach is not recommended due to the risk of double deletion and manual reference counting errors.

内容的提问来源于stack exchange,提问作者Spatz

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.15 08:16:23