شرح المُدمِّرات في C++‏: ‎~ClassName وRAII والتنظيف

ما هو المُدمِّر

في الصفحة السابقة رأيت المُنشِئات - دوال خاصة تعمل عندما يُولد الكائن لتهيئة حالته الأولية. المُدمِّر هو الصورة المُعاكِسة لها: دالة خاصة تعمل عندما يموت الكائن، لتنظّف بعده.

تُصرّح عنه باسم الصنف مسبوقًا بعلامة التلدة (~). لا يأخذ أي مُعاملات، ولا يُرجع شيئًا، ويمكن للصنف أن يملك واحدًا منه بالضبط. نادرًا جدًا ما تستدعيه يدويًا - فلغة C++ تستدعيه نيابةً عنك في اللحظة المناسبة.

#include <iostream>
using namespace std;

class Logger {
public:
    Logger()  { cout << "Logger created\n"; }   // المُنشِئ
    ~Logger() { cout << "Logger destroyed\n"; }  // المُدمِّر
};

int main() {
    Logger log;                  // "Logger created"
    cout << "doing work...\n";
    return 0;
}                                // تُطبع "Logger destroyed" هنا، تلقائيًا

لاحظ أن رسالة المُدمِّر تُطبع بعد أن ينهي main متن دالته لكن قبل أن ينتهي البرنامج. عندما يخرج log من نطاقه عند القوس المعقوف الختامي، تُنفّذ C++ الدالة ~Logger() نيابةً عنك.

متى تعمل المُدمِّرات

يعتمد التوقيت الدقيق على المكان الذي يعيش فيه الكائن:

• الكائنات على المكدس (المحلية) تُتلَف عندما تخرج من نطاقها - عند القوس المعقوف الختامي } للكتلة.
• الكائنات في الكومة (المُنشأة بـ new) تُتلَف عندما تستدعي delete. إن نسيت delete، فلن يعمل المُدمِّر أبدًا وستتسبب في تسرّب.

يُبرز هذا المثال الفرق بوضوح:

#include <iostream>
using namespace std;

class Tagged {
    int id;
public:
    Tagged(int i) : id(i) { cout << "create " << id << "\n"; }
    ~Tagged()             { cout << "destroy " << id << "\n"; }
};

int main() {
    Tagged a(1);              // create 1

    {
        Tagged b(2);          // create 2
    }                         // destroy 2  (يغادر b نطاقه الداخلي)

    Tagged* c = new Tagged(3); // create 3
    delete c;                 // destroy 3  (عليك أنت أن تُطلق هذا)

    return 0;
}                             // destroy 1  (يغادر a الدالة main)

تُتلَف الكائنات بترتيب عكسي لترتيب إنشائها. أُنشئ a أولًا، لذا يموت أخيرًا. هذا الترتيب من نوع LIFO (الداخل أخيرًا يخرج أولًا) مهمّ عندما تعتمد الكائنات بعضها على بعض.

لماذا تهمّ المُدمِّرات: RAII

القوة الحقيقية للمُدمِّرات هي أنها تجعل التنظيف تلقائيًا وآمنًا أمام الاستثناءات. فبدلًا من تذكّر تحرير المورد في كل مسار من مسارات الكود، تضع التحرير داخل مُدمِّر وتترك للغة ضمان تنفيذه. يُسمى هذا النمط RAII - أي Resource Acquisition Is Initialization (الحصول على المورد هو تهيئته) - وهو العمود الفقري للغة C++ الحديثة.

هنا يملك صنفٌ مخزنًا مؤقتًا في الكومة: يحجزه في المُنشِئ ويحرّره في المُدمِّر، فلا يلمس المُستدعون new/delete بأنفسهم أبدًا.

#include <iostream>
using namespace std;

class IntArray {
    int* data;
    int size;
public:
    IntArray(int n) : data(new int[n]), size(n) {
        for (int i = 0; i < size; ++i) data[i] = i * i;
        cout << "allocated " << size << " ints\n";
    }
    ~IntArray() {
        delete[] data;                 // يطابق new[] أعلاه
        cout << "freed the buffer\n";
    }
    int at(int i) const { return data[i]; }
};

int main() {
    IntArray squares(5);
    cout << "squares[3] = " << squares.at(3) << "\n";  // 9
    return 0;
}   // ‏~IntArray() يعمل هنا: يُحرَّر المخزن المؤقت حتى لو نسينا ذلك

الفكرة الجوهرية: حتى لو أُلقي استثناء بعد إنشاء squares، فسيُفكّ المكدس وسيظل ~IntArray() يعمل رغم ذلك. هذا الضمان هو ما يجعل RAII موثوقًا إلى هذا الحد - وهو السبب في أنك نادرًا ما تكتب delete مجرّدًا في كودِ C++ الجيد.

قاعدة الثلاثة (والخمسة)

الصنف ذو المُدمِّر المخصّص يملك في الغالب موردًا خامًا، وهذا يخلق خطرًا خفيًا. فمُنشِئ النسخ ومعامل إسناد النسخ اللذان يولّدهما المُترجِم ينفّذان نسخًا سطحيًا - أي ينسخان المؤشر، لا المخزن الذي يشير إليه. والآن يحمل كائنان المؤشر نفسه، وسيستدعي كلا المُدمِّرين delete عليه، مُسبّبَين انهيارًا بسبب التحرير المزدوج.

IntArray a(5);
IntArray b = a;   // نسخ سطحي: a.data و b.data هما المؤشر نفسه
// عند نهاية النطاق: يحرّر مُدمِّر b المخزن المؤقت،
// ثم يحرّره مُدمِّر a مرة أخرى -> سلوك غير مُعرَّف (تحرير مزدوج)

يقودنا هذا إلى قاعدة الثلاثة: إن كتبت أيًّا من الثلاثة - المُدمِّر، أو مُنشِئ النسخ، أو معامل إسناد النسخ - فأنت بالتأكيد تقريبًا بحاجة إلى الثلاثة جميعًا. وفي C++11 وما بعدها تمتدّ إلى قاعدة الخمسة، بإضافة مُنشِئ النقل وإسناد النقل.

لكن هناك قاعدة أفضل من ذلك - قاعدة الصفر: صمّم الأصناف بحيث لا تدير موارد خامًا على الإطلاق. احمل بدلًا من ذلك std::vector أو std::string أو مؤشرًا ذكيًا، وسيؤدي المُدمِّر الذي يولّده المُترجِم العملَ الصحيح مجانًا.

#include <iostream>
#include <vector>
using namespace std;

class IntArray {
    vector<int> data;              // يدير ذاكرته بنفسه
public:
    IntArray(int n) : data(n) {
        for (int i = 0; i < n; ++i) data[i] = i * i;
    }
    int at(int i) const { return data[i]; }
    // لا حاجة إلى مُدمِّر ولا إلى كود نسخ/نقل: vector يتولى كل ذلك.
};

int main() {
    IntArray a(5);
    IntArray b = a;                // نسخ عميق آمن - vector ينسخ نفسه بنفسه
    cout << b.at(3) << "\n";       // 9
    return 0;
}

اعتمد قاعدة الصفر افتراضيًا. ولا تكتب مُدمِّرًا مخصّصًا إلا عندما تملك فعلًا موردًا خامًا لا يغلّفه لك أي نوع قياسي.

المُدمِّرات الافتراضية

عندما تحذف كائنًا عبر مؤشر إلى الصنف الأساسي، يجب أن يكون المُدمِّر virtual - وإلا فلن يُتلَف سوى الجزء الأساسي ويتسرّب الجزء المُشتق. هذا واحد من أكثر العلل شيوعًا في الكود متعدّد الأشكال، والمُترجِم لا يحذّرك منه افتراضيًا.

#include <iostream>
using namespace std;

struct Base {
    virtual ~Base() { cout << "~Base\n"; }   // ‏virtual ضروري هنا
};

struct Derived : Base {
    ~Derived() { cout << "~Derived\n"; }
};

int main() {
    Base* p = new Derived();
    delete p;                  // ‏~Derived ثم ~Base، كلاهما يعمل بشكل صحيح
    return 0;
}

بدون virtual على ~Base، فإن delete p سيستدعي ~Base() فقط - وهو سلوك غير مُعرَّف، ولن يُنظَّف الجزء Derived من الكائن أبدًا. قاعدة عملية: أي صنف يحتوي على دوال افتراضية (صنف أساسي متعدّد الأشكال) يحتاج إلى مُدمِّر افتراضي. سترى بالضبط لماذا يهمّ ذلك بمجرد أن تبدأ في اشتقاق الأصناف.

الأخطاء والمزالق الشائعة

ثمة بضع مزالق يقع فيها الجميع تقريبًا:

عدم تطابق new/delete. إن حجزت بـ new[]، فحرّر بـ delete[]. وخلط new[] مع delete العادي (أو العكس) سلوك غير مُعرَّف.

نسيان virtual على مُدمِّر الصنف الأساسي. كما سبق، حذف كائن مُشتق عبر مؤشر إلى الأساسي دون مُدمِّر افتراضي يُسرّب الجزء المُشتق. إن كنت تكتب صنفًا مقصودًا للوراثة منه، فاجعل المُدمِّر افتراضيًا.

ترك الاستثناءات تفلت من المُدمِّر. المُدمِّر الذي يُلقي استثناءً أثناء فكّ المكدس يُنهي برنامجك. في C++ الحديثة تكون المُدمِّرات ضمنيًا noexcept - فامنع كود التنظيف من إلقاء الاستثناءات، أو ابتلع الاستثناء داخل المُدمِّر.

كتابة مُدمِّر لا تحتاج إليه. إن كانت أعضاؤك تنظّف نفسها أصلًا، فإن ~ClassName() {} فارغًا يضيف ضوضاء وقد يُعطّل عمليات النقل بصمت. وحين لا يكون ثمة ما يُنظَّف، فلا تكتب أي مُدمِّر على الإطلاق.

التالي: الوراثة

لقد رأيت الآن دورة حياة الكائن كاملة - المُنشِئات تبثّ فيه الحياة، والمُدمِّرات تنظّف بعده، والمُدمِّرات virtual تُبقي ذلك التنظيف صحيحًا عندما يُبنى صنف على آخر. تلك النقطة الأخيرة تمهيد للفكرة الكبيرة التالية: الوراثة، حيث يُعيد صنفٌ استخدام بيانات صنف آخر وسلوكه ويوسّعهما. تُظهر الصفحة التالية كيف تشتقّ صنفًا من آخر، وكيف يتسلسل الإنشاء والإتلاف عبر التسلسل الهرمي، وكيف تتلاءم القطع التي تعلّمتها للتو.