عندما لا يكون noexcept مجرد علامة عصرية، بل هو المنقذ في عام 2025

عندما لا يكون noexcept مجرد موضة، بل أداتك الرئيسية في عام 2025

تخيل: أنت تكتب بلغة C++ منذ سنوات، المترجم صامت، الكود يعمل. ولكن فجأة تلاحظ أن std::vector عند إدراج عناصر جديدة يقوم بنسخ الكائنات لسبب ما، على الرغم من أنك حددت بوضوح move-constructor. ألم مألوف؟ مرحبًا بك في عالم حيث noexcept يقرر مصير الأداء.

سؤال «متى يجب علي حقًا استخدام noexcept؟» على Stack Overflow حصد آلاف المشاهدات - وليس بدون سبب. في عام 2025، عندما أصبحت المترجمات أكثر ذكاءً، وأصبحت المكتبة القياسية أكثر تطلبًا للضمانات، يتحول الاستخدام الخاطئ لـ noexcept من تحسين دقيق إلى خطأ فادح. دعنا نفهم أين يكون هذا المُحدد أفضل صديق لك، وأين يكون مجرد ضوضاء زائدة.

شرح موجز: ما هو noexcept ولماذا هو مطلوب؟

noexcept هو مُحدد يخبر المترجم: «هذه الدالة لن ترمي استثناءً أبدًا». في C++17 أصبح جزءًا من نظام الأنواع، وفي C++20 حصل على تأثير أكبر على التحسينات.

عندما تكتب:

void safe_function() noexcept {\n    // كود مضمون عدم رميه للاستثناءات\n}

يحصل المترجم على الضوء الأخضر لـ:

\n
• توليد كود أكثر إحكامًا (بدون عبء فك تكديس الاستثناءات)
\n
• تحسين دلالات النقل (move semantics) في الحاويات
\n
• تبسيط المنطق لـ std::terminate في حالة حدوث استثناء فعلي
\n

لكن الشيء الرئيسي هو أن noexcept يؤثر على سلوك الحاويات القياسية. وهنا يكمن المأزق الأكثر شيوعًا.

القاعدة رقم 1: يجب أن يكون move-constructor و move-assignment operator من نوع noexcept

هذه هي القاعدة الذهبية لـ C++11 وجميع المعايير اللاحقة. إذا لم يتم وضع علامة noexcept على move-constructor الخاص بك، فإن std::vector عند إعادة تخصيص الذاكرة سيقوم بنسخ العناصر بدلاً من نقلها. لماذا؟

لأن std::vector يجب أن يضمن ضمانًا صارمًا لأمان الاستثناءات. إذا كانت عملية النقل يمكن أن ترمي استثناءً، فلن تتمكن الحاوية من العودة إلى الحالة الأصلية. أما النسخ فهو آمن: إذا فشلت النسخة، يبقى الكائن الأصلي سليمًا.

مثال يستحق التذكر:

#include <vector>\n#include <string>\n#include <iostream>\n\nstruct MyData {\n    std::string name;\n    \n    // Move-constructor بدون noexcept\n    MyData(MyData&& other) : name(std::move(other.name)) {\n        // كل شيء جيد، لكن لا يوجد noexcept!\n    }\n};\n\nint main() {\n    std::vector<MyData> vec;\n    MyData d1{"Alice"}, d2{"Bob"};\n    vec.push_back(std::move(d1));\n    vec.push_back(std::move(d2));  \n    // تنبيه: عند إعادة تخصيص الذاكرة\n    // سيتم نسخ العناصر، وليس نقلها!\n    std::cout << "الحجم: " << vec.size() << std::endl;\n    return 0;\n}

الإصلاح هو إضافة noexcept:

MyData(MyData&& other) noexcept : name(std::move(other.name)) {}

الخلاصة: جميع عمليات النقل التي لا ترمي استثناءات (وهي عادة لا ترمي، إذا لم تقم بتخصيص الذاكرة يدويًا) يجب أن تكون مُحددة بـ noexcept. هذا ليس خيارًا - إنه ضرورة للأداء.

القاعدة رقم 2: عمليات swap - مرشح آخر لـ noexcept

دوال swap تُستخدم غالبًا في الخوارزميات والحاويات. إذا كان swap يمكن أن يرمي استثناءً، فإن العديد من الخوارزميات (مثل خوارزميات الترتيب) تفقد فعاليتها.

class Buffer {\n    int* data;\n    size_t size;\npublic:\n    friend void swap(Buffer& a, Buffer& b) noexcept {\n        using std::swap;\n        swap(a.data, b.data);\n        swap(a.size, b.size);\n    }\n};

لماذا هذا مهم؟ لأن std::sort و std::shuffle وغيرها