دلالات النقل هي وسيلة لنقل كائن إلى آخر في C++‎، عبر إفراغ الكائن القديم، وتبديل محتوياته بمحتويات الكائن الجديد. ولفهم دلالات النقل، من الضروري فهم المقصود بالمرجع اليميني (rvalue reference). وهي، أي المراجع اليمينية (‎T&&‎ حيث T يمثّل نوع الكائن) لا تختلف كثيرًا عن المراجع العادية (‎T&‎، يُطلق عليها الآن مراجع يسارية - lvalue references)، لكنهما تتصرّفان كنوعين مختلفين. ونستطيع إنشاء مُنشئات أو دوال تأخذ أحد النوعين، وهو أمر ضروري عند التعامل مع دلالات النقل.

ونحن نحتاج إلى نوعين مختلفين من أجل تحديد سلوكين مختلفين، إذ ترتبط مُنشئات المراجع اليسارية بالنّسخ، في حين ترتبط مُنشئات المراجع اليمينية بالنقل. ولأجل نقل كائن، سنستخدم الدالة ‎std::move(obj)‎ التي تعيد مرجعًا يمينيًا يشير إلى الكائن، ويمكننا استخدام ذلك لنقل بيانات هذا الكائن إلى كائن جديد.

هناك عدّة طرق لفعل ذلك وسنناقشها فيما يلي، فكلّ ما عليك تذكّره الآن هو أنّ استخدام ‎std::move‎ يخلق مرجعًا يمينيًا، أي أن تعليمة std::move(obj)‎ لا تغيّر محتوى الكائن obj، أمّا auto obj2 = std::move(obj)‎ فقد تفعل ذلك.

استخدام std::move لتخفيض التعقيد من O(n²)‎‎ إلى O(n)‎‎

أدخلت C++‎ 11 دعم نقل الكائنات في اللغة الأساسية وفي المكتبة القياسية، فإذا كان لدينا كائن o مؤقّت وكنّا نريد إنشاء نسخة منطقية (logical copy) منه، فعندئذ قد يكون من الآمن أخذ موارده ببساطة، مثل المخزن المؤقّت المخصّص ديناميكيًا (dynamically allocated buffer) الخاص به، تاركين الكائن o فارغًا منطقيًا (logically empty)، ولكن سيبقى قابلاً للتدمير والنسخ.

يشمل دعم اللغة الأساسية (core language) ما يلي:

• باني نوع المراجع اليمينية (rvalue reference type builder‏) ‎&&‎، على سبيل المثال، ‎std::string&&‎ هو مرجع يميني يشير إلى سلسلة نصية (‎std::string‎)، ممّا يبيّن أنّ هذا المرجع مؤقّت، ويمكن نقل موارده.
• دعم خاص لمنشئ النقل - move constructor‏ - ‎T( T&& )‎، الذي يفترض أن ينقل الموارد بكفاءة من الكائن المُحدّد الآخر، بدلاً من نسخ تلك الموارد.
• دعم خاص لعامل إسناد النقل (move assignment operator‏) ‎auto operator=(T&&) -> T&‎، والذي يفترض أيضًا أن يجري عمليّة النقل من المصدر.

يتركّز الدعم الذي تقدمه المكتبة القياسية بالأساس في قالب الدالّة ‎std::move‎ من الترويسة ، وتنتج هذه الدالّة مرجعًا يمينيًا يشير إلى الكائن المُحدّد، وذلك يبيّن أنّه من الممكن النقل منه كما لو كان مؤقّتًا.

تعقيد (complexity) عمليّة نسخ حاوية يساوي عادةً O(n)‎‎، حيث يمثّل n عدد عناصر الحاوية، أمّا النقل فتَعقيده يساوي O(1)‎‎، أي أنّ وقته ثابت. وبالنسبة لخوارزمية تنسخ تلك الحاوية n مرّة منطقيًا، فيمكن لذلك أن يقلّل التعقيد من القيمة O (n²)‎‎ (غير العملية)، إلى التعقيد الخطي O(n)‎‎.

قدّم أندرو كوينج (Andrew Koenig) في مقالته “Containers That Never Change” مثالًا مثيرًا للاهتمام عن عدم كفاءة الخوارزمية عند استخدام نمط برمجة خاص تكون فيه المتغيّرات غير قابلة للتغيير بعد تهيئتها، ففي مثل هذا النمط البرمجي، تُنفَّذ الحلقات (loops) بشكل عام باستخدام التكرارية، وبالنسبة لبعض الخوارزميات، مثل خوارزمية إنشاء تسلسل Collatz‏ (Collatz sequence‏)‏، يتطلب التكرار نسخ الحاوية بشكل منطقي. انظر المثال التالي المبني على مثال كوينج في الرابط أعلاه:

namespace my
{
    template < class Item>
        using Vector_ = /*E.g. std::vector<Item> */ ;
        auto concat( Vector_<int> const& v, int const x ) -> Vector_<int>
        {
            auto result
            {
                v
            };
            result.push_back(x);
            return result;
        }

    auto collatz_aux( int const n, Vector_<int> const& result ) -> Vector_<int>
        {
            if (n == 1)
            {
                return result;
            }

            auto const new_result = concat(result, n);
            if (n % 2 == 0)
            {
                return collatz_aux(n / 2, new_result);
            }
            else
            {
                return collatz_aux(3 *n + 1, new_result);
            }
        }

    auto collatz( int const n ) -> Vector_<int>

        {
            assert(n != 0);
            return collatz_aux(n, Vector_<int> ());
        }

    please split, thi
}    // my فضاء الاسم
#include <iostream>
using namespace std;
auto main()->int
{
    for (int
        const x: my::collatz(42))
    {
        cout << x << ' ';
    }

    cout << '\n';
}

الخرج:

42 21 64 32 16 8 4 2

عدد عمليات نسخ العناصر الناجمة عن نسخ المتجهات يقارب O (n ²)‎ هنا، لأنّه يساوي المجموع 1 + 2 + 3 + … n.

باستخدام المٌصرّفين g++‎ و Visual C++‎، سيُنتج الاستدعاء الوارد أعلاه للتعبير ‎collatz(42)‎ تسلسل Collatz مؤلفًا من 8 عناصر، وسيَنطوي على 36 عملية نسخ للعناصر (‎‎8 * 7/2 = 28، بالإضافة إلى بعض العمليات) في استدعاءات مُنشئ نسخ المتجه.

يمكن تجنّب كل عمليات نسخ العناصر تلك عن طريق نقل المتجهات التي لم تعد هناك حاجة لقيَمِها. وكي نفعل هذا فمن الضروري إزالة ‎const‎ والرجوع إلى وسائط نوع المتجه، وتمرير المتجهات بالقيمة (by value).

تحسَّن القيم المُعادة من الدالة تلقائيا، أما بالنسبة للاستدعاءات التي تُمرّر فيها المتجهات ثمّ لا تُستخدم مرّة أخرى في الدالّة، فما عليك سوى تطبيق ‎std::move‎ لنقل تلك المخازن المؤقّتة (buffers) بدلاً من نسخها:

using std::move;
auto concat( Vector_<int> v, int const x )-> Vector_<int>

    {
        v.push_back(x);

تنبيه: نقل كائن محلي في تعليمة return يمنع ترك النَّسخ، انظر الرابط التالي من SO، نتابع المثال …

// return move(v);
return v;
}

auto collatz_aux( int const n, Vector_<int> result ) -> Vector_<int>

    {
        if (n == 1)
        {
            return result;
        }

        auto new_result = concat(move(result), n);
        struct result;    // بعد الآن `result` التحقق من عدم استخدام
        if (n % 2 == 0)
        {
            return collatz_aux(n / 2, move(new_result));
        }
        else
        {
            return collatz_aux(3 *n + 1, move(new_result));
        }
    }

auto collatz(int
        const n) -
    > Vector_ < int>
    {
        assert(n != 0);
        return collatz_aux(n, Vector_<int> ());
    }

هنا، وباستخدام المصرّفين g++‎ و Visual C++‎، فإنّ عدد عمليات نسخ العناصر الناجمة عن استدعاءات مُنشئ نسخ المتجهات يساوي 0.

ما زال تعقيد الخوارزمية يساوي O (n)‎‎، بيْد أنّه أفضل بكثير من O (n ²)‎‎. ومع بعض الدعم من لغة C++‎، يمكننا أن نستخدم النقل ونفرض جمود المتغيّر (immutability) منذ لحظة تهيتئه وحتّى النقل النهائي، بعد ذلك، فأيّ محاولة لاستخدام هذا المُتغيّر ستُعدّ خطأ. بأي حال فإن ++C لا تدعم هذا بدءًا من الإصدار C++‎ 14.

يمكن فرض قاعدة عدم الاستخدام بعد النقل بالنسبة للشيفرات الخالية من الحلقات (loop-free code)، عبر إعادة التصريح عن الاسم باعتباره بنية (‎struct‎) غير مكتملة، كما هو الحال في ‎struct result;‎ أعلاه، لكن هذا المنظور سيئ ويستبعد أن يفهمها المبرمجون الآخرون؛ أيضًا، قد يكون التشخيص مربكًا.

باختصار، أتاح دعم لغة C++‎ والمكتبة القياسية للنقل تحسينات جذرية على تعقيد الخوارزمية، ولكن بسبب عدم اكتمال الدعم، فإنّ تلك الفائدة ستكون على حساب التخلي عن ضمانات صحّة ووضوح الشيفرة التي يمكن أن توفّرها ‎const‎.

كتتمّة للمثال السابق، سنستخدَم صنف المتجه لقياس عدد عمليات نسخ العناصر الناجمة عن استدعاءات منشئ النسخ:

template < class Item>
    class Copy_tracking_vector
    {
        private:
            static auto n_copy_ops() -> int&{
                static int value;
                return value;
            }

        vector<Item> items_;

        public:
    static auto n() -> int { return n_copy_ops(); }
    void push_back( Item const& o ) { items_.push_back( o ); }
auto begin() const { return items_.begin(); }
    auto end() const { return items_.end(); }
    Copy_tracking_vector(){}
    Copy_tracking_vector( Copy_tracking_vector const& other )  : items_( other.items_ )
    { n_copy_ops() += items_.size(); }
    Copy_tracking_vector( Copy_tracking_vector&& other )  : items_( move( other.items_ ) )
    {}

    };

منشئ النقل (Move constructor)

لنقل أن لدينا الشيفرة التالية:

class A
{
    public:
        int a;
    int b;

    A(const A &other)
    {
        this->a = other.a;
        this->b = other.b;
    }
};

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

وبدلًا من ذلك، يمكننا كتابة ‎A(const A &) = default;‎، التي تنسخ تلقائيًا جميع الأعضاء باستخدام مُنشئ النسخ الخاص بها.

سنأخذ مرجعًا يمينيًا بدلًا من اليساري، من أجل إنشاء مُنشئ نقل (move constructor)، كما هو مُوضّح هنا.

class Wallet
{
    public:
        int nrOfDollars;

    Wallet() = default;    //default ctor
    Wallet(Wallet &&other)
    {
        this->nrOfDollars = other.nrOfDollars;
        other.nrOfDollars = 0;
    }
};

يرجى ملاحظة أنّنا ضبطنا القيم القديمة عند القيمة ‎zero‎، ينسخ مُنشئ النقل الافتراضي (‎Wallet(Wallet&&) = default;‎) قيمة ‎nrOfDollars‎، لأنّه نوع بيانات قديم (Plain Old Data أو POD).

وبما أن دلالات النقل مُصمّمة للسماح بسرقة الحالة من النُسخة الأصلية، فالسؤال الآن هو كيف ستظهر النسخة الأصلية بعد تلك "السرقة"؟

Wallet a;
a.nrOfDollars = 1;
Wallet b(std::move(a));    // B(B&& other); استدعاء
std::cout << a.nrOfDollars << std::endl;    //0
std::cout << b.nrOfDollars << std::endl;    //1

وهكذا نكون قد أنشأنا كائنًا بشكل نقليّ (move constructed) من كائن آخر قديم. ربما يكون المثال السابق بسيطًا إلّا أنّه يوضّح آلية عمل مُنشئات النقل، وتظهر فائدته في الحالات الأكثر تعقيدًا، كما يحدث في حالات إدارة الموارد. انظر الشيفرة التالية التي تدير عمليات تتضمن نوعًا بعينه، وتملك مساعِدًا على الكومة (heap) وآخر في ذاكرتها، في المكدَّس غالبًا. وكلا المساعدان DefaultConstructible و CopyConstructible و MoveConstructible:

template < typename T,
    template<typename> typename HeapHelper,
    template<typename> typename StackHelper>
    class OperationsManager
    {
        using MyType = OperationsManager<T, HeapHelper, StackHelper> ;
        HeapHelper<T> *h_helper;
        StackHelper<T> s_helper;
        // ...
        public:
            // Five لـ &Rule المنشئ الافتراضي
            OperationsManager(): h_helper(new HeapHelper < T>) {}

        OperationsManager(const MyType& other): h_helper(new HeapHelper<T> (*other.h_helper)), s_helper(other.s_helper) {}

        MyType& operator=(MyType copy)
        {
            swap(*this, copy);
            return * this;
        }~OperationsManager()
        {
            if (h_helper)
            {
                delete h_helper;
            }
        }

منشئ نقل بدون ()swap، يأخذ *<HeapHelper<T و <StackHelper <T من other من خلال فرض استخدام منشئ النقل الخاص بـ <StackHelper <T. ويٌحِلّ nullptr مكان *<HeapHelper<T الخاص بـ other، لمنع الأخير من حذف مساعِدنا الجديد حين يُدمَّر، نتابع المثال …

        OperationsManager(MyType&& other) noexcept: h_helper(other.h_helper),
            s_helper(std::move(other.s_helper))
            {
                other.h_helper = nullptr;
            }

منشئ نقل (مع ()swap)، نضع أعضاءنا في الشرط الذي نريد أن يكون فيه other ثم نبادل الأعضاء معه، نتابع …

        // OperationsManager(MyType&& other) noexcept : h_helper(nullptr) {
        //       swap(*this, other);
        // }

        // Copy/move helper.
        friend void swap(MyType &left, MyType &right) noexcept
        {
            std::swap(left.h_helper, right.h_helper);
            std::swap(left.s_helper, right.s_helper);
        }
    };

إعادة استخدام كائن منقول

يمكنك إعادة استخدام كائن منقول على النحو التالي:

void consumingFunction(std::vector<int> vec)
{
    // بعض العمليات
}

int main()
{
    // 1, 2, 3, 4 تهيئة المتجه بالقيم
    std::vector<int> vec
    { 1, 2, 3, 4 };
    // by move إرسال المتجه بالنقل
    consumingFunction(std::move(vec));
    // في حالة غير محدّدة vec الكائن
    // نظرا لأنّ الكائن لم يُدمَّر، يمكننا أن نسند إليه محتوى جديدا
    // في هذه الحالة، سنسند قيمة فارغة إلى المتجه ما يجعله فارغًا 
    vec = {};
    // نظرًا لأنّ المتجه قد اكتسب قيمة محدّدة، فيمكننا استخدامه بشكل طبيعي
    vec.push_back(42);
    // إرسال المتجه عبر النقل مجددا
    consumingFunction(std::move(vec));
}

إسناد النقل (Move assignment)

على غرار إسناد قيمة لكائن باستخدام مرجع يساري، ثمّ نسخه، يمكننا أيضًا نقل القيم من كائن إلى آخر دون إنشاء كائن جديد، إذ نستدعي إسناد النقل، ثمّ ننقل القيم من كائن إلى كائن آخر موجود.

سيتعيّن علينا أن نزيد تحميل العامل ‎operator =‎ لنجعله يأخذ مرجعًا يمينيًا.

class A
{
    int a;
    A& operator=(A&& other)
    {
        this->a = other.a;
        other.a = 0;
        return * this;
    }
};

هذه هي الصيغة النموذجية لتعريف إسناد النقل، إذ نزيد تحميل‎operator =‎ حتى نتمكن من تزويده بمرجع يميني، وإسناده إلى كائن آخر.

A a;
a.a = 1;
A b;
b = std::move(a);    // A& operator= (A&& other) استدعاء
std::cout << a.a << std::endl;    //0
std::cout << b.a << std::endl;    //1

ومن ثم يمكننا إسناد كائن نقليًا (move assign) إلى كائن لآخر.

استخدام دلالات النقل على الحاويات

يمكنك نقل حاوية بدلاً من نسخها على النحو التالي:

void print(const std::vector<int>& vec)
{
    for (auto&& val: vec)
    {
        std::cout << val << ", ";
    }

    std::cout << std::endl;
}

int main()
{
    // 1, 2, 3, 4 بالقيم vec1 تهيئة المتجه
   // كمتجه فارغ vec2 ثمّ تهيئة
    std::vector<int> vec1
    { 1, 2, 3, 4 };
    std::vector<int> vec2;

    // 1, 2, 3, 4 السطر التالي سيطبع
    print(vec1);

    // السطر التالي سيطبع سطرا جديدا
    print(vec2);

    // عبر إسناد النقل vec2 أُسنِدت قيمة المتجه
    // دون نسخها vec1 هذا سيسرق قيمة

    vec2 = std::move(vec1);
    // هنا في حالة غير محدّدة، لكن يبقى صالحًا vec1 المتجه
    // لم يُدمَّر بعد، لكن لا يوجد ضمان بخصوص الكائنات التي يحتويها vec1 الكائن

    // 1, 2, 3, 4 السطر التالي سيطبع
    print(vec2);
}

هذا الدرس جزء من سلسلة دروس عن C++‎.

ترجمة -بتصرّف- للفصل Chapter 106: Move Semantics من كتاب C++ Notes for Professionals

ما المقصود بالسلوك غير المعرَّف (undefined behavior أو UB)؟ وفقًا لمعيار ISO C++‎ (الفقرة 1.3.24، N4296)، فهو:

اقتباس

"أيّ سلوك لا يكون مفروضًا من قبل المواصفة القياسية الدولية."

هذا يعني أنّه عندما يواجه البرنامج سلوكًا غير معرَّف، فإنّه يُسمَح له بفعل ما يريد. هذا قد يعني غالبًا التوقف عنا العمل، ولكنّه قد يعني تجاهله وعدم فعل أيّ شيء، أو قد يعمل البرنامج بشكل صحيح!، ولا شك أن عليك تجنب كتابة شيفرات تؤدي إلى سلوكيات غير معرَّفة.

أما السلوك غير المُحدَّد فهو أيّ سلوك قد يتغير من جهاز إلى آخر، أو من مصرّف إلى آخر. لا يمكن التنبؤ الدقيق بسلوكيات البرامج التي تحتوي سلوكات غير محدّدة في مرحلة الاختبار، لأنّها تتعلق بالتقديم (implementation). لذا يُفضّل عموما تجنّب هذا النوع من السلوكات قدر الإمكان.

القراءة أو الكتابة من مؤشّر فارغ

int *ptr = nullptr;
*ptr = 1;    // سلوك غير معرَّف

هذا سلوك غير معرَّف لأنّ المؤشّر الفارغ لا يشير إلى أي كائن صالح، لذلك لا يوجد كائن في ‎*ptr‎ للكتابة عليه. ورغم أنّ هذا قد يتسبب غالبًا في حدوث خطأ في التجزئة (segmentation fault)، إلا أنّه غير مُعرَّف، وقد يحدث أي شيء.

استخدام متغيّر محلي غير مهيّأ

int a;
std::cout << a;    // سلوك غير معرَّف

ينتج عن هذا سلوك غير معرَّف لأنّ ‎a‎ غير مهيّأة. يدّعي البعض (خطأً) أنّ هذا ناتج عن أنّ القيمة "غير معرَّفة "، أو بسبب "القيمة التي كانت سابقًا في ذلك الموقع من الذاكرة". والصحيح أنّ محاولة الوصول إلى قيمة ‎a‎ في المثال أعلاه هي التي أدّت إلى سلوك غير معرَّف.

ومحاولة طباعة "قيمة مُهملة" (garbage value) هي عرض شائع في هذه الحالة لكن هذا ليس سوى شكل واحد ممكن من السلوكات غير المعرَّفة.

الإصدار ≥ C++‎ 14

استخدام قيمة غير معرَّفة من نوع ‎unsigned char‎ لا ينتج عنه سلوك غير معرَّف عند استخدام القيمة كـ: *معامل ثاني أو ثالث للمعامل الشرطي الثلاثي (ternary conditional operator).

• معامَل أيمن لمُعامل الفاصلة المُضمّن (comma operator).
• معامَل التحويل إلى ‎unsigned char‎.
• معامَل أيمن لمُعامل الإسناد إذا كان المعامل الأيسر من النوع ‎unsigned char‎.
• مُهيئ لكائن ‎unsigned char‎؛

أو حتى عند تجاهل القيمة. ففي مثل هذه الحالات، تنتشر (propagates) القيمة غير المعرَّفة ببساطة إلى نتيجة التعبير إن أمكن. لاحظ أنّ المتغيّرات الساكنة (‎static‎) تُهيّأ دائمًا عند القيمة صفر (إن أمكن):

static int a;
std::cout << a;    // تساوي 0 'a' سلوك معرَّف، و

محاولة الوصول إلى فهرس خارج النطاق

محاولة الوصول إلى فهرس خارج نطاق مصفوفة (أو حاوية من المكتبة القياسية، إذ أنّها جميعًا منفَّذة باستخدام مصفوفات خام) تؤدّي إلى سلوك غير معرَّف:

int array[] = { 1, 2, 3, 4, 5 };
array[5] = 0;    // سلوك غير معرَّف

لكن يُسمح بالحصول على مؤشّر يشير إلى نهاية المصفوفة (أي ‎array + 5‎ في هذه الحالة)، بيْد أنّه يُحظر تحصيله (dereference)، لأنّه ليس عنصرًا صالحًا.

const int *end = array + 5;    // مؤشر إلى الموضع الذي يلي العنصر الأخير
for (int *p = array; p != end; ++p)
    // `p` افعل شيئا ما بـ

بشكل عام، لا يُسمح لك بإنشاء مؤشّر خارج الحدود، إذ يجب أن يشير المؤشّر إلى عنصر داخل المصفوفة، أو إلى الموضع الذي يلي نهاية المصفوفة.

حذف كائن مشتق عبر مؤشّر يشير إلى صنف أساسي لا يتوفّر على حاذِف وهمي

class base {};
class derived: public base {};
int main()
{
    base* p = new derived();
    delete p;    // سلوك غير معرَّف
}

تشير الفقرة ‎‎5.3.5 / 3‎‎ من المعيار إلى أنّه إذا استُدعِيت ‎delete‎ على كائن لا يحتوي نوعُه الساكن (static type) على مُدمّر وهمي (‎virtual‎)، فإنّه:

اقتباس

إذا كان النوع الساكن للكائن المراد حذفه مختلفًا عن نوعه الديناميكي، فينبغي أن يكون النوع الساكن صنفًا أساسيًا للنوع الديناميكي للعنصر المراد حذفه، ويجب أن يكون للنوع الساكن مدمّر افتراضي، وإلّا فإنّ السلوك سيكون غير معرَّف.

هذا يبقى صحيحًا بغض النظر عمّا إذا كان الصنف المشتق قد أضاف أو لم يضف أيّ حقول إلى الصنف الأساسي.

توسيع فضاءي الاسم "std" أو "posix"

يحظر المعيار (‎‎17.6.4.2.1 / 1) عمومًا توسيع فضاء الاسم ‎std‎:

اقتباس

يكون سلوك برامج C++‎ غير معرَّف عند إضافة تصريحات أو تعريفات إلى فضاء الاسم std، أو إلى فضاء اسم داخل std، ما لم يُحدّد خلاف ذلك.

وينطبق نفس الشيء على‎‎‎posix‎‏ (‎‎17.6.4.2.2 / 1):

اقتباس

يكون سلوك برامج C++‎ غير معرَّف عند إضافة تصريحات أو تعريفات إلى فضاء الاسم posix أو إلى فضاء اسم ضمن posix، ما لم يُحدّد خلاف ذلك. انظر:

#include <algorithm>

namespace std
{
    int foo() {}
}

لا شيء في المعيار يحظر على ‎algorithm‎ (أو أيٍّ من الترويسات التي يتضمّنها) إعادة تعريف نفس التعريف، وهذا قد يؤدّي إلى انتهاك قاعدة التعريف الواحد (One Definition Rule). ولذلك فهو ممنوع بشكل عام لكن مع بعض الاستثناءات، فمثلًا يُسمح بإضافة تخصيصات للأنواع المُعرَّفة من المستخدمين.

في المثال التالي، لنفترض أنّ الشيفرة تحتوي على:

class foo
{
    // شيفرة هنا
};

الشيفرة التالية صالحة:

namespace std
{
    template < >
        struct hash < foo>
        {
            public: size_t operator()(const foo &f) const;
        };
}

حسابيات غير صالحة على المؤشّرات Invalid pointer arithmetic

ستتسبّب الاستخدامات التالية لحسابيات المؤشّر في حدوث سلوك غير معرَّف:

• إضافة أو طرح عدد صحيح إذا لم تنتمي النتيجة إلى نفس المصفوفة التي يشير إليها المؤشّر. (هنا، يُعدّ العنصر الموجود بعد النهاية جزءًا من المصفوفة.)

int a[10];
int* p1 = &a[5];
int* p2 = p1 + 4;    //  a[9] يشير إلى p2 جيد، لأنّ
int* p3 = p1 + 5;    // a يشير إلى الموضع الذي يلي p2 جيد، لأنّ
int* p4 = p1 + 6;    // سلوك غير معرَّف
int* p5 = p1 - 5;    // a[0] يشير إلى p2 جيد، لأنّ
int* p6 = p1 - 6;    // سلوك غير معرَّف
int*  p7 = p3 - 5;    // a[5] يشير إلى p7 جيد، لأنّ

• طرح (subtraction) مؤشّرين إذا لم ينتمي كلاهما إلى نفس المصفوفة، مرّة أخرى، يعدّ العنصر الذي يلي العنصر الأخير من المصفوفة جزءًا من المصفوفة، والاستثناء الوحيد هو أنّه يمكن طرح مؤشّرين فارغين، والنتيجة ستكون 0.

int a[10];
int b[10];
int *p1 = &a[8], *p2 = &a[3];
int d1 = p1 - p2; // 5
int *p3 = p1 + 2;  //  a يشير إلى الموضع الذي يلي العنصر الأخير في p2 جيد، لأنّ
int d2 = p3 - p2; // 7
int *p4 = &b[0];
int d3 = p4 - p1; // سلوك غير معرَّف

• طرح مؤشّرين إذا كانت النتيجة تطفح (overflow) عن ‎std::ptrdiff_t‎.
• أيّ عملية حسابية على المؤشّرات لا يتطابق فيها نوع أحد المعامَليْن (operand) مع النوعَ الديناميكي للكائن المُشار إليه من قبل ذلك المؤشّر (تجاهل التأهيل - cv-qualification). فوفقًا للمعيار فإنه:

اقتباس

"[بشكل خاص]، لا يمكن استخدام مؤشّر يشير إلى صنف أساسي في العمليات الحسابية للمؤشّرات عندما تحتوي المصفوفة على كائنات من نوع صنف مشتق."

struct Base { int x; };
struct Derived : Base { int y; };
Derived a[10];
Base* p1 = &a[1];    // جيد
Base* p2 = p1 + 1;    // Derived  يشير إلى p1 سلوك غير معرَّف، لأنّ
Base* p3 = p1 - 1;    // نفس الشيء
Base* p4 = &a[2];    // سلوك غير معرَّف
auto p5 = p4 - p1;    // Derived  يشيران إلى p4 و  p1  سلوك غير معرَّف، لأنّ
const Derived* p6 = &a[1];
const Derived* p7 = p6 + 1;  // لا تهمّ cv-qualifiers جيد، لأن المؤهّلات 

عدم وجود تعليمة return في دالّة نوعها المُعاد يخالف void

سيؤدّي حذف تعليمة ‎return‎ في دالّة نوعها المُعاد غير فارغ (‎void‎) إلى سلوك غير معرَّف.

int
function()
{
    // return غياب تعليمة 
}

int main()
{
    function();    // سلوك غير معرَّف
}

تطرح معظم المٌصرّفات الحديثة تحذيرًا في وقت التصريف إذا صادَفَت مثل هذه السلوكيات غير المعرَّفة.

ملاحظة: ‎main‎ هي الاستثناء الوحيد لهذه القاعدة. إذا لم تحتو ‎main‎ على تعليمة ‎return‎، فسيُدرِج المصرّف تلقائيًا التعبير ‎return 0;‎ نيابة عنك، لذلك يمكنك عدم وضعها إن شئت.

الوصول إلى مرجع معلّق (Accessing a dangling reference)

لا يمكن الوصول إلى مرجع يشير إلى كائن خرج عن النطاق أو تمّ تدميره، ويقال أن هذا المرجع "مُعلّق" (dangling)، لأنّه لم يُعد يشير إلى كائن صالح.

#include <iostream>
int& getX()
{
    int x = 42;
    return x;
}

int main()
{
    int& r = getX();
    std::cout << r << "\n";
}

في هذا المثال، يخرج المتغيّر المحلي ‎x‎ عن النطاق عند إعادة ‎getX‎. لاحظ أنّ تمديد دورة الحياة (lifetime extension) لا يمكنه أن يطيل دورة الحياة الخاصة بالمتغيّر المحلي بعد الخروج من نطاق الكتلة التي عُرِّف فيها. لذلك فإن المرجع ‎r‎ أصبح معلقًا. هذا البرنامج له سلوك غير معرَّف رغم أنّه قد يبدو أنّه يعمل بدون مشاكل، بل إنّه قد يطبع ‎42‎ في بعض الحالات.

قسمة عدد صحيح على الصفر

int x = 5 / 0;    // سلوك غير معرَّف

القسمة على ‎0‎ هي عمليّة غير معرَّفة في الرياضيات، فلا جرم أنّها تؤدّي إلى سلوك غير معرَّف في البرمجة.

في المثال التالي، x تساوي موجب ما لا نهاية infinity+.

float x = 5.0f / 0.0f; 

تعتمد معظم التنفيذات (implementaions) على المعيار IEEE-754، الذي ينصّ على أنّ قسمة عدد عشري (floating point) على الصفر ستعيد القيمة الخاصة "ليس عددًا" ‎NaN‎ (إذا كان البسْط يساوي ‎0.0f‎)، أو ‎infinity‎ (إذا كان البسط موجبًا)، أو ‎-infinity‎ (إذا كان البسط سالباً).

الإزاحة بعدد غير صالح من المنازل

بالنسبة لعامل الإزاحة (shift operator) المُضمّن، يجب أن يكون العامل الأيمن غير سالب وأصغر من طول العامل الأيسر بالبتّات. خلاف ذلك، فإنّ السلوك سيكون غير معرَّف.

const int a = 42;
const int b = a << -1;    // سلوك غير معرَّف
const int c = a << 0;    // ok

في السطرين التاليين، ينتج لنا سلوك غير معرَّف إذا كان طول int يساوي 32 أو أقل …

const int d = a << 32;  
const int e = a >> 32;

في حالة const int g = f << 10، هذا مقبول حتى لو كان طول signed char أقل من أو يساوي 10 بت، ويجب ألا يقل طول int عن 16 بت …

const signed char f = 'x';
const int g = f << 10;   

تخصيص الذاكرة وتحريرها بشكل غير صحيح

• لا يمكن تحرير (deallocated) كائن عبر ‎delete‎ إلا إن كان قد خُصِّص من قبل عبر ‎new‎ ولم يكن مصفوفةً. أما إذا لم يكن الوسيط المُمرّر إلى ‎delete‎ مُعادًا من ‎new‎، أو لم يكن مصفوفةً، فسيكون السلوك غير معرَّف.
• لا يمكن تحرير كائن عبر ‎delete[]‎ إلا إن كان قد خُصِّص من قبل عبر ‎new‎ ولم يكن مصفوفةً. أما إذا لم يكن الوسيط المُمرّر إلى ‎delete[]‎ مُعادًا من ‎new‎، أو لم يكن مصفوفةً، فسيكون السلوك غير معرَّف.
• إذا لم يكن الوسيط المُمرّر إلى ‎free‎ مُعادًا من ‎malloc‎، فسيكون السلوك غير معرَّف.

int* p1 = new int;
delete p1;    // صحيح
// delete[] p1;    // غير معرَّف
// free(p1);    //  غير معرَّف
int* p2 = new int[10];
delete[] p2;    // صحيح
// delete p2;    //  غير معرَّف
// free(p2);    //  غير معرَّف
int* p3 = static_cast<int*>(malloc(sizeof(int)));
free(p3);    // صحيح
// delete p3;    //  غير معرَّف
// delete[] p3;    //  غير معرَّف

يمكن تجنّب هذه المشاكل عن طريق تجنّب ‎malloc‎ و ‎free‎ في برامج C++‎، فمن الأفضل استخدام المؤشّرات الذكية بدلًا من ‎new‎ و ‎delete‎ الخام، كما يُفضَّل استخدام ‎std::vector‎ و ‎std::string‎ على ‎new‎ و ‎delete[]‎

طفح الأعداد الصحيحة المُؤشّرة (Signed Integer Overflow)

انظر المثال التالي:

int x = INT_MAX + 1;
// سلوك غير معرَّف

اقتباس

إذا لم تُعرَّف النتيجة رياضيًا أثناء تقييم تعبير ما أو لم تكن ضمن نطاق القيم القابلة للتمثيل لنوع ذلك التعبير، فسيكون السلوك غير معرَّف. (C++‎ 11، الفقرة 5/4 من المعيار)

هذا أحد أسوأ حالات السلوكيات غير المعرَّفة لأنّها تنتج سلوكًا غير معرَّف متكرّر ولا يوقف البرنامج، لذا قد لا ينتبه إليه المطوّرون.

من ناحية أخرى:

unsigned int x = UINT_MAX + 1;
// تساوي 0 x 

يؤدي هذا إلى سلوك معرَّف جيدًا بما أنه:

اقتباس

يجب على الأعداد الصحيحة غير المُؤشّرة والمُصرّح عنها أن تلتزم بقوانين معامل الباقي الحسابي (arithmetic modulo)‏ ‎2^n‎، حيث يمثّل ‎n‎ عدد البتات في تمثيل الأعداد الصحيحة.

(C++‎ 11 الفقرة ‎‎3.9.1 / 4 من المعيار)

أحيانًا قد تستغل المٌصرّفات السلوكات غير المعرَّفة وتحسّنها.

signed int x;
if (x > x + 1)
{
    // افعل شيئا ما
}

وطالما أنّ طفح الأعداد الصحيحة المُؤشّرة (signed integer overflow) يؤدي إلى سلوك غير معرَّف، فيمكن للمُصرّف تجاهله وافتراض أنّه لن يحدث أبدا، ومن ثم يمكنه استبعاد كتلة if.

التعريفات المتعدّدة غير المتطابقة (قاعدة التعريف الواحد)

إذا كان أي مما يلي معرَّفًا في عدة واحدات ترجمة فيجب أن تكون جميع التعريفات متطابقة أو سيكون السلوك غير معرَّف وفقًا لقاعدة التعريف الواحد (ODR): الأصناف، التعدادات، الدوال المضمنَّة، القوالب، الأعضاء في القوالب.

foo.h‎:

class Foo
{
    public:
        double x;
    private:
        int y;
};
Foo get_foo();

‎‎foo.cpp:

#include "foo.h"

Foo get_foo()
{ /*التنفيذ*/ }

main.cpp:

// Foo أريد الوصول إلى العضو الخاص، لذا سأستخدم النوع الخاص بي بدلًا من 
class Foo
{
    public:
        double x;
    int y;
};
Foo get_foo();    // foo.h سنصرّح عن هذه الدالة بأنفسنا لأننا لم نُضمَِن
int main()
{
    Foo foo = get_foo();
    // foo.y افعل شيئا ما بـ
}

يتسبّب البرنامج أعلاه في سلوك غير معرَّف لأنّه يحتوي على تعريفين غير متطابقين للصنف ‎::Foo‎، والذي له صلة خارجية (external linkage) في وحدات ترجمة مختلفة. وعلى عكس إعادة تعريف صنف داخل وحدة الترجمة نفسها، فإن المٌصرّف ليس مُلزمًا بتشخيص هذه المشكلة.

محاولة تعديل كائن ثابت (Modifying a const object)

إنّ أيّ محاولة لتعديل كائن ثابت ‎const‎ سينتج عنها سلوك غير معرَّف، هذا ينطبق على المتغيّرات الثابتة وأعضاء الكائنات الثابتة، وأعضاء الأصناف المُصرّح عنها عبر ‎const‎. بالمقابل، فإنّ عضوا متغيّرًا ‎mutable‎ من كائن ثابت ‎const‎ لن يكون ثابتا، وقد تحدث هذه المحاولة عبر ‎const_cast‎:

const int x = 123;
const_cast<int&>(x) = 456;
std::cout << x << '\n';

عادة ما يُضمِّن المٌصرّف قيمة الكائن ‎const int‎، وعليه فيحتمل أن تُصرَّف هذه الشيفرة وتطبع ‎123‎، كذلك يمكن للمٌصرّفات وضع قيم الكائنات الثابتة في ذاكرة مخصّصة للقراءة فقط، ومن ثم قد يحدث خطأ في التجزئة (segmentation fault). وسيكون السلوك بشكل عام غير معرَّف، ولا يمكن التنبؤ بما سيفعله البرنامج.

ينطوي البرنامج التالي على خطأ خفِىّ:

#include <iostream>

class Foo* instance;
class Foo
{
    public:
        int get_x() const
        {
            return m_x;
        }

    void set_x(int x)
    {
        m_x = x;
    }

    private:
        Foo(int x, Foo* &this_ref): m_x(x)
        {
            this_ref = this;
        }

    int m_x;
    friend
    const Foo &getFoo();
};
const Foo &getFoo()
{
    static
    const Foo foo(123, instance);
    return foo;
}

void do_evil(int x)
{
    instance->set_x(x);
}

int main()
{
    const Foo &foo = getFoo();
    do_evil(456);
    std::cout << foo.get_x() << '\n';
}

في الشيفرة السابقة، أنشأت دالة ‎getFoo‎ مفردة (singleton) من نوع ‎const Foo‎، وتمت تهيئة عضوها ‎m_x‎ عند القيمة ‎123‎. ثم استُدعِيت ‎do_evil‎ يبدو أنّ هذا غيّر قيمة ‎foo.m_x‎ إلى 456. فأين مكمن الخطأ؟

لا تفعل ‎do_evil‎ أيّ شيء شرّير رغم اسمها، فكلّ ما تفعله هو استدعاء ضابط (setter) من خلال ‎Foo*‎، لكنّ هذا المؤشّر يشير إلى كائن ‎const Foo‎ رغم عدم استخدام ‎const_cast‎، وقد تمّ الحصول على هذا المؤشّر عبر مُنشئ ‎Foo‎.

لا يصبح كائن ثابت ثابتًا (‎const‎) حتى تكتمل عمليّة التهيئة، لذلك فإنّ نوع المؤشّر ‎this‎ يساوي ‎Foo*‎، وليس const Foo*‎ داخل المنشئ، وبسبب ذلك يحدث سلوك غير معرَّف، رغم عدم وجود أيّ إنشاءات خطيرة في هذا البرنامج.

محاولة إعادة قيمة من دالة لا تعيد قيمة

الإصدار ≥ C++‎ 11

هذا مثال من المعيار [dcl.attr.noreturn]:

[[noreturn]] void f()
    {
        throw "error";    // حسنا
    }

[
    [noreturn]
    ] void q(int i)
    {
        // السلوك غير معرَّف في حال كان الوسيط أصغر من أو يساوي 0
        if (i > 0)
            throw "positive";
    }

تكرار لا نهائي للقالب

هذا مثال من المعيار ‎‎[temp.inst] / 17: يتطلب التوليد الضمني لـ <X<T استنساخًا ضمنيًا والذي يتطلب بدوره استنساخًا ضمنيًا لـ <*X<T والذي يتطلب بدوره استنساخًا ضمنيًا لـ <**X<T وهكذا …

template < class T > class X
{
    X<T> *p;    // OK
    X<T*> a;  
};

التدفق الزائد الناتج عن التحويل من وإلى عدد عشري

عند تحويل:

• نوع عددي صحيح إلى نوع عدد عشري.
• أو نوع عدد عشري إلى نوع عددي صحيح.
• أو نوع نوع عدد عشري إلى نوع عدد عشري أقصر.

فسيحدث سلوك غير معرَّف إن كانت القيمة المصدرية (source value) خارج نطاق القيم التي يمكن تمثيلها في النوع المقصود، انظر المثال التالي حيث لا يمكن لـ int تخزين عناصر كبيرة إلى هذا الحد، لذا يحدث سلوك غير معرَّف.

double x = 1e100;
int y = x;    

تعديل سلسلة نصّية مجردة

الإصدار < C++‎ 11 ‎"hello world"‎ في المثال أدناه هي سلسلة نصّية مجردة، لذا فإنّ محاولة تعديلها ستؤدّي إلى سلوك غير معرَّف.

char *str = "hello world";
str[0] = 'H';

طريقة تهيئة ‎str‎ في المثال أعلاه أصبحت مهملة رسميًا في C++‎ 03 (من المقرر إزالتها من الإصدارات المستقبلية للمعيار)، قد تصدر بعض المٌصرّفات القديمة (قبل عام 2003) تحذيرًا بشأن ذلك، وأصبحت المٌصرّفات تحذّر عادة من أنّ هناك تحويلات متجاوَزة بعد عام 2003.

الإصدار ≥ C++‎ 11

المثال أعلاه غير جائز ويؤدّي إلى إطلاق عملية تشخيص (diagnostic) من قبل المصرّف في الإصدار C++‎ 11 والإصدارات الأحدث. يمكن إنشَاء مثال لتوضيح السلوك غير المعرَّف من خلال السماح بتحويل النوع بشكل صريح على النحو التالي:

char *str = const_cast<char*> ("hello world");
str[0] = 'H';

الوصول إلى كائن بافتراض أنّه من النوع الخاطئ

لا تجوز محاولة الوصول إلى كائن من نوع معيّن كما لو كان من نوع آخر مختلف في معظم الحالات -متجاهلين المؤهِّلات cv- qualifiers. انظر المثال التالي:

float x = 42;
int y = reinterpret_cast<int&>(x);

النتيجة ستكون سلوكًا غير معرَّف.

هناك بعض الاستثناءات لقاعدة التسمية البديلة الصارمة (strict aliasing rule):

• يمكن الوصول إلى كائن كما لو كان من صنف أساسي (base class) للصنف الفعلي الذي ينتمي إليه.
• يمكن الوصول إلى أيّ نوع كما لو كان من النوع ‎char‎ أو ‎unsigned char‎، لكنّ العكس ليس صحيحًا، مثلًا: لا يمكن الوصول إلى مصفوفة مكوّنة من حروف كما لو كانت نوعًا عشوائيًا.
• يمكن الوصول إلى نوع عددي صحيح مؤشّر كما لو كان من النوع غير المؤشَّر المقابل له، والعكس صحيح.

هناك قاعدة قريبة من هذا تقول أنّه إذا استُدعِي تابع غير ساكن على كائن من صنف آخر غير الصنف الذي عُرّف فيه ذلك التابع، أو صنف مشتقّ منه، فسيحدث سلوك غير معرَّف. ويبقى هذا صحيحًا حتى لو لم تحاول الدالّة الوصول إلى ذلك الكائن.

struct Base {
};
struct Derived : Base {
void f() {}
};
struct Unrelated {};
Unrelated u;
Derived& r1 = reinterpret_cast<Derived&>(u); // ok
r1.f(); //  سلوك غير معرَّف
Base b;
Derived& r2 = reinterpret_cast<Derived&>(b); // ok
r2.f();   //  سلوك غير معرَّف

التحويلات غير الصالحة من صنف مشتق إلى صنف أساسي، للمؤشّرات العضوية (pointers to members)

عند استخدام ‎static_cast‎ لتحويل ‎T D::*‎ إلى ‎T B::*‎، يجب أن ينتمي العضو المشار إليه إلى صنف يمثّل صنفًا أساسيًا (base class) أو مشتقًّا من ‎B‎. بخلاف ذلك، فإنّ السلوك سيكون غير معرَّف.

محاولة تدمير كائن دُمِّر من قبل

في هذا المثال، يُستدعى المُدمّر بشكل صريح على كائن سيتم تدميره تلقائيًا في وقت لاحق.

struct S
{
    ~S()
    {
        std::cout << "destroying S\n";
    }
};
int main()
{
    S s;
    s.~S();
}    // سلوك غير معرَّف، بسبب تدمير العنصر للمرة الثانية هنا

تحدث مشكلة مماثلة عندما يشير مؤشّر ‎std::unique_ptr<T>‎ إلى نوع ‎T‎ ذي مدّة تخزين (storage duration) تلقائية أو ساكنة، إذ يؤدي تدمير s في حال عودة f إلى سلوك غير معرَّف، لأن s مدمَّرة فعلًا.

void f(std::unique_ptr<S> p);
int main()
{
    S s;
    std::unique_ptr<S> p(&s);
    f(std::move(p)); 
}

محاولة تدمير كائن ما مرتين قد ينتج عنها وجود مؤشّرين مشتركين ‎shared_ptr‎ يديران الكائن دون مشاركة الملكية مع بعضهما البعض.

void f(std::shared_ptr<S> p1, std::shared_ptr<S> p2);
int main()
{
    S* p = new S;
    // أريد تمرير نفس الكائن مرّتين
    std::shared_ptr<S> sp1(p);
    std::shared_ptr<S> sp2(p);
    f(sp1, sp2);
}           

نتيجة الشيفرة السابقة سلوك غير معرف لأن sp2 و sp1 سيحاولان تدمير s بشكل منفصل، لكن بأي حال، فما يلي صحيح:

std::shared_ptr<S> sp(p);
f(sp, sp);

محاولة الوصول إلى عضو غير موجود عبر مؤشّر عضوي

عند محاولة الوصول إلى عضو غير ساكن من كائن معيّن عبر مؤشّر عضوي (pointer to member)، فسيحدث سلوك غير معرَّف إذا لم يكن الكائن يحتوي فعليًا ذلك العضو الذي يشير إليه المؤشّر، إذ يمكن الحصول على المؤشّر العضوي عبر ‎static_cast‎.

struct Base { int x; };
struct Derived : Base { int y; };
int Derived::*pdy = &Derived::y;
int Base::*pby = static_cast<int Base::*>(pdy);
Base* b1 = new Derived;
b1->*pby = 42;    // Derived  في كائن من النوع y جيد، تعيين
Base* b2 = new Base;
b2->*pby = 42;    // Base في  y سلوك غير معرَّف، لأنّه لا يوجد عضو

تحويل غير صالح من الصنف الأساسي إلى صنف مشتق

عند استخدام ‎static_cast‎ على مؤشّر أو مرجع يشير إلى صنف أساسي، من أجل تحويله إلى مؤشّر أو مرجع يشير إلى صنف مشتق منه، فسيكون السلوك غير معرَّف إن لم يكن المُعامل يشير (يرجِع) إلى كائن من الصنف المشتق.

طفح الأعداد العشرية Floating point overflow

إذا أنتجت عملية حسابية قيمة لا تنتمي إلى مجال القيم التي يمكن تمثيلها في النوع الناتج، وكان يُفترض أن تعيد عددًا عشريًا، فإنّ السلوك سيكون غير معرَّف وفقًا لمعيار C++‎، لكن قد يكون معرَّفا في معايير أخرى قد تتوافق معها الآلة، مثل IEEE 754.

float x = 1.0;
for (int i = 0; i < 10000; i++)
{
    x *= 10.0;    // قد يؤدّي في النهاية إلى حدوث تدفق زائد، وسينتج عن ذلك سلوك غير معرَّف
}

استدعاء أعضاء وهمية (خالصة) من مُنشئ أو مدّمر

ينصّ المعيار (10.4) على ما يلي:

اقتباس

يمكن استدعاء التوابع من مُنشئ أو مُدمّر خاص بصنف مجرّد، وسيحدث سلوك معرَّف عند إجراء استدعاء وهمي - virtual call - ‏(10.3) لدالّة وهمية خالصة - pure virtual function - بشكل مباشر أو غير مباشر على الكائن الذي يجري إنشاءه (أو تدميره) من مثل هذا المُنشئ (أو المدمّر).

وعمومًا، يقترح بعض كُبراء C++‎، مثل سكوت مايرز (Scott Meyers) تجنّب استدعاء الدوال الوهميّة (حتى غير الخالصة منها) من المنشئات والمُدمِّرات. انظر المثال التالي المُعدّل من الرابط أعلاه:

class transaction
{
    public:
        transaction()
        {
            log_it();
        }

    virtual void log_it() const = 0;
};
class sell_transaction: public transaction
{
    public: virtual void log_it() const
    { /* افعل شيئا ما */ }
};

لنفترض أنّنا أنشأنا كائنًا ‎sell_transaction‎:

sell_transaction s;

يستدعي هذا ضمنيًا مُنشئ ‎sell_transaction‎، الذي يستدعي أولًا مُنشئ ‎transaction‎. وفي لحظة استدعاء مُنشئ ‎transaction‎ لن يكون الكائن من النوع ‎sell_transaction‎ بعدُ وإنّما سيكون من النوع ‎transaction‎. وعليه فإنّ استدعاء ‎log_it‎ في ‎transaction::transaction()‎ لن يقوم بالمُتوقّع منه - أي استدعاء ‎sell_transaction::log_it‎.

• إذا كانت ‎log_it‎ وهمية خالصة، كما هو مُوضّح في هذا المثال، فإنّ السلوك سيكون غير معرَّف
• إذا لم تكن ‎log_it‎ وهمية خالصة، فستُستدعى ‎transaction::log_it‎.

استدعاء دالّة عبر مؤشّر دالّة من نوع غير مطابق

من أجل استدعاء دالة عبر مؤشّر دالة، يجب أن يتطابق نوع مؤشّر الدالّة مع نوع الدالّة، أما خلاف ذلك فإنّ السلوك سيكون غير معرَّف. هذا مثال على ذلك:

int f();
void(*p)() = reinterpret_cast<void(*)() > (f);
p();    // غير معرَّف

الإشارة إلى أعضاء غير ساكنة في قائمة مهيئ

فيما يلي مزيد من الأمثلة عن كيفية حدوث الأخطاء في C++‎. يمكن أن تؤدي الإشارة إلى أعضاء غير ساكنين (non-static members) في قوائم المهيئات (initializer lists) قبل بدء تنفيذ المُنشئ إلى حدوث سلوك غير معرَّف، ذلك أنه في هذه المرحلة لن يكون جميع الأعضاء قد أُنشِؤوا بعد. انظر هذا المُقتطف من المسوَّدة القياسية:

اقتباس

12.7.1: بالنسبة لكائن ذي مُنشئ غير اعتيادي (non-trivial constructor)، ستؤدّي الإشارة إلى عضو غير ساكن أو صنف أساسي للكائن قبل أن يبدأ تنفيذ المُنشئ إلى نتائج غير مُحدّدة.

هذا مثال على ذلك:

struct W { int j; };
struct X : public virtual W { };
struct Y {
    int *p;
    X x;
    Y() : p(&x.j) { // لم يُنشأ بعد x غير محدد، لأنّ
}
};

نكتفي بالحديث عن السلوك غير المُعرَّف وننتقل بدءًا من هذا القسم وما يليه إلى الحديث عن السلوك غير المُحدَّد (Unspecified behavior).

قيمة لتعداد خارج النطاق

عند تحويل تعداد إلى نوع عددِي صحيح، وكان ذلك النوع أصغر من أن يحتفظ بقيمة التعداد، فستكون القيمة الناتجة غير محددة، انظر المثال التالي:

enum class E {
    X = 1,
        Y = 1000,
};
// char نفترض أنّ العدد 1000 لا يُمكن أن يُخزَّن في
char c1 = static_cast < char > (E::X); // تساوي 1 c1 قيمة
char c2 = static_cast < char > (E::Y); // غير معينة c2 قيمة

كذلك عند تحويل عدد صحيح إلى تعداد، وكانت قيمة العدد الصحيح خارج نطاق قيم التعداد، فإنّ القيمة الناتجة ستكون غير محددة. انظر المثال التالي:

enum Color {
    RED = 1,
        GREEN = 2,
        BLUE = 3,
};
Color c = static_cast < Color > (4);

بالمقابل، لمّا كانت قيمة المصدر في المثال التالي تقع في نطاق التعداد، فإنّ السلوك لن يكون "غير معيّن"، رغم أنّها لا تساوي أيّ عدّاد (enumerator):

enum Scale {
    ONE = 1,
        TWO = 2,
        FOUR = 4,
};
Scale s = static_cast < Scale > (3);

هنا، ستكون قيمة ‎s‎ مساوية لـ 3، ولن تساوي ‎ONE‎ أو ‎TWO‎ أو ‎FOUR‎.

ترتيب تقييم وسائط دالة (Evaluation order of function arguments)

إذا كان لدالّة ما عدّة وسائط، فسيكون ترتيب تقييمها غير محدد. انظر المثال التالي، حيث يحتمل أن تطبع الشيفرة التالية إمّا ‎x = 1, y = 2‎ أو ‎x = 2, y = 1‎.

int f(int x, int y) {
    printf("x = %d, y = %d\n", x, y);
}
int get_val() {
    static int x = 0;
    return ++x;
}
int main() {
    f(get_val(), get_val());
}

الإصدار ≥ C++‎ 17

في C++‎ 17، يظل ترتيب تقييم وسائط الدالّة غير محدد، رغم أن كل وسائط الدالة تُقيّم بشكل كامل كما يُضمن تقييم كائن الاستدعاء calling object قبل تقييم وسائط الدالة.

struct from_int {
    from_int(int x) {
        std::cout << "from_int (" << x << ")\n";
    }
};
int make_int(int x) {
    std::cout << "make_int (" << x << ")\n";
    return x;
}
void foo(from_int a, from_int b) {}
void bar(from_int a, from_int b) {}
auto which_func(bool b) {
    std::cout << b?"foo":"bar" << "\n";
    return b ? foo : bar;
}
int main(int argc, char const*const* argv) {
    which_func(true)(make_int(1), make_int(2));
}

سيكون الخرج إمّا:

bar
make_int(1)
from_int(1)
make_int(2)
from_int(2)

أو:

bar
make_int(2)
from_int(2)
make_int(1)
from_int(1)

قد لا تطبع الشيفرة السلسلة النصية ‎bar‎ بعد ‎make‎ أو ‎from‎، وقد لا تطبع ما يلي أيضًا:

bar
make_int(2)
make_int(1)
from_int(2)
from_int(1)

كانت طباعة ‎bar‎ بعد ‎make_int‎ قبل C++‎ 17 غير جائزة، ولا تنفيذ ‎make_int‎ s قبل ‎from_int‎.

نتيجة التحويلات من النوع reinterpret_cast

تكون نتيجة التحويل ‎reinterpret_cast‎ من نوع مؤشر دالة إلى آخر أو من نوع مرجع دالة ما إلى آخر، تكون غير محددة. انظر المثال التالي حيث تكون قيمة fp غير محددة.

int f();
auto fp = reinterpret_cast<int(*)(int)>(&f); 

الإصدار ≤ C++‎ 03

بالمثل، ستكون نتيجة تحويل ‎reinterpret_cast‎ من نوع مؤشّر كائن (object pointer) إلى آخر، أو من نوع مرجع كائن (object reference) إلى آخر، غير محددة. انظر المثال التالي حيث تكون قيمة p غير محددة:

int x = 42;
char* p = reinterpret_cast<char*>(&x); 

يكافئ هذا في معظم المُصرِّفات تحويلَ ‎static_cast<char*>(static_cast<void*>(&x))‎، لذلك يشير المؤشّر الناتج ‎p‎ إلى البايت الأول من ‎x‎، وهذا هو السلوك القياسي في C++‎ 11.

المساحة التي يشغلها مرجع ما

المرجع ليس كائنًا، إذ أنّه على عكس الكائنات، لا يحتل بالضرورة مجموعة متجاورة من البايتات في الذاكرة، ولا يحدّد المعيار مسألة ما إذا كان المرجع يتطلب أيّ تخزين أصلًا.

وبعض المزايا في C++‎ 17 تجعل مسألة التحقق من أيّ تخزين قد يشغله المرجع بشكل محمول (portably) أمرًا مستحيلًا:

• فعند تطبيق ‎sizeof‎ على مرجع ما فإنها تُعيد حجم النوع المشار إليه، ومن ثم لن تعطي معلومات عمّا إذا كان المرجع يشغل مساحة تخزين ما.
• مصفوفات المراجع (Arrays of references) غير جائزة، لذا لا يمكن التحقّق من عنواني عنصرين متتاليين لمرجع يشير إلى مصفوفات بُغية تحديد حجم المرجع.
• في حال أخذ عنوان مرجع ما، فإنّ النتيجة ستكون عنوان العنصر المشار إليه في ذلك المرجع، لذا لا يمكننا الحصول على مؤشّر يشير إلى المرجع نفسه.
• إذا كان لصنف ما عضو مرجعي (reference member)، فإنّ محاولة استخراج عنوان ذلك العضو باستخدام ‎offsetof‎ ستؤدي إلى سلوك غير معرَّف، لأنّ مثل هذا الصنف لن يكون صنفَ تخطيط قياسي (standard-layout class).
• إذا كان لصنف ما عضوٌ مرجعي، فلن يعدّ الصنف تخطيطًا قياسيًا (standard layout)، لذا سينتج عن محاولة الوصول إلى البيانات المُستخدمة لتخزين المرجع سلوكًا غير معرَّف، أو سلوكًا غير محدد.

وعمليًا، يمكن في بعض الحالات تنفيذ متغيّر مرجعي (reference variable) على هيئة متغيّر مؤشّر (pointer variable)، وسيشغل حينها نفس مساحة التخزين التي يشغلها المؤشّر، بينما قد لا يشغل المرجع في حالات أخرى أيّ مساحة على الإطلاق نتيجة لعمليات التحسين (optimisation). على سبيل المثال، في الشيفرة التالية:

void f() {
    int x;
    int& r = x;
    // r افعل شيئا ما بـ
}

يستطيع المُصرِّف معاملة ‎r‎ كاسم بديل (alias) لـ ‎x‎، واستبدال كل تكرارات ‎x‎ في بقية الدالّة ‎f‎ بـ r، مع عدم تخصيص أيّ ذاكرة لـ ‎r‎.

حالة "منقول-منه" Moved-from لأغلب أصناف المكتبات القياسية

الإصدار ≥ C++‎ 11

تُترك جميع حاويات المكتبات القياسية في حالة غير محددة لكن صالحة بعد النقل منها. على سبيل المثال، في الشيفرة التالية، ‎v2‎ ستتضمّن ‎{1, 2, 3, 4}‎ بعد النقل، لكن لن تكون ‎v1‎ فارغة بالضرورة.

int main() {
    std::vector v1{1, 2, 3, 4}; 
    std::vector < int > v2 = std::move(v1);
}

تكون لبعض الأصناف حالة مُحدّدة بدقة بعد النقل منها، والحالة الأهم هي حالة std::unique_ptr<T>‎، التي تكون فارغة بعد النقل منها.

نتيجة المقارنة بين المؤشّرات

ستكون النتيجة غير محددة عند مقارنة مؤشّرين باستخدام العوامل ‎<‎ أو ‎>‎ أو ‎<=‎ أو ‎>=‎، وذلك في الحالات التالية:

• إذا كانت المؤشّرات تشير إلى مصفوفات مختلفة، إذ تُعدّ الكائنات التي ليست مصفوفات عبارة عن مصفوفات من الحجم 1.

int x;
int y;
const bool b1 = &x < &y; // غير محدد
int a[10];
const bool b2 = &a[0] < &a[1]; // true
const bool b3 = &a[0] < &x; // غير محدد
const bool b4 = (a + 9) < (a + 10); // true
// إلى الموضع الذي يلي المصفوفة a+10 تشير

• إذا كانت المؤشرات تشير إلى داخل نفس الكائن، لكن إلى أعضاء ذات متحكمات وصول (access control) مختلفة.

class A {
    public:
        int x;
    int y;
    bool f1() { return &x < &y; } // true
    bool f2() { return &x < &z; } // غير محدد
    private:
        int z;
};

‎

التحويل الساكن من من قيمة من النوع void*‎

إذا حُوِّلَت قيمةٌ من نوع ‎void*‎ إلى مؤشّر يشير إلى نوع ‎T*‎، لكن لم تحاذى بشكل صحيح مع ‎T‎، فستكون قيمة المؤشّر الناتجة غير محددة. انظر المثال التالي، لنفترض أن (alignof(int تساوي 4:

int x = 42;
void* p1 = &x;
// إنجاز بعض العمليات الحسابية على المؤشر
void* p2 = static_cast<char*>(p1) + 2;
int* p3 = static_cast<int*>(p2);

قيمة ‎p3‎ غير محددة لأنّ ‎p2‎ لا يمكن أن تشير إلى كائن من النوع ‎int‎؛ فمُحاذاة عنوان قيمتها غير صحيحة.

ترتيب تهيئة الكائنات العامّة عبر وحدة الترجمة

يكون ترتيب تهيئة المتغيّرات العامة محددًا داخل وحدة الترجمة، بينما يكون ترتيب التهيئة عبر عدة وحدات ترجمة غير محدد. لذلك فالبرنامج الذي به الملفات التالية:

• foo.cpp

#include <iostream>

int dummyFoo = ((std::cout << "foo"), 0);

• bar.cpp

#include <iostream>

int dummyBar = ((std::cout << "bar"), 0);

• main.cpp

int main() {}

قد يُنتِج الخرج التالي:

foobar

أو:

barfoo

وقد يؤدّي ذلك إلى إخفاق ترتيب التهيئة الساكنة (Static Initialization Order Fiasco).

الاتحادات Unions والسلوك غير المعرَّف

انظر المثال التالي:

union U {
    int a;
    short b;
    float c;
};
U u;
u.a = 10;
if (u.b == 10) {
}

سينجم عن الشيفرة أعلاه سلوك غير معرَّف، ذلك أن a كان آخر عضو يُكتَب فيه. وتجيز الكثير من المصرّفات هذا الأمر، وقد تكتفي بإصدار تحذير، بيْد أنّ النتيجة ستكون "كما هو متوقع"؛ أن هذه إضافة للمصرّف (extension compiler)، لذا لا يمكن ضمان هذا السلوك في جميع المصرّفات (فهي شيفرة غير محمولة ولا متوافقة).

الاتحادات (Unions) هي بنيات مخصصة تحتلّ أعضاؤها مساحة مشتركة في الذاكرة.

union U {
    int a;
    short b;
    float c;
};
U u;
//سيكونان متساويين a و b عنوانا
(void*)&u.a == (void*)&u.b;
(void*)&u.a == (void*)&u.c;
// إسناد قيمة إلى أيّ عضو من الاتحاد يغير الذاكرة المشتركة
u.c = 4. f;
u.a = 5;
u.c != 4. f;

تساعد الاتحادات على ترشيد استخدام الذاكرة المخصّصة للبيانات الحصرية (exclusive data)، كما في تنفيذ أنواع مختلطة من البيانات.

struct AnyType {
    enum {
        IS_INT,
        IS_FLOAT
    }
    type;

    union Data {
        int as_int;
        float as_float;
    }
    value;
    AnyType(int i): type(IS_INT) {
        value.as_int = i;
    }
    AnyType(float f): type(IS_FLOAT) {
        value.as_float = f;
    }
    int get_int() const {
        if (type == IS_INT)
            return value.as_int;
        else
            return (int) value.as_float;
    }

    float get_float() const {
        if (type == IS_FLOAT)
            return value.as_float;
        else
            return (float) value.as_int;
    }
};

هذا الدرس جزء من سلسلة دروس عن C++‎.

ترجمة -بتصرّف- للفصول:

• Chapter 104: Undefined Behavior
• Chapter 140: More undefined behaviors in C++‎
• Chapter 121: Unspecified behavior
• Chapter 111: Unions

من كتاب C++ Notes for Professionals

كلمة SFINAE هي اختصار للجملة: Substitution Failure Is Not An Error، وتشير إلى أنّه لا تُعد الشيفرات سيئة الصيغة بسبب تعويض الأنواع (أو القيم) لأجل استنساخ قالب دالة (instantiate a function template) أو قالب صنف، لا تُعدُّ خطأً تصريفيا فادحًا (hard compile error)، وإنّما يتم التعامل معها على أنّها فشل في استنتاج النوع فقط.

فشل استنتاج النوع في قوالب دوالّ الاستنساخ (instantiating function templates) أو تخصيصات قالب الصنف (class template specializations) يؤدي إلى إهمال ذلك النوع أثناء محاولة استنتاج النوع (كما لو أنّ ذلك النوع المرشح المُستبعد لم يكن موجودًا من البداية).

template < class T>
    auto begin(T& c) -> decltype(c.begin()) { return c.begin(); }

template < class T, size_t N>
    T* begin(T (&arr)[N]) { return arr; }

int vals[10];
begin(vals);

تفشل المحاولة الأولى لتعويض قالب الدالة في (begin(vals من الشيفرة السابقة، لأن صيغة ()vals.begin خطأ، لكن لا يعطي هذا خطأً بل ستُزال تلك الدالة من ترشيحها للتحميل الزائد، تاركة إيانا مع التحميل الزائد للمصفوفات (array overload).

لا يعدُّ فشل الاستبدال فشلًا في الاستنتاج إلّا في السياق الفوري (immediate context)، أمّا في الحالات الأخرى، فستُعد أخطاء فادحة (hard errors).

template < class T>
    void add_one(T& val) { val += 1; }

int i = 4;
add_one(i);    // حسنا
std::string msg = "Hello";
add_one(msg);    // error. msg += 1 is ill-formed for std::string, but this
// T لم يحدث الفشل في السياق الفوري لتعويض

void_t

الإصدار ≥ C++‎ 11

‎void_t‎ هي دالّة وصفية (meta-function) تحول الأنواع إلى النوع الفارغ (type void)، وغرضها الأساسي هو تسهيل كتابة سمات النوع (type traits). ستكون std::void_t جزء من C++‎ 17، ولكنّ تنفيذها سهل على أي حال:

template < class... > using void_t = void;

تتطّلب بعض المٌصرّفات تنفيذًا مختلفًا قليلاً:

template < class... >
    struct make_void
    {
        using type = void;
    };
template < typename...T >
    using void_t = typename make_void < T... >::type;

التطبيق الأساسي لـ ‎void_t‎ هو كتابة سمات النوع التي تتحقّق من صحّة عبارة برمجية. على سبيل المثال، دعنا نتحقّق ممّا إذا كان نوع ما له دالة تابعة ‎foo()‎ لا تأخذ أيّة وسائط:

template < class T, class = void >
    struct has_foo: std::false_type {};
template < class T>
struct has_foo<T, void_t<decltype(std::declval<T&>().foo())>> : std::true_type {};

سيحاول المُصرّف عند محاولة استنساخ ‎has_foo<T>::value‎ أن يبحث عن أفضل تخصيص لـ ‎has_foo<T, void>‎. لدينا خياران هنا، الأوليّ والثانوي، يتطلب الثانوي استنساخ التعبير الأساسي (underlying expression):

• إذا لم يحتوي‎T‎ على دالة تابعة ‎foo()‎، فسيُحوّل النوع المُعاد إلى ‎void‎، وسيُفضَّل التخصِيص (specialization) على القالب الأوّلي بناءً على قواعد الترتيب الجزئي للقوالب (template partial ordering rules). لذا، فإنّ has_foo<T>::value ستساوي true
• إذا لم يكن ‎T‎ يتحوي على تلك الدالة التابعة (أو إذا كانت موجودة، بيْد أنّها تتطّلب أكثر من وسيط واحد)، فستفشل عملية الاستبدال بالتخصيص، وسنعود إلى القالب الأساسي. وعندئذ ستساوي ‎has_foo<T>::value‎ القيمة ‎false‎.

هذا المثال لا يستخدم ‎std::declval‎ أو ‎decltype‎:

template < class T, class = void >
    struct can_reference: std::false_type {};
template < class T>
    struct can_reference<T, std::void_t<T&>> : std::true_type {};

لاحظ النمط الشائع لاستخدام الوسيط الفارغ (void argument). يمكننا كتابة الشيفرة التالية:

struct details
{
    template<template < class... > class Z, class = void, class...Ts >
        struct can_apply:
        std::false_type {};
    template<template < class... > class Z, class...Ts >
        struct can_apply<Z, std::void_t<Z < Ts... >>, Ts... >:
        std::true_type {};
};
template<template < class... > class Z, class...Ts >
    using can_apply = details::can_apply<Z, void, Ts... > ;

والتي تتجّنب استخدام ‎std::void_t‎، وتستخدم ‎can_apply‎ بدلًا من ذلك، والتي تتصرّف كمحدّد (indicator) يوضح ما إذا كان النوع المتوفّر كوسيط أوّل للقالب مُصاغًا صيغة صحيحة بعد استبدال الأنواع الأخرى فيه. يمكن الآن إعادة كتابة الأمثلة السابقة باستخدام ‎can_apply‎ على النحو التالي:

template<class T>
using ref_t = T&;
template<class T>
using can_reference = can_apply<ref_t, T>;   // مصاغة صيغة صحيحة T& 

و:

template<class T>
using dot_foo_r = decltype(std::declval<T&>().foo());
template<class T>
using can_dot_foo = can_apply< dot_foo_r, T >;   // مصاغة صيغة صَحيحة T.foo() 

والتي تبدو أبسط من النسخ السابقة، هناك مقترحات بعد الإصدار C++‎ 17 لإنشاء سمات ‎std‎ مماثلة لـ ‎can_apply‎.

يُعزى اكتشاف فائدة ‎void_t‎ إلى والتر براون (Walter Brown)، في العرض الرائع الذي قدّمه في CppCon 2016.

enable_if

std::enable_if هي أداة مساعدة لاستخدام الشروط المنطقية لتفعيل قاعدة SFINAE. وتُعرّف على النحو التالي:

template < bool Cond, typename Result = void >
    struct enable_if {};
template < typename Result>
    struct enable_if<true, Result>
    {
        using type = Result;
    };

بمعنى أنّ ‎enable_if<true, R>::type‎ هو اسم بديل (alias) لـ ‎R‎، في حين أنّ صيغة ‎enable_if<false, T>::type‎ غير صحيحة نظرًا لأنّ تخصيص ‎enable_if‎ لا يحتوي على نوع عضوي (member type‏) ‎type‎.

نستطيع استخدام std::enable_if لتقييد القوالب:

int negate(int i) { return -i; }

template <class F>
auto negate(F f) { return -f(); }

هنا سيفشل استدعاء ‎negate(1)‎ بسبب الغموض، لكنّ التحميل الزائد الثاني ليس مُعدًّا لاستخدامه مع الأنواع العددية الصحيحة، لذلك يمكننا إضافة:

int negate(int i) { return -i; }

template <class F, class = typename std::enable_if<!std::is_arithmetic<F>::value>::type>
auto negate(F f) { return -f(); }

الآن، سيؤدّي استنساخ ‎negate<int>‎ إلى فشل التعويض لأنّ ‎!std::is_arithmetic<int>::value‎ تساوي ‎false‎. لكن بسبب قاعدة SFINAE، فلَن يكون هذا خطأ فادحًا (hard error)، وإنّما سيُزال هذا المرشّح من مجموعة المرشحين للتحميل الزائد وحسب. ونتيجة لذلك، لن يكون لـ negate(1)‎ إلّا مرشح واحد وهو الذي سيُستدعى.

متى نستخدَمها

تذكر أنّ ‎std::enable_if‎ هو مُساعد يعمل مع قاعدة SFINAE، لكن ليس هو الذي يجعلها تعمل في المقام الأول، دعنا ننظر في البديلين التاليين لتنفيذ وظائف مماثلة لـ ‎std::size‎، وهي مجموعة تحميل زائد لـ ‎size(arg)‎ تعيد حجم الحاوية أو المصفوفة:

// للحاويات
template < typename Cont>
    auto size1(Cont const& cont) -> decltype( cont.size() );

// للمصفوفات
template<typename Elt, std::size_t Size>
std::size_t size1(Elt const(&arr)[Size]);

// حذف التنفيذ
template < typename Cont>
    struct is_sizeable;

// للحاويات
template<typename Cont, std::enable_if_t<std::is_sizeable<Cont>::value, int> = 0>
    auto size2(Cont const& cont);

// للمصفوفات
template < typename Elt, std::size_t Size>
    std::size_t size2(Elt const(&arr)[Size]);

على افتراض أنّ ‎is_sizeable‎ مكتوبة بشكل صحيح، فيجب أن يكون هذان التصريحان متكافئين تمامًا بحسب قاعدةSFINAE، فأيّهما أسهل في الكتابة وفي المراجعة والفهم؟

سنحاول الآن تنفيذ بعض المساعِدات الحسابية التي تتفادى طفح (overflow) الأعداد الصحيحة غير المؤشّرة لصالح سلوك الالتفاف (wraparound) أو السلوك القابل للتعديل (modular). هذا يعني مثلًا أنّ ‎incr(i, 3)‎ ستكافئ ‎i += 3‎ باستثناء حقيقة أنّ النتيجة ستكون دائمًا مُعرّفة حتى لو كان ‎i‎ عددًا صحيحًا يساوي ‎INT_MAX‎. ما يلي بديلان ممكنان:

// معالجة الأنواع المؤشَّرة
template < typename Int>
    auto incr1(Int& target, Int amount)
-> std::void_t<int[static_cast<Int>(-1) < static_cast<Int>(0)]>;

// target += amount معالجة الأنواع غير المؤشَّرة عبر
// بما أنّ حسابيات العناصر غير المؤشَّرة تتصرف كما هو مطلوب
template < typename Int>
    auto incr1(Int& target, Int amount)
-> std::void_t<int[static_cast<Int>(0) < static_cast<Int>(-1)]>;

template<typename Int, std::enable_if_t<std::is_signed<Int>::value, int> = 0>
void incr2(Int& target, Int amount);
template<typename Int, std::enable_if_t<std::is_unsigned<Int>::value, int> = 0>
void incr2(Int& target, Int amount);

مرّة أخرى، أيّهما أسهل في الكتابة، وأيّهما أسهل في المراجعة والفهم؟

تتمثّل قوة ‎std::enable_if‎ في طريقة تعاملها مع إعادة الإنتاج (refactoring) وتصميم الواجهات البرمجية، فإذا كان الغرض من ‎is_sizeable<Cont>::value‎ هو التحقّق من صحّة ‎cont.size()‎، فقد يكون استخدام التعبير كما يظهر في ‎size1‎ أوجز، رغم أنّ ذلك قد يعتمد على ما إذا كانت ‎is_sizeable‎ ستُستخدَم في العديد من المواضع أم لا. على النقيض من ذلك، فإنّ ‎std::is_signed‎ أكثر وضوحًا ممّا كانت عليه عندما كان تنفيذها يتسرّب إلى تصريح ‎incr1‎.

is_detected

لتعميم إنشاء type_trait استنادًا إلى قاعدة SFINAE، فهناك بعض السمات التجريبية، وهي: ‎detected_or‎ و ‎detected_t‎ و ‎is_detected‎.

ومع معاملات القوالب ‎typename Default‎ و ‎template <typename...> Op‎ و ‎typename ... Args‎:

• ‎is_detected‎: هو اسم بديل لـ std::true_type أو std::false_type اعتمادًا على صلاحية Op<Args...>
• ‎detected_t‎: هو اسم بديل لـ Op<Args...>‎ أو ‎nonesuch‎ اعتمادًا على صلاحية Op<Args...>‎.
• ‎detected_or‎: هو اسم بديل لبنية لها ‎value_t‎ مرصودة (‎is_detected‎)، ونوع ‎type‎ يحقّقOp<Args...>‎ أو ‎Default‎ اعتمادًا على صلاحية ‎Op<Args...>‎

ويمكن تنفيذ باستخدام ‎std::void_t‎ لأجل قاعدة SFINAE على النحو التالي:

الإصدار ≥ C++‎ 17

namespace detail
{
    template < class Default, class AlwaysVoid,
        template < class... > class Op, class...Args >
        struct detector
        {
            using value_t = std::false_type;
            using type = Default;
        };
    template < class Default, template < class... > class Op, class...Args >
        struct detector<Default, std::void_t<Op < Args... >>, Op, Args... >
        {
            using value_t = std::true_type;
            using type = Op < Args... > ;
        };
}    // تفاصيل فضاء الاسم
// نوع خاص للإشار إلى رصد الخطأ
struct nonesuch
{
    nonesuch() = delete;
   ~nonesuch() = delete;
   nonesuch(nonesuch const&) = delete;
   void operator=(nonesuch const&) = delete;

};
template <template<class...> class Op, class... Args>
using is_detected = typename detail::detector<nonesuch, void, Op, Args...>::value_t;
template <template<class...> class Op, class... Args>
using detected_t = typename detail::detector<nonesuch, void, Op, Args...>::type;
template <class Default, template<class...> class Op, class... Args>
using detected_or = detail::detector<Default, void, Op, Args...>;

يمكن تنفيذ السمات التي ترصد وجود تابع على النحو التالي:

typename <typename T, typename ...Ts>
using foo_type = decltype(std::declval<T>().foo(std::declval<Ts>()...));
struct C1 {};
struct C2
{
    int foo(char) const;
};
template < typename T>
    using has_foo_char = is_detected<foo_type, T, char> ;
static_assert(!has_foo_char<C1>::value, "Unexpected");
static_assert(has_foo_char<C2>::value, "Unexpected");
static_assert(std::is_same<int, detected_t<foo_type, C2, char>>::value,
    "Unexpected");
static_assert(std::is_same<void,    // افتراضي
    detected_or<void, foo_type, C1, char>>::value,
    "Unexpected");
static_assert(std::is_same<int, detected_or<void, foo_type, C2, char>>::value,
    "Unexpected");

تحليل تحميل زائد له عدد كبير من الخيارات

إذا كنت بحاجة إلى الاختيار بين عدة خيارات، فقد يكون تمكين خيار واحد فقط عبر ‎enable_if<>‎ مرهقًا للغاية، إذ يجب إلغاء العديد من الشروط لاستبعاد الخيارات الأخرى، وبدلاً من ذلك، يمكن اختيار ترتيب التحميلات الزائد باستخدام الوراثة، أي بإرسال الوسم (tag dispatch).

وبدلاً من التحقق من صحّة الصيغة وكذلك التحقق من أنّ جميع الشروط الأخرى غير متحقّقة، فإنّنا سنكتفي باختبار الأشياء التي نحتاجها وحسب، ويفضل أن يكون ذلك في ‎decltype‎ في إعادة زائدة (trailing return).

قد يؤدّي هذا إلى تجاهل الكثير من الخيارات ذات الصيغة الصحيحة، لكن نستطيع التفريق بينها باستخدام "الوسوم" (tags)، على غرار وسوم مكرّرات السمات (‎random_access_tag‎). وسيعمل هذا بدون مشاكل لأنّ الحصول على تطابق مباشر أفضل من الصنف الأساسي (base class)، والذي هو بدوره أفضل من الصنف الأساسي لصنف أساسي (base class of a base class)، وهكذا دواليك.

#include <algorithm>
#include <iterator>

namespace detail
{
    // سيعطينا هذا عددا غير محدود من الأنواع التي ترث بعضها بعضا
    template<std::size_t N>
        struct pick: pick < N - 1 > {};
    template < >
        struct pick < 0> {};

التحميل الزائد الذي نريد له أن يكون مفضَّلًا يجب أن تكون قيمة N له أكبر في <pick<N، ما يلي أول دالة قالب مساعِدة، نتابع المثال …

    template < typename T>
        auto stable_sort(T& t, pick<2>)-> decltype( t.stable_sort(), void() )

        {

إن كانت الحاوية لديها stable_sort فاستخدمه، …

            t.stable_sort();
        }

    // المساعد سيكون ثاني أفضل تطابق ممكن
    template < typename T>

template<typename T>
auto stable_sort(T& t, pick<1>)-> decltype( t.sort(), void() )
        {

إذا كان للحاوية عضو sort لكن لم يكن فيها stable_sort فسيكون sort مستقرًا غالبًا، نتابع …

            t.sort();
        }

    // هذا المساعد سيكون آخر مرشح
    template < typename T>
        auto stable_sort(T& t, pick<0>)-> decltype( std::stable_sort(std::begin(t), std::end(t)), void() )

        {

الحاوية لا تحتوي على عضو sort أو stable_sort …

           std::stable_sort(std::begin(t), std::end(t));
        }
}

// 'tags' هذه هي الدالة التي يستدعيها المستخدم، ستقوم بإرسال الاستدعاء إلى التقديم الصحيح بمساعدة
template < typename T>
    void stable_sort(T& t)
    {
        // مع قيمة أكبر من القيم السابقة N استخدم
        // هذا سيختار أعلى تحميل زائد من بين التحميلات الزائدة صحيحة الصيغة
        detail::stable_sort(t, detail::pick < 10> {});
    }

هناك عدّة طرق أخرى للتمييز بين التحميلات الزائدة، مثل أنّ المطابقة التامة أفضل من التحويل، والتي هي بدورها أفضل من علامة الحذف (ellipsis). بالمقابل، يمكن أن يتوسّع وسم الإرسال إلى أيّ عدد من الخيارات، وهو أكثر وضوحًا وصراحة في العادة.

الكلمة المفتاحية decltype الزائدة في قوالب الدوالّ

الإصدار ≥ C++‎ 11

يمكن استخدام ‎decltype‎ زائدة (trailing) لتحديد نوع القيمة المُعادة:

namespace details
{
    using std::to_string;
    // to_string(T) ينبغي أن تكون قادرة على استدعاء
    template < class T>
        auto convert_to_string(T const& val, int )-> decltype(to_string(val))

        }

   // ellipsis argument هذه غير مقيّدة، لكن يُفضَّل عدم استخدامها بسبب وسيط علامة الحذف
    template < class T>
        std::string convert_to_string(T const& val, ... )
        {
            std::ostringstream oss;
            oss << val;
            return oss.str();
        }
}

template < class T>
    std::string convert_to_string(T const& val)
    {
        return details::convert_to_string(val, 0);
    }

في حال استدعاء ‎convert_to_string()‎ باستخدام وسيط يمكن استدعاء الدالة ‎to_string()‎ من خلاله، فعندها ستكون لدينا دالتان قابلتان للتطبيق على ‎details::convert_to_string()‎، والأولى مُفضّلة لأنّ تسلسل التحويل الضمني من ‎0‎ إلى ‎int‎ أفضل من التحويل من ‎0‎ إلى ‎...‎

أما في حال استدعاء ‎convert_to_string()‎ باستخدام وسيط لا يمكننا عبره استدعاء ‎to_string()‎، فحينئذٍ سيؤدّي استنساخ قالب الدالة الأوّل إلى فشل الاستبدال - substitution failure - (ليس هناك ‎decltype(to_string(val))‎)، ونتيجة لذلك، يُزال هذا المرشح من مجموعة التحميل الزائد. قالب الدالّة الثاني غير مقيّد ولذا تم اختياره، وسنمرّ عبر ‎operator<<(std::ostream&, T)‎، أمّا في حال لم يكن معرَّفًا فسيحدث خطأ فادح في التصريف لمكدّس القالب (template stack) في سطر ‎oss << val‎.

enableifall / enableifany

الإصدار ≥ C++‎ 11

مثال تحفيزي

لدينا في الشيفرة التالية حزمة قالب متغيّرة (variadic template pack) في قائمة معاملات القالب:

template < typename...Args > void func(Args && ...args)
    {
        //... };

لا تعطينا المكتبة القياسية (قبل الإصدار C++‎ 17) أيّ طريقة مباشرة لكتابة enable_if لفرض قيود قاعدة SFINAE على جميع (أو أيٍّ من) المعاملات في ‎Args‎. توفّر C++‎ 17 حلّين لهذه المشكلة، وهما: ‎std::conjunction‎ و ‎std::disjunction‎. انظر المثال التالي: قيود SFINAE على جميع المعامِلات في Args:

template<typename ...Args,
    std::enable_if_t<std::conjunction_v<custom_conditions_v<Args>...>>* = nullptr>
void func(Args &&...args) { //... };

template<typename ...Args,
    std::enable_if_t<std::disjunction_v<custom_conditions_v<Args>...>>* = nullptr>
void func(Args &&...args) { //... };

إذا كنت تعمل بإصدار أقل من C++‎ 17، فهناك العديد من الحلول الممكنة لتحقيق ذلك، أحدها هو استخدام صنف الحالة الأساسية (base-case class) والتخصيصات الجزئية، كما هو مُوضّح في جواب هذا السؤال.

يمكن أيضًا تنفيذ سلوك ‎std::conjunction‎ و ‎std::disjunction‎ بطريقة مباشرة، وسأوضح في المثال التالي، كيفيّة كتابة التنفيذات وسأجمعها مع std::enable_if لإنتاج كُنيتين: ‎enable_if_all‎ و ‎enable_if_any‎، واللّتان تفعلان بالضبط ما يفترض بهما فعله. قد يكون هذا الحلّ أكثر قابلية للتوسيع.

تطبيق ‎enable_if_all‎ و ‎enable_if_any‎

أولاً، سنحاكي ‎std::conjunction‎ و ‎std::disjunction‎ باستخدام ‎seq_and‎ و ‎seq_or‎:

/// C++14 مساعد لاستخدامه في الإصدارات التي تسبق
template<bool B, class T, class F >
using conditional_t = typename std::conditional<B,T,F>::type;
/// Emulate C++17 std::conjunction.
template<bool...> struct seq_or: std::false_type {};
template<bool...> struct seq_and: std::true_type {};
template<bool B1, bool... Bs>
struct seq_or<B1,Bs...>:
    conditional_t<B1,std::true_type,seq_or<Bs...>> {};
template<bool B1, bool... Bs>
struct seq_and<B1,Bs...>:
    conditional_t<B1,seq_and<Bs...>,std::false_type> {};

الآن سيصبح التنفيذ واضحًا:

template < bool...Bs >
    using enable_if_any = std::enable_if<seq_or < Bs... >::value > ;
template < bool...Bs >
    using enable_if_all = std::enable_if<seq_and < Bs... >::value > ;

وأخيرًا بعض المساعِدات:

template < bool...Bs >
    using enable_if_any_t = typename enable_if_any < Bs... >::type;
template < bool...Bs >
    using enable_if_all_t = typename enable_if_all < Bs... >::type;

كيفية الاستخدام

الاستخدام واضح ومباشر: قيود SFINAE على جميع المعامِلات في Args:

template<typename ...Args,
enable_if_all_t<custom_conditions_v<Args>...>* = nullptr>
void func(Args &&...args) { //... };

template<typename ...Args,
enable_if_any_t<custom_conditions_v<Args>...>* = nullptr>
void func(Args &&...args) { //... };

هذا الدرس جزء من سلسلة دروس عن C++‎.

ترجمة -بتصرّف- للفصل Chapter 103: SFINAE (Substitution Failure Is Not An Error)‎ من كتاب C++ Notes for Professionals

آلية RTTI: معلومات الأنواع في وقت التشغيل (Run-Time Type Information)

dynamic_cast

استخدم ‎dynamic_cast<>()‎ كدالة تساعدك على التخفيض النوعي (downcasting) في التسلسل الهرمي للوراثة (الوصف الرئيسي). وإذا كنت بحاجة إلى إجراء بعض الأعمال غير متعددة الأشكال (non-polymorphic) على صنفين مشتقّين ‎B‎ و ‎C‎ عبر الصنف الأب ‎class A‎، فستحتاج إلى كتابة ما يلي:

class A { public: virtual ~A(){} };

class B: public A
{ public: void work4B(){} };

class C: public A
{ public: void work4C(){} };

void non_polymorphic_work(A* ap)
{
    if (B* bp =dynamic_cast<B*>(ap))
        bp->work4B();
    if (C* cp =dynamic_cast<C*>(ap))
        cp->work4C();
}

الكلمة المفتاحية typeid

الكلمة المفتاحية ‎typeid‎ هي عامل أحادي يعطي معلومات حول النوع المُمرّر إليها في وقت التشغيل في حال كان معامَلها (operand) كائنًا من صنف متعدد الأشكال. تعيد ‎typeid‎ قيمةً يسارية من النوع ‎const std::type_info‎، كما تتجاهَل التأهيل عالي المستوى (Top-level cv-qualification).

struct Base
{
    virtual~Base() = default;
};
struct Derived: Base {};
Base *b = new Derived;
assert(typeid(*b) == typeid(Derived {}));    // حسنا

يمكن أيضًا تطبيق ‎typeid‎ على النوع مباشرة، ويتم تجريد مراجع المستوى الأعلى الأولى (first top-level references) في هذه الحالة، ثم يُتجاهَل التأهيل عالي المستوى. ومن ثم يمكن كتابة المثال أعلاه باستخدام ‎typeid(Derived)‎ بدلاً من typeid(Derived{})‎:

assert(typeid(*b) == typeid(Derived {}));    // OK

إذا طُبِّقت ‎typeid‎ على تعبير من غير النوع متعدد الأشكال فلن يُقيَّم المعامَل، أمّا معلومات النوع المُعادة فستخصّ النوع الساكن.

struct Base
{
    // ملاحظة: لا مدمّرات وهمية
};
struct Derived: Base {};
Derived d;
Base &b = d;
assert(typeid(b) == typeid(Base));    // غير مشتق
assert(typeid(std::declval<Base> ()) == typeid(Base));    // لابأس، لأنّه غير مُقيَّم

أسماء الأنواع

تستطيع الحصول على الاسم المعرَّف من قِبل التنفيذ لنوع معيّن في وقت التشغيل باستخدام الدالة التابعة ‎.name()‎ الخاص بالكائن ‎std::type_info‎ المُعاد من قِبل ‎typeid‎.

#include <iostream>
#include <typeinfo>

int main()
{
    int speed = 110;

    std::cout << typeid(speed).name() << '\n';
}

يكون الخرج ما يلي (متعلق بالتنفيذ):

int

كيف تعرّف التحويل الذي ينبغي استخدامه

• استخدم التحويل الديناميكي dynamic_cast لتحويل المؤشّرات/المراجع داخل التسلسل الهرمي للوراثة.

• استخدم التحويل الساكن static_cast لإجراء تحويلات الأنواع العادية.

• استخدم تحويل إعادة التفسير reinterpret_cast لإعادة تفسير أنماط البتات منخفضة المستوى، لكن استخدمه بحذر شديد.

• استخدم التحويل الثابت const_cast للتخلص من الثباتيّة أو التغايرية (const/volatile). تجنّب هذا الخيار ولا تستخدمه إلّا كنت مضطرًّا لاستخدام واجهة برمجية غير صحيحة ثباتيًّا (const-incorrect API).

شطب الأنواع Type Erasure

شطب النوع (Type Erasure) هو مجموعة من التقنيات الهادفة لإنشاء نوع يمكن أن يوفّر واجهة موحّدة للأنواع الأساسية (underlying types)، مع إخفاء معلومات النوع الأساسي عن العميل. وتُعدُّ ‎std::function<R(A...)>‎، التي يمكنها تخزين كائنات قابلة للاستدعاء من مختلف الأنواع، أفضل مثال معروف على شطب الأنواع في C++‎.

std::function للنقل فقط

شطب النوع std::function ينحصر في عدد قليل من العمليات، وأحد الأشياء التي يتطّلّبها الشطب أن تكون القيمة المخزّنة قابلة للنسخ. لكن هذا قد يتسبّب بمشاكل في بعض السياقات، كما في حالة تخزين تعابير لامبدا للمؤشرات الحصريّة (unique ptrs)، وقد يضيف هذا المتطلَّب حِملًا إضافيًا على البرنامج إذا كنت تستخدم ‎std::function‎ في سياق لا يهمّ فيه النسخ، كساحة خيوط (thread pool) مثلًا، حيث توفد (dispatch) المهامّ إلى الخيوط.

الكائن ‎std::packaged_task<Sig>‎ هو كائن قابل للاستدعاء، كما أنه قابل للنقل فقط (move-only)، وتستطيع تخزين std::packaged_task<R(Args...)>‎ في std::packaged_task<void(Args...)>‎، إلا أنّها طريقة بطيئة لإنشاء صنف شطب للنوع (type-erasure class) يكون للنقل فقط (move-only) وقابلا للاستدعاء (callable) في نفس الوقت.

يوضّح المثال التالي كيف يمكنك كتابة نوع ‎std::function‎ بسيط، سنحذف مُنشئ النسخ - copy constructor - (والذي يتضمّن إضافة تابع ‎clone‎ إلى ‎details::task_pimpl<...>‎). سنضعه في فضاء اسم (namespace) إذ سيسمح لنا ذلك بتخصيصه للقيمة المعادة الفارغة void:

template < class Sig>
    struct task;

namespace details
{
    template < class R, class...Args >
        struct task_pimpl
        {
            virtual R invoke(Args && ...args) const = 0;
            virtual~task_pimpl() {};
            virtual
            const std::type_info &target_type() const = 0;
        };
    // store an F.    invoke(Args&&...) calls the f
    template < class F, class R, class...Args >
        struct task_pimpl_impl: task_pimpl<R, Args... >
        {
            F f;
            template < class Fin>
            task_pimpl_impl(Fin && fin): f(std::forward<Fin> (fin)) {}

            virtual R invoke(Args && ...args) const final override
            {
                return f(std::forward<Args> (args)...);
            }

            virtual
            const std::type_info &target_type() const final override
            {
                return typeid(F);
            }
        };

سيتجاهل إصدار void القيمة التي تعيدها f، نتابع …

    template < class F, class...Args >
        struct task_pimpl_impl<F, void, Args... >: task_pimpl<void, Args... >
        {
            F f;
            template < class Fin>
            task_pimpl_impl(Fin && fin): f(std::forward<Fin> (fin)) {}

            virtual void invoke(Args && ...args) const final override
            {
                f(std::forward<Args> (args)...);
            }

            virtual
            const std::type_info &target_type() const final override
            {
                return typeid(F);
            }
        };
};
template < class R, class...Args >
    struct task < R(Args...) >
    {
        // semi-regular:
        task() = default;
        task(task &&) = default;
        // no copy
        private:

هنا ننشئ أسماءً بديلة أو كُنى (aliases) لتحسين مظهر شيفرة sfinae أدناه، …

            template < class F>
            using call_r = std::result_of_t < F
        const &(Args...) > ;
        template < class F>
        using is_task = std::is_same<std::decay_t < F>, task> ;
        public:
            // قابل للاستدعاء F يمكن تدميرها من كائن 
            template < class F,

        class= decltype( (R)(std::declval<call_r<F>>()) ),
        // ليس النوع نفسه
        std::enable_if_t<!is_task<F>{}, int>* = nullptr>
        task(F&& f):m_pImpl( make_pimpl(std::forward<F>(f)) ) {}


        R operator()(Args...args) const
        {
            return m_pImpl->invoke(std::forward<Args> (args)...);
        }

        explicit operator bool() const
        {
            return (bool) m_pImpl;
        }

        void swap(task & o)
        {
            std::swap(m_pImpl, o.m_pImpl);
        }

        template < class F>
        void assign(F && f)
        {
            m_pImpl = make_pimpl(std::forward<F> (f));
        }

        // std::function جزء من واجهة
        const std::type_info &target_type() const
        {
            if (! *this) return typeid(void);
            return m_pImpl->target_type();
        }

        template < class T>
        T* target()
        {
            return target_impl<T> ();
        }

        template < class T>
        const T* target() const
        {
            return target_impl<T> ();
        }

        // nullptr مقارنة مع
        friend bool operator==(std::nullptr_t, task
            const &self)
        {
            return !self;
        }

        friend bool operator==(task
            const &self, std::nullptr_t)
        {
            return !self;
        }

        friend bool operator!=(std::nullptr_t, task
            const &self)
        {
            return !!self;
        }

        friend bool operator!=(task
            const &self, std::nullptr_t)
        {
            return !!self;
        }

        private: template < class T>
            using pimpl_t = details::task_pimpl_impl<T, R, Args... > ;
        template < class F>
        static auto make_pimpl(F && f)
        {
            using dF = std::decay_t<F> ;
            using pImpl_t = pimpl_t<dF> ;
            return std::make_unique<pImpl_t> (std::forward<F> (f));
        }

        std::unique_ptr<details::task_pimpl<R, Args... >> m_pImpl;
        template < class T>
        T* target_impl() const
        {
            return dynamic_cast<pimpl_t<T> *> (m_pImpl.get());
        }
    };