هناك العديد من العقبات والأخطاء التي قد يتعرض لها مطورو لغة البرمجة ++C، يمكن لهذه العقبات أن تصعب عملية البرمجة وترفع تكاليفها، فتعلم قواعد البرمجة ووجود مهارات في لغات البرمجة الأخرى مثل جافا Java وسي شارب #C ليست كافية وحدها للاستفادة الكاملة من إمكانيات لغة ++C وتجنب الأخطاء.

حيث يتطلب إتقان ++C عدة سنوات من الخبرة العملية لتجنب الوقوع في الأخطاء الدقيقة بسبب عدة عوامل متعلقة بطبيعة اللغة، وسنلقي الضوء في هذه المقالة على أهم الأخطاء التي يقع بها مطورو ++C سواء المبتدئون منهم أو الخبراء إن لم يكونوا حذرين في التعامل مع هذه اللغة.

الخطأ 1: الاستخدام الخاطئ للمعاملين new و delete

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

سنلقي الضوء هنا على المثال البسيط التالي:

void SomeMethod()
{
  ClassA *a = new ClassA;
  SomeOtherMethod();      // it can throw an exception
  delete a;
}

إذا أصدر هذا الكود البسيط استثناء فلن يتم حذف الكائن a أبدًا. ففي هذا الكود تنشئ الدالة SomeMethod كائن من الصنف ClassA باستخدام التخصيص الديناميكي للذاكرة new ClassA. بعد ذلك، تستدعي الدالة SomeOtherMethod والتي قد تتسبب في حدوث استثناء أثناء تنفيذها. فإذا وقع هذا الاستثناء قبل تنفيذ delete a، فلن يتم تحرير الكائن `` a من الذاكرة، مما يؤدي إلى ما يعرف بتسريب الذاكرة Memory Leak.

يقدم المثال التالي طريقة أقصر وأكثر أمانًا لتنفيذ هذه المهمة، حيث نستخدم هنا طريقة المؤشر الذكي auto_ptr الذي لم يعد موجودًا في النسخة 11 من لغة البرمجة ++C ولكنه لا يزال يستخدم على نطاق واسع في النسخ القديمة.

ملاحظة: يمكن استبدال المؤشر auto_ptr في النسخة 11 من ++C بالمؤشر unique_ptr أو المؤشر scoped_ptr من خلال المكتبة Boost التي توفر بعض الأدوات المفيدة لإدارة الذاكرة.

void SomeMethod()
{
  std::auto_ptr<ClassA> a(new ClassA); // deprecated, please check the text
  SomeOtherMethod();      // it can throw an exception
}

هنا سيحذف الكائن a مباشرة بمجرد انتهاء البرنامج من تنفيذ الكود الموجود بين قوسين.

هذا المثال هو الأبسط للمشكلات التي يمكن تحدث في ++C، فهناك العديد من الأمثلة التي يجب فيها أن يتم الحذف في مكان آخر (مثال: دالة خارجية أو خيط thread آخر)، لذلك لا ينصح أبدًا باستخدام المعاملين new وdelete مع بعضهما البعض وإنما يجب استخدام المؤشرات الذكية بدلًا من ذلك.

الخطأ 2: عدم استخدام الهادم الوهمي Virtual Destructor

هذا من الأخطاء الأكثر شيوعًا التي تؤدي إلى استهلاك حجم الذاكرة داخل الأصناف المشتقة من أصناف أخرى، فعند إنشاء صنف أساسي base class وصنف مشتق derived class يحتوي على ذاكرة مخصصة، فمن الضروري أن تكون دالة الهدم في الصنف الأساسي وهمية virtual لأن ++C تعتمد على نوع المؤشر عند استدعاء الدوال، وبالتالي إذا حذفنا كائنًا من خلال مؤشر إلى صنف أساسي لا يحتوي على دالة هادم وهمية فلن تُستدعى دالة الهدم للصنف المشتق عند حذف الكائن. وهذا يؤدي إلى عدم تحرير الذاكرة بشكل صحيح وظهور مشكلة تسرب الذاكرة.

هناك بعض الحالات التي لا يرغب فيها بوجود دالة الهدم الوهمية virtual destructor، على سبيل المثال عندما يكون الصنف لا يقبل الوراثة وحجمه وأداؤه في غاية الأهمية، حيث تضيف دالة الهدم الوهمية -أو أي دالة وهمية أخرى- بيانات إضافية لبنية الصنف بمعنى أنها تضيف مؤشر إلى جدول وهمي مما يؤدي إلى زيادة حجم الصنف class.

ولما كان من الممكن توريث الأصناف في معظم الحالات -حتى وإن لم نكن نريد توريثها- لذا يفضل أن يضيف المبرمج دالة الهدم الوهمية عند التصريح عن الصنف class. من ناحية أخرى، في حال عدم رغبة المبرمج بإضافة أي دوال وهمية للكود لتعزيز أداء البرنامج فيتوجب عليه وضع ملاحظة عند التصريح عن الصنف تخبر باقي المطورين بأن هذا الصنف يجب أن لا يوسع عن طريق الوراثة منه. ومن أفضل الخيارات لتجنب الوقوع في هذه المشكلة هو استخدام بيئة التطوير المتكاملة IDE التي تدعم إنشاء دالة هدم افتراضية أثناء عملية إنشاء الصنف.

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

class MyString : public std::string
{
    ~MyString() {
    // ...
}
};

int main()
{
    std::string *s = new MyString();
    delete s; // May not invoke the destructor defined in MyString
}

لتجنب الوقوع في مثل هذه المشكلات في لغة ++C، يجب على المطورين استخدام الوراثة الخاصة private inheritance والتي تعتبر الطريقة الأكثر أمانًا لإعادة استخدام الأصناف أو القوالب من المكتبة الأساسية القياسية.

الخطأ 3: حذف مصفوفة باستخدام delete أو باستخدام المؤشر الذكي

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

فمن المهم جدًا تحرير الذاكرة المخصصة لهذه المصفوفات بعد الانتهاء من استخدامها، ولكن المشكلة الكبيرة في لغة ++C هي أنها تتطلب عامل الحذف ذي الأقواس المربعة delete[] والذي ينساه المبرمج غالبًأ ، وعامل الحذف لن يقوم بحذف الذاكرة المخصصة للمصفوفة فحسب وإنما سيستدعي في البداية تابع الهدم destructor لجميع الكائنات أو العناصر ضمن المصفوفة.

بالمقابل فإن استخدام أمر الحذف بدون أقواس مربعة [] أمر غير صحيح خاصة بالنسبة للأنواع الأساسية الأولية على الرغم من عدم وجود تابع هدم لهذه الأنواع، لذا يجب الانتباه لاستخدام الأقواس لضمان تحرير الذاكرة بشكل صحيح.

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

إن استخدام المؤشرات الذكية مثل auto_ptr و<unique_ptr<T و shared_ptr أمر غير صحيح أيضًا فعندما يخرج المؤشر الذكي خارج المجال فإنه سيستدعي عامل الحذف بدون أقواس مما يؤدي إلى حدوث المشكلة نفسها التي شرحناها في الفقرة السابقة.

عندما يكون استخدام المؤشر الذكي للمصفوفة أمرًا مطلوبًا، توجب على البرنامج استخدام الصنف scoped_array أو الصنف shared_array من المكتبة Boost أو الصنف <[]unique_ptr<T بالتحديد.

إذا كنا غير محتاجين لاستخدام تقنية إدارة الذاكرة المسماة عد المراجع reference counting عند التعامل مع المصفوفات، فإن الحل الأفضل في هذه الحالة هو استخدام متجهات مكتبة القوالب المعيارية STL بدلًا عنها لأن تلك المتجهات لا تتعامل مع تحرير الذاكرة فحسب وإنما تحتوي على وظائف إضافية مهمة لا مجال لذكرها الآن.

الخطأ 4: إعادة مرجع إلى كائن محلي داخل دالة

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

لنأخذ المثال التالي والذي يريد المبرمج من خلاله إدخال بعض التحسينات على الكود وتجنب عمليات النسخ غير الضرورية:

Complex& SumComplex(const Complex& a, const Complex& b)
{
    Complex result;
    …..
    return result;
}

Complex& sum = SumComplex(a, b);

في هذه الحالة سيشير الكائن sum إلى الكائن المحلي result وستعيد الدالة الكائن sum، ولكن السؤال المطروح: أين سيتواجد الكائن result بعد تنفيذ الدالة SumComplex؟.

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

هناك حالات يمكنك فيها الاستفادة من تقنية تحسين القيمة المعادة Return Value Optimization أو اختصارًا RVO وهي تقنية يستخدمها المصرف compiler لمنع حدوث مشكلات تتعلق بأداء البرنامج:

Complex SumComplex(const Complex& a, const Complex& b)
{
     return Complex(a.real + b.real, a.imaginar + b.imaginar);
}

Complex sum = SumComplex(a, b);

بالنسبة للنسخ الحديثة من المصرفات compilers، عندما تتضمن عبارة إرجاع قيمة باني الكائن constructor فإن المصرف سيعمل على تحسين الكود لقائيًا لتجنب عمليات النسخ الزائدة. فبدلاً من إنشاء كائن مؤقت أولاً داخل الدالة ثم نسخه لاحقًا إلى المكان النهائي مثل المتغير sum في الكود أعلاه، يعمل المترجم على إنشاء الكائن النهائي مباشرة في موقعه المطلوب. هذا يعني أن sum سيبنى مباشرة باستخدام القيم المرجعة من الدالة دون الحاجة إلى كائن وسيط أو عملية نسخ إضافية مما يحسن الأداء ويوفر الذاكرة.

الخطأ 5: استخدام مرجع لمورد أو مصدر محذوف

تحدث مثل هذه الأخطاء في لغة ++C بشكل كبير وخصوصًا في التطبيقات متعددة الخيوط multithread، وللتوضيح سنأخذ الكود التالي:

الخيط رقم 1:

Connection& connection= connections.GetConnection(connectionId);
// ...

الخيط رقم 2:

connections.DeleteConnection(connectionId);
// …

الخيط رقم 1:

connection.send(data);

في هذا المثال، ستكون نتيجة التنفيذ غير متوقعة في حال استخدم كلا الخيطين نفس المعرف connection ID، وغالبًا ما يجد المطور صعوبة في إيجاد سبب وقوع أخطاء انتهاك الوصول access violation هنا.

ففي مثل هذه الحالات وعند وصول عدة خيوط إلى نفس المصدر، سيكون من المخاطرة الاحتفاظ بمؤشرات أو مراجع لهذا المورد لأنه يمكن لمؤشر آخر أن يحذفه، ولتجنب هذا علينا استخدام المؤشرات الذكية مع تقنية العد المرجعي والتي تعتبر الطريقة الأكثر أمانًا مثل المؤشر shared_ptr من المكتبة Boost، إذ يستخدم هذا النوع من المؤشرات العمليات الذرية atomic operations لزيادة أو إنقاص عداد المراجع reference counter مما يجعله آمنًا للاستخدام في بيئة متعددة الخيوط.

ملاحظة: يتعقب عداد المراجع في البرمجة عدد المراجع لكائن معين في الذاكرة فكلما تم إنشاء مرجع جديد إلى الكائن يزداد بقيمة 1 وكلما تم حذف مرجع ينقص بقيمة 1.

الخطأ 6: السماح برمي توابع الهدم لاستثناءات

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

class A
{
public:
   A(){}
   ~A()
   {
      writeToLog(); // could cause an exception to be thrown
   }
};

// …

try
{
   A a1;        
   A a2;        
}
catch (std::exception& e)
{
   std::cout << "exception caught";
}

إذا حدث الاستثناء في المثال السابق مرتين في نفس الوقت كما في حالة تدمير كلا الكائنين فإن العبارة catch لن تنفذ ابدًا، والسبب في ذلك هو أنه عند وجود استثنائين يعملان على التوازي (في نفس الوقت) سواء كانا من نفس النوع أو من نوعين مختلفين فإن بيئة تشغيل اللغة ++C لن تكون قادرة على تحديد طريقة التعامل معهما، ونتيجة لذلك تستدعي بيئة التشغيل دالة الإنهاء abort مما يؤدي إلى تعطل البرنامج.

تنص القاعدة العامة في هذه الحالة على عدم السماح برمي الاستثناءات من توابع الهدم في البرنامج حتى لو لم تبدو التعليمات البرمجية جذابة من الناحية الجمالية، فمن المهم هنا التعامل مع الاستثناءات المحتملة داخل تابع الهدم لمنعها من الانتشار بشكل أكبر

try
   {    
      writeToLog(); // could cause an exception to be thrown
   }
   catch (...) {}

الخطأ 7: استخدام المؤشر auto_ptr بشكل خاطئ

توقف دعم المؤشر أو القالب auto_ptr منذ صدور النسخة 11 من لغة البرمجة ++C وذلك لعدة أسباب (لا داعي لذكرها الآن)، ولكنه لا يزال يستخدم على نطاق واسع لأن معظم المشاريع المطورية سابقًا تعمل في النسخة 98++C.

يتمتع القالب auto_ptr بميزة مهمة قد لا يعرفها الكثير من مطوري ++C، وهي أنه عند نسخ كائن من نوع auto_ptr، تنتقل ملكيته من الكائن الأصلي إلى الكائن الجديد. هذا يعني أن الكائن الأصلي يصبح فارغًا ولا يمكن الوصول إلى بياناته أو استخدامه بعد ذلك. إذا لم تستخدم هذا القالب بحذر وبطريقة احترافية، قد يتسبب ذلك في مشكلات كبيرة. للتوضيح ألقِ نظرة على الكود التالي:

auto_ptr<ClassA> a(new ClassA); // deprecated, please check the text
auto_ptr<ClassA> b = a;
a->SomeMethod();    // will result in access violation error

سيؤدي الكود السابق إلى خطأ انتهاك الوصول، حيث يحتوي الكائن b فقط على مؤشر للكائن Class A بينما سيكون الكائن a فارغًا، وستؤدي محاولة الوصول إلى الكائن a إلى ظهور خطأ انتهاك الوصول.

توجد عدة طرق لاستخدام الكائن auto_ptr بشكل خاطئ لذا يجب على المطور تذكر الأمور الأربعة التالية: 1.يجب عدم استخدام المؤشر auto_ptr ضمن حاويات مكتبة القوالب المعيارية STL، لأن نسخ الحاويات سيؤدي إلى وضع بيانات غير صحيحة في الحاويات الأصلية. بالإضافة إلى ذلك، قد تتسبب بعض خوارزميات مكتبة القوالب المعيارية في حدوث أخطاء في المؤشرات الخاصة بـ auto_ptr.

2. عدم استخدام المؤشر auto_prt كوسيط دالة لأن هذا سيؤدي إلى نسخ القيمة وستصبح القيمة الأصلية الممررة إلى الوسيط خاطئة بعد استدعاء الدالة.

3. إذا استخدم المبرمج المؤشر auto_ptr ضمن بيانات الصنف، يجب عليه التأكد من أن عملية النسخ داخل تابع البناء constructor تنجز بشكل صحيح وذلك إما من خلال إنشاء نسخة صحيحة داخل منشئ النسخة copy constructor وعامل الإسناد assignment operator أو عدم السماح بتطبيق هذه العمليات عن طريق جعلها private مما يمنع النسخ غير المقصود للبيانات.

4. استخدام المؤشرات الذكية الأحدث من المؤشر auto_ptr إذا كان الأمر ممكنًا.

الخطأ 8: استخدام المؤشرات والمراجع غير الصالحة

هذا الخطأ شائع جدًا حتى أن يمكننا تأليف كتاب كامل حوله، حيث تحتوي كل حاوية من مكتبة القوالب المعيارية STL على بعض الحالات الخاصة التي تبطل عمل المؤشرات والمراجع، ومن المهم لكل مبرمج أن يكون على علم بهذه الحالات عند استخدام المؤشرات والمراجع.

يمكن أن تحدث إحدى هذه المشكلات بشكل متكرر في بيئات التطوير التي تمتلك خاصية الخيوط المتعددة multiple threads، ولذلك من الضروري اعتماد آليات المزامنة synchronization mechanisms لمنع حدوث هذه المشكلة.

سنلقي نظرة على الكود التالي الذي يستخدم متجه vector لتخزين السلاسل النصية:

vector<string> v;
v.push_back(“string1”);
string& s1 = v[0];     // assign a reference to the 1st element
vector<string>::iterator iter = v.begin();    // assign an iterator to the 1st element
v.push_back(“string2”);
cout << s1;     // access to a reference of the 1st element
cout << *iter;  // access to an iterator of the 1st element

للوهلة الأولى ومن وجهة نظر منطقية يتبين لنا أن الكود صحيح ولا يوجد فيه مشكلات، ولكن عند إضافة عنصر ثاني إلى المتجه فسيحتاج لإعادة توضع الذاكرة وهذا يمكن أن يجعل كل من مؤشر ومرجع المتجه غير صالحين (يشيران إلى قيمة أخرى)، ونتيجة لذلك يمكن أن تتسبب محاولة الوصول لهم في السطرين الأخيرين من الكود بعد إضافة العنصر الجديد إلى حدوث خطأ انتهاك الوصول Access Violation لأن المؤشر والمرجع لم يعودا يشيران إلى الأماكن الصحيحة في الذاكرة.

الخطأ 9: تمرير كائن عن طريق القيمة

من المعروف لدى معظم المبرمجين أن عملية تمرير الكائن عن طريق القيمة  by value (وهي عبارة عن أخذ نسخة من الكائن وتمريرها إلى الدالة) فكرة سيئة فقد يكون لها تأثير سلبي على أداء البرنامج، ومع ذلك نجدهم يؤجلون معالجة هذا الموضوع إلى وقت لاحق لتجنب كتابة كود إضافي مما يؤدي تقليل فاعلية الكود المكتوب وجعله يتسبب في لمشكلات غير متوقعة

class A
{
public:
   virtual std::string GetName() const {return "A";}
    …
};

class B: public A
{
public:
   virtual std::string GetName() const {return "B";}
   ...
};

void func1(A a)
{
   std::string name = a.GetName();
   ...
}

B b;
func1(b);

يصرّف هذا الكود بشكل صحيح وبدون مشكلات، ومع ذلك فإن الدالة func1 ستنسخ جزء من الكائن b الذي ينتمي إلى الصنف A ضمن الكائن a عند استدعائها، وهذا ما يعرف باسم مشكلة التقطيع slicing problem.

بالنتيجة سوف يستدعي البرنامج عند تنفيذه التابع من الصنف A بدلًا من الصنف B، ويعتبر هذا سلوكًا غير متوقع للشخص الذي يستدعي الدالة.

تحدث مشكلة أخرى مشابهة عند محاولة التقاط catch الاستثناء كما في المثال التالي:

class ExceptionA: public std::exception;
class ExceptionB: public ExceptionA;

try
{
   func2(); // can throw an ExceptionB exception
}
catch (ExceptionA ex)
{
    writeToLog(ex.GetDescription()); 
    throw;
}

في المثال السابق، عندما تطلق الدالة func2 استثناء من النوع ExceptionB، سيتلقط الاستثناء ويعالج في كتلة try/catch. ولكن بسبب مشكلة النسخ، ينسخ الاستثناء إلى كائن من النوع الأساسي ExceptionA بدلاً من النوع الفرعي ExceptionB. هذا يؤدي إلى فقدان المعلومات الخاصة بنوع الاستثناء الفرعي مما يتسبب في استدعاء تابع غير صحيح. وعند إعادة رمي الاستثناء باستخدام throw، سيرمى استثناء من النوع ExceptionA بدلاً من النوع الأصلي ExceptionB.

النصيحة في نهاية هذه الفكرة هي يجب على المبرمج تمرير الكائنات حسب المرجع reference وليس حسب القيمة وأن يلتقط الاستثناءات بالمرجع & وليس بالقيمة. هذا يحافظ على نوع الاستثناء الفرعي ويمنع المشاكل التي تحدث عند فقدان التفاصيل الخاصة بالاستثناء.

الخطأ 10: استخدام التحويلات المعرفة من المستخدم عن طريق توابع البناء وعوامل التحويل

تشير التحويلات المخصصة أو المعرفة من قبل المستخدم في ++C إلى إمكانية تعريف تحويلات مخصصة بين أنواع البيانات المختلفة، يمكن إنشاء هذه التحويلات باستخدام توابع البناء constructors وعوامل التحويل conversion operators في الأصناف.

وبشكل عام فإن هذا النوع من التحويلات يمنح المبرمج تحكمًا أكبر في طريقة تحويل الكائنات من أنواع مختلفة في كود ++C، وهو مفيد جدًا في بعض الأحيان لكنه قد يؤدي إلى تحويلات غير متوقعة يكون من الصعب تحديد موقعها. لنفترض أن أحدهم أنشأ مكتبة تحتوي على صنف string فيه دالتا بناء لإنشاء السلاسل النصية الأولى وسيطها عدد والثانية وسيطها محارف كما يلي:

class String
{
public:
   String(int n);
   String(const char *s);
   ….
}

نستطيع من خلال التابع الأول إنشاء سلسلة نصية طولها n، ونستطيع من خلال التابع الثاني إنشاء سلسلة نصية تحتوي على الحروف المدخلة من المستخدم، ولكن تبدأ المشكلة عندما يكون لدينا كود مثل الكود التالي:

String s1 = 123;
String s2 = ‘abc’;

في المثال الأول أعلاه، ستستدعى دالة البناء الأولى التي تنشئ سلسلة نصية s1 حجمها هو 123 محرف وليس سلسلة تحتوي على الأحرف 123، أما المثال الثاني فيحوي على علامات اقتباس مفردة بدلًا من علامات اقتباس مزدوجة والتي ستؤدي إلى استدعاء دالة البناء الأولى أيضًا وإنشاء سلسلة نصية ذات حجم كبير جدًا (لن يفهم 'abc' كسلسلة نصية).

توضيح عند استخدام علامات الاقتباس الفردية يعامل كل حرف على أنه قيمة محرفية character literal، وتمثل قيمة كل حرف بناءً على ترميز الحرف وبالتالي ستحول 'abc' إلى قيمة عددية باستخدام قيمة ASCII المقابلة لكل حرف في السلسلة وتدمج معًا لتكوين قيمة عددية كبيرة الحجم.

تعتبر هذه الأمثلة بسيطة جدًا، وهناك العديد من الأمثلة الأكثر تعقيدًا التي تؤدي إلى الالتباس وحدوث نتائج غير متوقعة التي قد يكون من الصعب تحديدها أو التنبؤ بها.

توجد قاعدتان بشكل عام لتجنب حدوث هذه المشكلات:

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

الخلاصة

تعتبر لغة ++C لغة قوية جدًا، وفي الحقيقة فإن العديد من التطبيقات التي نستخدمها يوميًا مبنية على لغة ++C. وبالرغم من أن لغة البرمجة ++C توفر مرونة كبيرة للمطورين من خلال ما توفره من ميزات متطورة وباعتبارها من لغات البرمجة كائنية التوجه، إلا أن هذه الميزات المتقدمة يمكن أن تسبب بعض الالتباس والإحباط لبعض المطورين إذا لم تستخدم بشكل صحيح واحترافي. نتمنى لكم الاستفادة الجيدة من هذا المقال، وفي حال كان لديكم أي تساؤل يمكن تركه في قسم التعليقات أسفل المقال أو كتابته في قسم الأسئلة والأجوبة في أكاديمية حسوب.
ترجمة وبتصرف للمقال Top 10 Most Common C++ Mistakes That Developers Make لكاتبه Vatroslav Bodrozic

اقرأ أيضًا

• تحسين الشيفرات المكتوبة بلغة Cpp وتشخيصها
• أنظمة التصريف المستخدمة لبناء البرامج المكتوبة بلغة ++C وأهم أخطاء عملية البناء
• قواعد البرمجة ببساطة للمبتدئين
• الأخطاء العشرة الأكثر شيوعًا في شيفرة PHP
• الأخطاء العشرة الأكثر شيوعًا في شيفرة بايثون Python

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

هناك الكثير من المقالات التي تقارن بين المميزات التقنية للغتي C++‎‎ وجافا، ولكنها لا توضح لك بشكل دقيق ما هي الجوانب التي ستؤثر بها هذه الاختلافات، على سبيل المثال، لا تدعم لغة جافا الوراثة المتعددة بينما تدعمها لغة C++‎، حسنًا ماذا يعني ذلك لي كمطور؟ وهل هذا أمر جيد أم لا؟ لماذا يعتبر البعض بأن هذه ميزة في جافا، بينما يعتبرها آخرون مشكلة.

دعنا نستكشف كافة الحالات التي يجب على المطورين فيها اختيار لغة C++‎‎ أو جافا أو ربما لغة أخرى في تطوير التطبيقات، ولماذا يعد اختيار اللغة الصحيحة أمرًا مهمًا لنجاح مشروعك البرمجي.

الفروقات الأساسية بين C++‎‎ وجافا: بناء اللغة والنظام البيئي

أُُطلِقت لغة C++‎‎ عام 1985 كواجهة أمامية للغة سي C فهي تستخدم الكثير من مفاهيم وبنية لغة C، ولكنها أيضًا تضيف ميزات جديدة وتحسينات عليها، وهذا يشبه إلى حد ما طريقة ترجمة لغة TypeScript إلى جافا سكريبت JavaScript . عادةً ما تقوم مترجمات C++‎‎ الحديثة بترجمة أكواد C++‎‎ إلى لغة الآلة الأصلية، وعلى الرغم من أن البعض يرى أن مترجمات C++‎‎ تقلل من قابلية التنقل بين المنصات، وتتطلب إعادة بناء البرامج للتكيف مع المعماريات الحديثة للحواسيب، إلا أن كود C++‎‎ يعمل على جميع منصات المعالجات تقريبًا.

أما لغة جافا فقد صدرت لأول مرة في عام 1995، وهي تتميز بأنها لا تترجم مباشرةً إلى لغة الآلة الأصلية Native Machine Code، بل تترجم بدلاً من ذلك إلى لغة وسيطة تسمى شيفرة البايت bytecode، وهي لغة ذات تمثيل ثنائي مخصصة للعمل على آلة جافا الافتراضية JVM أي بعبارة أخرى، يحتاج مترجم جافا الذي يترجم كود لغة جافا إلى كود يفهمه الحاسوب إلى ملف تشغيلي أصيل خاص بكل منصة أو نظام التشغيل كي يعمل بشكل صحيح. لذا، تختلف جافا عن بعض لغات البرمجة الأخرى من حيث أن كودها المصدري لا يتحول مباشرة إلى برنامج قابل للتشغيل بل يحول إلى كود البايت أولًا والذي يحتاج تنفيذه لبرنامج آخر يسمى آلة جافا الافتراضية.

وتصنف كل من لغة C++‎‎ و جافا بأنها من عائلة اللغات الشبيهة بلغة سي C، حيث أنهما تشبهان لغة C بشكل عام في تراكيبها اللغوية وبنية التعليمات البرمجية، لكن يكمن الفرق الأبرز بينما في البيئة التشغيليلة الخاصة بكل لغة، حيث يمكن للغة C++‎‎ استدعاء المكتبات المستندة إلى C أو ++C، أو استدعاء واجهة برمجة التطبيقات API لنظام التشغيل بسهولة كبيرة، أما لغة جافا فهي ملاءمةً بشكل أفضل للمكتبات المعتمدة على لغة جافا، ويمكن الوصول إلى مكتبات C في جافا باستخدام واجهة برمجة التطبيقاتJava Native Interface أو اختصارًا JNI، لكن هذا قد يتسبب في وقوع بعض الأخطاء ويتطلب كتابة بعض أكواد C أو ++C، كما تتفاعل لغة C++‎‎ مع الأجهزة بسهولة أكبر من لغة جافا لكونها أقرب للعتاد وتعد أقرب إلى لغات البرمجة منخفضة المستوى.

الفروقات التفصيلية بين لغة C++‎‎ وجافا: الأنواع المعمعة وإدارة الذاكرة وغيرها

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

وبما أن اختيار اللغة الأنسب قد لا يكون واضحًا بالنسبة لبعض المشاريع، لذلك دعونا نقارن بين اللغتين بتفصيل أكبر من خلال الجدول التالي:

إضافة إلى الميزات التي قارنها في الجدول أعلاه، سنركز أيضًا على ميزات أخرى مثل البرمجة كائنية التوجه OOP مثل الوراثة المتعددة multiple inheritance، والأنواع المعممة generics، والقوالب templates، والانعكاس reflection. فكلا اللغتين مثلًا تدعمان البرمجة كائنية التوجه مع فرق بسيط بينهما حيث تفرض لغة جافا استخدام نموذج البرمجة كائنية التوجه، بينما تدعم لغة C++‎‎ البرمجة كائنية التوجه إلى جانب نماذج برمجة أخرى.

الوراثة المتعددة

الوراثة هي أحد مبادئ البرمجة كائنية التوجه وهي تمكن صنف ابن child class من وراثة الواصفات attributes والتوابع methods من صنف أب parent class. وأحد الأمثلة القياسية على مبدأ الوراثة هو صنف المستطيل Rectangle الذي يرث من صنف الشكل Shape الأكثر عمومية:

// Note that we are in a C++‎‎ file

class Shape {

  // Position

  int x, y;

 public:

  // The child class must override this pure virtual function

  virtual void draw() = 0;

};



class Rectangle: public Shape {

  // Width and height

  int w, h;

 public:

  void draw();

};

تحدث الوراثة المتعددة عندما يرث صنف ابن من عدة أصناف آباء بذات الوقت. فيما يلي مثال يستخدم صنف المستطيل Rectangle وصنف الشكل Shape وصنف إضافي Clickable:

// Not recommended

class Shape {...};

class Rectangle: public Shape {...};

class Clickable {

  int xClick, yClick;

 public:

  virtual void click() = 0;

};


class ClickableRectangle: public Rectangle, public Clickable {

  void click();

};

لدينا في هذه الحالة صنفان أساسيان هما صنف الشكل Shape (الذي يمثل الصنف الأساسي أو الصنف الأب للمستطيل Rectangle) والصنف الأساسي Clickable والصنف ClickableRectangle الذي يرث من كل من الصنفين السابقين ويملك خصائص نوعي الكائنات التي يولدها كل صنف. تدعم لغة C++‎‎ الوراثة المتعددة، بينما لا تدعم لغة جافا هذه الميزة، وتعد ميزة الوراثة المتعددة مفيدة في بعض حالات المحددة مثل:

• إنشاء لغة تخصصية Domain-Specific Language أواختصارًا DSL للعمل في مجال معين ولحل مشكلة مخصصة.
• إجراء حسابات معقدة في وقت تصريف البرنامج كما في تطبيقات الزمن الحقيقي.
• تحسين سلامة المشروع البرمجي وضمان أمنه بطرق لا يمكن تحقيقها في لغة جافا.

ومع ذلك، يُنصح عمومًا بعدم استخدام الوراثة المتعددة إلا عند الضرورة لكونها قد تعقد الكود البرمجي.

الأنواع المعممة والقوالب

تعمل الإصدارات المعممة Generics للأصناف مع أي نوع من أنواع البيانات وهي تسهل إعادة استخدام الكود البرمجي، وتدعم لغة جافا هذه الميزة عن طريق الأنواع المعممة في حين تدعم لغة C++‎‎ هذه الميزة عن طريق القوالب templates، ولكن مرونة التعامل مع قوالب C++‎‎ تجعل عملية البرمجة أكثر أمنًا وقوة. حيث يمكن لمترجمات C++‎‎ إنشاء أصناف أو وظائف مخصصة جديدة في كل مرة تستخدم فيها أنواعًا مختلفة مع القالب، كما يمكن لقوالب C++‎‎ استدعاء وظائف أو دوال مخصصة بناءً على أنواع وسطاء الدالة، مما يسمح بتخصيص شيفرات مخصصة لأنواع بيانات معينة بدلًا من إنشاء إصدار واحد يناسب جميع أنواع البيانات، يطلق على هذه الميزة اسم تخصيص القالب template specialization.

لا تملك لغة جافا ميزة مكافئة لهذه الميزة. بل على العكس تمامًا عند استخدام الأنواع المعممة generics في لغة جافا، تنشئ مترجمات لغة جافا كائنات عامة دون أنواع محددة من خلال عملية تسمى شطب النوع type erasure. وتجري عملية التحقق من النوع أثناء عملية الترجمة، ولكن لا يمكن للمبرمجين تعديل سلوك صنف أو تابع عام بناءً على نوع وسطائه.

وكي تتمكن من فهم هذا الأمر بشكل أفضل، انظر سريعًا على الدالة العامة التالية format:
std::string format(std::string fmt, T1 item1, T2 item2)
تستخدم هذه الدالة قالب template<class T1, class T2>‎‎ من مكتبة C++‎‎ تم إنشاؤها:

std::string firstParameter = "A string";
int secondParameter = 123;
// Format printed output as an eight-character-wide string and a hexadecimal value
format("%8s %x", firstParameter, secondParameter);
// Format printed output as two eight-character-wide strings
format("%8s %8s", firstParameter, secondParameter);

تنشأ الدالة العامة format في لغة C++‎‎ على النحو التالي (لاحظ أننا حددنا نوع وسطاء الدالة ليكون نص string ثم عدد صحيح int)

std::string format(std::string fmt, std::string item1, int item2)

بينما تنشأ هذه الدالة في لغة جافا دون تحديد أنواع الكائنات string و int الخاصة بوسطاء الدالةitem1 و item2 وفي هذه الحالة، يعرف القالب في لغة C++‎‎ أن آخر معامل مرسل هنا هو عدد صحيح int، وبالتالي يمكنه إجراء عملية تحويله لنص std::to_string المطلوب في الاستدعاء الثاني للدالة format.

وبدون استخدام القوالب، قد تؤدي عبارة printf في لغة C++‎‎ والتي تحاول طباعة رقم على هيئة سلسلة نصية كما في الاستدعاء الثاني للدالة formatفي الكود السابق إلى سلوك غير محدد وقد تتسبب في تعطل التطبيق أو طباعة قيم غير صحيحة. من ناحية أخرى،ستكون الدالة في جافا قادرة على التعامل مع الرقم كنص في الاستدعاء الأول، ولكن لن تنسقه على هيئة قيمة ست عشرية مباشرةً.

وعلى الرغم من بساطة هذا المثال، لكنه يوضح قدرة لغة C++‎‎ على تعريف واختيار قالب مخصص للتعامل مع أي كائن من الصنف بشكل ديناميكي دون الحاجة لتعديل الصنف أو تعديل كود الدالة format، ويمكنك الحصول على نفس النتيجة في لغة جافا باستخدام ميزة تسمى الانعكاس reflection كبديل على استخدام الأنواع المعممة generics، ولكن هذه الطريقة أقل مرونة وأكثر عرضة للأخطاء.

الانعكاس Reflection

تمكنك لغة البرمجة جافا من معرفة واستكشاف كافة تفاصيل بنية الكائن (في وقت التشغيل)، حيث يمكنك معرفة ما هي الأعضاء المتاحة في صنف أو نوع صنف معين. وتُسمى هذه الميزة الانعكاس Reflection لكونها تشبه رفع مرآة أمام الكائن لرؤية كل ما يوجد بداخله.

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

إدارة الذاكرة

تختلف لغتا جافا C++‎ كذلك في الأسلوب المتبع في إدارة الذاكرة والتي تتبع عادة أحد طريقتين رئيسيتين الأولى هي الطريقة اليدوية التي يتوجب فيها على المطورين تتبع الذاكرة وتحريرها يدويًا، والطريقة الثانية هي الطريقة الآلية ، حيث يقوم البرنامج بتتبع ومراقبة الكائنات التي لا تزال قيد الاستخدام في الذاكرة، فإذا لم يعد أي كائن قيد الاستخدام، سيعتبر قمامة ويمكن في هذه الحالة إعادة استخدام الذاكرة التي كان يحجزه ويستخدمها، ويسمى هذا الأسلوب في إدارة الذاكرة جمع القمامة أو كنس البيانات المهملة garbage collection.

تستخدم لغة جافا هذا الأسلوب الذي يمكنها من إدارة الذاكرة بسهولة أكبر من الطريقة اليدوية، كما أنه يساعد في منع وقوع أخطاء تحرير الذاكرة التي تسهم غالبًا في حدوث ثغرات أمنية . من ناحية أخرى لا توفر لغة C++‎‎ طريقة إدارة الذاكرة الآلية بشكل مدمج لكنها تدعم نوعًا من أنواع كنس البيانات يطلق عليه اسم المؤشرات الذكية smart pointers حيث تستخدم المؤشرات الذكية أسلوبًا يسمى عدّ المراجع وهي طريقة آمنة وفعالة في حال استخدامها بشكل صحيح، كما تقدم لغة C++‎‎ أيضًا مفهوم الهودام destructors التي تقوم بتنظيف أو تحرير الموارد المخصصة للكائن عن حذفه من الذاكرة.

وتقدم لغة جافا تخصيص الذاكرة بالطريقة الآلية وفق أسلوب يسمى تخصيص الذاكرة المعتمد على الكومة heap allocation (باستخدام الدالة new أو delete أو الدالة malloc الأقدم التي أتت من لغة C) وتخصيص الذاكرة المعتمد على المكدس stack allocation. ويمكن القول بأن تخصيص الذاكرة المعتمد على المكدس أسرع وأكثر أمانًا من تخصيص الذاكرة المعتمد على الكومة، لأن المكدس هو بنية بيانات خطية في حين أن الكومة هو بينة بيانات شجرية، لذا فإن أسلوب ذاكرة المكدس أسهل بكثير من ناحية التعامل مع تخصيص وتحرير الذاكرة.

وهناك أيضًا ميزة أخرى لصالح لغة C++‎‎ تتعلق بتخصيص الذاكرة بالاعتماد على المكدس وهي استخدام تقنية برمجية معروفة باسم Resource Acquisition Is Initialization أو اختصارًا RAII أي أن الحصول على المورد يجب أن يحدث عند إنشاء وتهيئة الكائن، وتربط الموارد مثل المراجع references بدورة حياة الكائن الذي يتحكم فيها، وتحذف أو تحرر في نهاية دورة حياة هذا الكائن.

يُحرر مرجع المؤشر الذكي المشار إليه في أعلى الدالة تلقائيًا عند الخروج من الدالة. كما تُحرر الذاكرة المرتبطة به إذا كان هذا هو المرجع الأخير إلى المؤشر الذكي. وبهذه الطريقة تعمل المؤشرات الذكية في C++‎‎ دون الحاجة إلى تحرير المراجع يدويًا، وعلى الرغم من أن لغة جافا تتبع طريقة مشابهًا لهذا الأسلوب في تحرير الذاكرة، إلا أن الأمور تنجز بطريقة أصعب من تقنية تخصيص المورد عند إنشاء الكائن RAII المستخدمة في لغة C++‎‎ خاصةً إذا كنت بحاجة إلى إنشاء عدة موارد في نفس كتلة التعليمات البرمجية.

الأداء في وقت التشغيل

يدل هذا المفهوم على مدى سرعة تشغيل البرنامج وفي هذا الصدد تملك لغة جافا أداء تشغيل جيد، ولكن تظل لغة C++‎‎ أعلى منها في الأداء لأن إدارة الذاكرة اليدوية أسرع من تقنية جمع القمامة. وبالرغم من ذلك يمكن أن تتفوق لغة جافا في الأداء على C++‎‎ وذلك في حالات خاصة معينة بسبب ميزة الترجمة اللحظية للغة Just-In-Time أو اختصارًا JIT

وبشكل مخصص تُشغّل مكتبة الذاكرة القياسية في جافا جمع القمامة بشكل كبير، مقارنة بالتخصيص الأقل لذاكرة الكومة Heap في ++C لكن تبقى لغة جافا لغة سريعة نسبيًا ومقبولة الأداء في التطبيقات التي لا تكون فيها سرعة الاستجابة أمرًا أساسيًا مثل الألعاب أو التطبيقات التي تتطلب استجابة في الزمن الحقيقي.

بناء وإدارة الحزم

يمكن التغاضي عن نقص أداء لغة جافا مقابل سهولة الاستخدام التي توفرها لا سيما في إدارة الحزم وطريقة بناء التطبيقات وإضافة التبعيات الخارجية إليها. حيث توفر لغة جافا أداة تسمى Maven تبسط العمل على المشاريع وتمكنك من إداراتها ببضع خطوات سهلة كما أنها تتكامل مع العديد من بيئات التطوير المتكاملة مثل IntelliJ IDEA.

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

ملاءمة اللغة للمبتدئين

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

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

هل أختار C++‎‎ أم Java؟

الآن بعد تعرفت على أهم الاختلافات والفروقات بين لغة C++‎‎ و Java لنعد للسؤال الأساسي هل أستخدم C++‎‎ أم جافا في تطوير تطبيقاتي؟ في الواقع لا يوجد جواب موحد على هذا السؤال يناسب الجميع حتى مع الفهم العميق لميزات كل من هاتين اللغتين.

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

ورغم ذلك قد تؤثر الفروق التقنية بين لغتي C++‎‎ و Java بشكل بسيط على قرار اختيار اللغة الأنسب، ويعتمد نوع اللغة بشكل أكبر على طبيعة التطبيقات أو المنتجات التي تريد تطويرها فقد تكون جافا هي الأنسب أو هي الأنسب أو ربما في النهاية برمجة ثالثة هي الأنسب.

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

الخلاصة

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

ترجمة بتصرف لمقال An In-depth Look at C++ vs. Java للكاتب Timothy Mensch

اقرأ أيضًا

• دليلك الشامل إلى لغات البرمجة عالية المستوى
• أنظمة التصريف المستخدمة لبناء البرامج المكتوبة بلغة Cpp وأهم أخطاء عملية البناء
• مواضيع متقدمة عن الأنواع والتعامل معها في Cpp
• البواني وتهيئة الكائنات Object Initialization في جافا
• المؤشرات الذكية (Smart Pointers) في Cpp

النطاقات Scopes

المتغيرات العامة Global variables

إذا أردت التصريح عن نسخة واحدة من متغير ما، وكانت هذه النسخة متاحة للوصول في عدة ملفات مصدرية source files، فمن الممكن أن نجعلها في النطاق العام global scope باستخدام الكلمة المفتاحية extern، فهي تخبر المصرِّف بوجود تعريف لهذا المتغير في مكان ما داخل الشيفرة الحالية، لذا فمن الممكن استخدامه في أي مكان، كما ستُجرى جميع عمليات القراءة / الكتابة في نفس المكان من الذاكرة.

يتألّف المثال التالي من عدّة ملفات مصدرية:

الملف my_globals.h:

#ifndef __MY_GLOBALS_H__
#define __MY_GLOBALS_H__
extern int circle_radius; //  سيُعرَّف في مكان ما circle_radius تخطر المصرّف بأنّ
#endif

الملف foo1.cpp:

#include "my_globals.h"

int circle_radius = 123; // extern  تعريف المتغير الخارجي

الملف main.cpp:

#include "my_globals.h"

#include <iostream>

int main() {
    std::cout << "The radius is: " << circle_radius << "\n";
    '
    return 0;
}

سينتج الخرج التالي:

The radius is: 123

المتغيرات المضمنة Inline variables

يُسمح بتعريف مُتغير مُضمّن Inline variable في عدّة وحدات ترجمة دون انتهاك قاعدة التعريف الواحد. وفي حال تعريف متغيّر مُضمّن أكثر من مرة، فسيَدمِج الرابط linker كلّ تَعاريفه في كائن واحد في البرنامج النهائي.

يمكن تعريف حقل ساكن static data member في صنف إن صُرِّح عنه بأنّه مُضمّن ‎inline‎. على سبيل المثال، يمكن تعريف الصنف في المثال التالي في الترويسة.

ملاحظة: قبل C++‎ 17، كان من الضروري توفير ملفّ ‎.cpp‎ لاحتواء تعريف Foo::num_instances كي نضمن ألا يُعرّف أكثر من مرّة واحدة، لكن في C++‎ 17، أصبحت مُختلف تعريفات المتغيّر المضمن ‎Foo::num_instances‎ تشير إلى نفس الكائن ‎int‎.

// not thread-safe قد لا يكون متوافقا مع المسالك
class Foo {
    public:
        Foo() {
            ++num_instances;
        }~Foo() {
            --num_instances;
        }
    inline static int num_instances = 0;
};

وفي حالّة خاصة، تكون الحقول الساكنة للتعابير الثابتة constexpr‎ مضُمّنة بطريقة غير صريحة implicitly.

class MyString {
    public:
        MyString() {
            /* ... */ }
    // ...
    static constexpr int max_size = INT_MAX / 2;
};

صار التعريف constexpr int MyString::max_sizeضروريًا في كل وحدات الترجمة في إصدار C++ 1.

نطاق كتلة بسيط

يبدأ نطاق متغيّر ما في كتلة ‎{ ... }‎ بعد التصريح وينتهي عند نهاية الكتلة، فإذا كانت هناك كتلة متشعّبة nested block، فتستطيع الكتلة الداخلية إخفاء نطاق المتغيّر الذي صُرِّح عنه في الكتلة الخارجية.

{
    int x = 100;
    //   ^
    //   يبدأ هنا `x` نطاق
    //
}   // <- ينتهي هنا `x` نطاق

في حال التصريح عن متغير جديد داخل الكتلة المُتشعِّبة، وكان ذلك المتغير يحمل اسم متغير موجود في الكتلة الخارجية، فإنه يخفي المتغير الأول الذي في الكتلة الخارجية.

{
    int x = 100; {
        int x = 200;
        std::cout << x; // → 200
    }
    std::cout << x; // →  100
}

قاعدة التعريف الواحد ODR

انتهاك قاعدة ODR عبر تحليل التحميل الزائد

يمكن انتهاك ODR إذا لم يشِر البحث عن الأسماء إلى نفس الكيان حتى في حال استخدام مقاطع tokens متماثلة للتعبير عن دالة مضمّنة معيّنة. لاحظ الدالة ‎func‎ في المثال التالي:

• header.h

void overloaded(int);
inline void func() {
    overloaded('*');
}

• foo.cpp ، تشير overloaded إلى (void overloaded(char:

#include "header.h"

void foo() {
    func();
}

• bar.cpp، تشير overloaded إلى (void overloaded(char:

void overloaded(char); // أخرى “include” قد تأتي من عبارات تضمين
#include "header.h"

void bar() {
    func();
}

لدينا انتهاك هنا لقاعدة ODR، إذ يشير المقطع ‎overloaded‎ إلى عدّة كيانات مختلفة في نفس وحدة الترجمة.

مضاعفة الدوال المعرفة Multiply defined function

إنّ أهم نتيجة لقاعدة التعريف الواحد هي أنّ الدوال غير المضمّنة ذات الارتباط الخارجي non-inline functions with external linkage يجب ألا تُعرَّف إلا مرّة واحدة في البرنامج، لكن يمكن التصريح عنها عدّة مرات. لذا لا ينبغي تعريف مثل هذه الدوال في الترويسات، إذ يمكن إدراج الترويسة عدّة مرات من قبل عدة وحدات ترجمة مختلفة.

• foo.h‎:

#ifndef FOO_H
#define FOO_H
#include <iostream>
void foo() { std::cout << "foo"; }
void bar();
#endif

• foo.cpp:

#include "foo.h"

void bar() {
    std::cout << "bar";
}

• main.cpp‎:

#include "foo.h"

int main() {
    foo();
    bar();
}

في هذا البرنامج، عُرِّفت الدالّة الأبسط ‎foo‎ في الترويسة ‎foo.h‎، والتي ضُمِّنت مرّتين: مرّة من قبل ‎foo.cpp‎ ومرّة أخرى من قبل ‎main.cpp‎، ولذلك تحتوي كل وحدة ترجمة على تعريف ‎foo‎ الخاص بها.

لاحظ أنّ دروع التضمين include guards في ‎foo.h‎ لا تمنع حدوث ذلك، إذ أنّ الملفين ‎foo.cpp‎ و ‎main.cpp‎ يشتملان على ‎foo.h‎ بشكل منفصل، وعلى الأرجح سينتج عن محاولة إنشاء هذا البرنامج خطأٌ في وقت الربط link-time error بسبب تعريف ‎foo‎ أكثر من مرّة.

ويجب التصريح عن الدوال في الترويسات وتعريفها في ملفات ‎.cpp‎ المقابلة لتجنّب مثل هذه الأخطاء، مع بعض الاستثناءات.

الدوال المضمنة Inline functions

يمكن تعريف دالّة مُضمّنة ‎inline‎ في عدّة وحدات ترجمة بشرط أن تكون جميع تَعاريفها متطابقة، ويجب أن تُعرّف أيضًا في كل وحدة ترجمة تُستخدم فيها، لذا يجب تعريف الدوال المضمّنة في الترويسات، ولا توجد حاجة إلى ذكرها في ملف التنفيذ implementation file.

سيتصرّف البرنامج كما لو كان هناك تعريف واحد للدالّة.

• foo.h‎:

#ifndef FOO_H
#define FOO_H
#include <iostream>
inline void foo() { std::cout << "foo"; }
void bar();
#endif

• foo.cpp:

#include "foo.h"

void bar() {
    // تعريفات أخرى أكثر تعقيدا
}

• main.cpp‎:

#include "foo.h"

int main() {
    foo();
    bar();
}

في هذا المثال، عُرِّفت الدالّة ‎foo‎ بصورة مُضمّنة inline في الترويسة، أمّا الدالّة الأكثر تعقيدًا ‎bar‎ فهي غير مُضمنة، وقد عُرِّفت في ملف التقديم. وتحتوي كل من وحدتي الترجمة foo.cpp‎ و ‎main.cpp على تعريفات لـ ‎foo‎، وهذا لن يسبّب مشكلة لأنّ ‎foo‎ مضمّنة.

تكون الدوالّ المُعرَّفة داخل تعريف صنف ما -والتي قد تكون دوالًا تابعة أو صديقة- مضمنة بشكل غير صريح، لذا يمكن تعريف الدوال التابعة للفصل داخل تعريف الصنف، رغم أنّه يمكن إدراج التعاريف في وحدات ترجمة متعددة:

// in foo.h
class Foo {
    void bar() {
        std::cout << "bar";
    }
    void baz();
};
// in foo.cpp
void Foo::baz() {
    // التعريف
}

عُرِّفت الدالّة ‎Foo::baz‎ خارج السطر، وعليه تكون غير مُضمّنة، ويجب ألا تُعُرِّف في الترويسة.

البحث باسم الوسيط Argument Dependent Name Lookup

عند البحث عن الدوال، تُجمع "الأصناف المرتبطة" associated classes، و"فضاءات الأسماء المرتبطة" associated namespaces التي تحقق أحد الشروط التالية، وفقًا لنوع الوسيط ‎T‎.

عند البحث عن الدوال فإننا نجدها عبر جمع "الأصناف المرتبطة" associated classes أولًا، وكذلك "فضاءات الأسماء المرتبطة" associated namespaces، التي تحقق شرطًا أو أكثر من الشروط أدناه وفقًا لنوع الوسيط ‎T‎، لكن سنعرض قبل هذا القواعد الخاصة بأسماء الأصناف والتعداد وقوالب أسماء الأصناف:

• إذا كان ‎T‎ صنفًا مُتشعِّبا nested class، أو عضوَ تعدادٍ member enumeration، فسيُضاف الصنف المحيطة به إلى مجموعة البحث.
• إذا كان ‎T‎ تعدادًا -قد يكون أيضًا عضوًا من صنف-، يُضاف أعمق فضاء اسم - innermost namespace - داخله إلى مجموعة البحث.
• إذا كان ‎T‎ صنفًا -قد يكون مُتشعِّبًا أيضًا-، تُضاف جميع أصنافه الأساسية، وكذلك الصنف نفسه، وأعمق فضاءات الاسم في جميع الأصناف المرتبطة.
• إذا كان ‎T‎ من النوع ‎ClassTemplate<TemplateArguments>‎ -وهو صنف أيضًا-، تُضاف الأصناف وفضاءات الاسم المرتبطة بوسائط نوع القالب، وفضاء الاسم الخاص بوسائط قالب القالب template template argument، والصنف المحيط بوسائط قالب القالب، إذا كان وسيط القالبِ template argument قالبَ عضوٍ member template.

هناك بعض القواعد التي تخصّ الأنواع المضمّنة أيضًا:

• إذا كان ‎T‎ مؤشّرًا يشير إلى نوع ‎U‎، أو مصفوفةً مؤلّفة من عناصر من النوع ‎U‎، تُضاف أصناف وفضاءات الأسماء المرتبطة بـ ‎U‎ إلى مجموعة البحث. في المثال: void (*fptr)(A);f(fptr);‎، تُضاف فضاءات الأسماء والأصناف المرتبطة بـ ‎void(A)‎ (انظر القاعدة التالية).
• إذا كان ‎T‎ نوع دالّة، تُضاف الأصناف وفضاءات الأسماء المرتبطة بأنواع المُعاملات والقيمة المعادة. في المثال: void(A)‎، تُضاف فضاءات الأسماء والأصناف المرتبطة بـ A.
• إذا كان ‎T‎ مؤشّرًا يشير إلى عضو، تُضاف الأصناف وفضاءات الأسماء المرتبطة بنوع ذلك العضو (قد تنطبق على كل من مؤشّرات التوابع ومؤشّرات الحقول). في مثال ‎‎B A::*p; void (A::*pf)(B); f(p);f(pf);‎؛ تُضاف فضاءات الأسماء والأصناف المرتبطة بـ A‎ و B‎ وvoid(B)‎، والتي تطبّق القواعد أعلاه التي تخصّ أنواع الدوال.

يُعثَر على جميع الدوال والقوالب داخل جميع فضاءات الأسماء المرتبطة من خلال البحث باسم الوسيط، أو البحث المعتمد على الوسيط argument dependent lookup. ويُعثَر على الدوال الصديقة friend functions لنطاق الأسماء المُصرَّح عنها في الأصناف المرتبطة، والتي عادة ما تكون غير مرئية. بالمقابل، تُتجَاهل الموجّهات directives. وتكون جميع الاستدعاءات في المثال التالي صالحة حتى دون الحاجة إلى تأهيل ‎f‎ بفضاء الاسم عند الاستدعاء.

namespace A {
    struct Z {};
    namespace I {
        void g(Z);
    }
    using namespace I;
    struct X {
        struct Y {};
        friend void f(Y) {}
    };
    void f(X p) {}
    void f(std::shared_ptr < X > p) {}
}
// أمثلة على الاستدعاءات
f(A::X());
f(A::X::Y());
f(std::make_shared < A::X > ());
g(A::Z()); // "using namespace I;"غير صالح، يُتجاهل

حزم المعاملات Parameter packs

قالب بحزمة معاملات template with a parameter pack

template < class...Types > struct Tuple {};

حزمة المُعاملات parameter pack هي مُعاملُ قالبٍ template parameter يقبل وسيط قالب أو أكثر، أو لا يقبل على الإطلاق، ويكون القالب متغايرًا variadic إذا كان يحتوي على حزمة مُعاملات واحدة على الأقل.

توسيع حزمة معاملات

يُوسَّع نمط ‎parameter_pack ...‎ إلى قائمة من البدائل لحزمة ‎parameter_pack‎ مفصولة بالفاصلة الأجنبية ,، وذلك مع كل معامل من معاملاتها:

template<class T> // أساس التكرار
void variadic_printer(T last_argument) {
    std::cout << last_argument;
}
template<class T, class ...Args>
void variadic_printer(T first_argument, Args... other_arguments) {
    std::cout << first_argument << "\n";
    variadic_printer(other_arguments...); // توسيع حزمة المعاملات
}

عند استدعاء الشيفرة أعلاه مع ‎variadic_printer(1, 2, 3, "hello");‎، ستطبع:

1
2
3
hello

فواصل الأرقام Digit separators

من الصعب قراءة القيم العددية المؤلّفة من من أرقام كثيرة، فمثلًا:

• حاول نُطق 7237498123
• قارن بين 237498123 وبين 237499123 من حيث التساوي.
• حدّد العدد الأكبر من بين 237499123 و 20249472.

وقد عرَّف الإصدار ‎C‎++ 14 علامةَ الاقتباس ‎'‎ على أساس فاصلة للأرقام، بحيث تُستخدَم داخل الأعداد والقيم مصنَّفة النوع المُعرَّفة من قبل المستخدِم user-defined literals لتسهيل قراءة الأعداد الكبيرة. انظر:

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

long long decn = 1'000'000'000ll;
long long hexn = 0xFFFF'FFFFll;
long long octn = 00'23'00ll;
long long binn = 0b1010'0011ll;

تُتجَاهل علامة الاقتباس المُفردة عند تحديد القيمة. مثلًا:

• القيم مصنَّفة النوع التالية: ‎1048576‎ و ‎1'048'576‎ و ‎0X100000‎ و ‎0x10'0000‎ و ‎0'004'000'000‎ كلها لها نفس القيمة.
• القيم مصنفة النوع التالية ‎1.602'176'565e-19‎ و ‎1.602176565e-19‎ لهما نفس القيمة.

ولا توجد أهمية تُذكر لموضع علامات الاقتباس المُفردة، فمثلًا، كل التعابير التالية متكافئة:

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

long long a1 = 123456789ll;
long long a2 = 123'456'789ll;
long long a3 = 12'34'56'78'9ll;
long long a4 = 12345'6789ll;

كذلك يُسمح باستخدام الفاصلة في القيم مصنَّفة النوع والمُعرّفة من المستخدم:

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

std::chrono::seconds tiempo = 1'674'456s + 5'300h;

موازنة مع إصدارات C++‎ المختلفة

اعلم أنه يمكن تنفيذ تكرار حلقي على حاوية التسلسل c في لغة ++C باستخدام الفهارس على النحو التالي:

for (size_t i = 0; i < c.size(); ++i) c[i] = 0;

هذه الصيغة -رغم بساطتها- عرضة لكثير من الأخطاء الشائعة، مثل استخدام عامل مقارنة خاطئ، أو متغيّر فهرسة غير صحيح:

for(size_t i = 0; i <= c.size(); ++j) c[i] = 0;
                     ^~~~~~~~~~~~~~^

كذلك يمكن التكرار على الحاويات باستخدام المُكرّرات iterators، مع عيوب مماثلة:

for(iterator it = c.begin(); it != c.end(); ++it) (*it) = 0;

وقد قدّمت C++‎ 11 حلقة for النطاقية، إضافة إلى الكلمة المفتاحية ‎auto‎، واللّتان سمحتا بكتابة شيفرات مثل:

for(auto& x : c) x = 0;

وهنا، يكون المُعاملان الوحيدان هما الحاوية ‎c‎، ومتغيّر ‎x‎ لتخزين القيمة الحالية. هذا يمنع الأخطاء المشار إليها سابقا. ووفقًا لمعيار C++‎ 11، فإنّ التنفيذ الأساسي underlying implementation يكافئ:

for(auto begin = c.begin(), end = c.end(); begin != end; ++begin)
{
// ...
}

في مثل هذا التنفيذ فإن التعبير ‎auto begin = c.begin(), end = c.end();‎ يجبر ‎begin‎ و ‎end‎ على أن يكونا من نفس النوع، بينما لا تُزاد قيمة ‎end‎ ولا تحصَّل dereferenced، ومن ثم فإنّ حلقة for النطاقية لا تعمل إلا على الحاويات المُعرَّفة بواسطة زوج مُكرّر/ مُكرّر iterator/iterator. وقد خفّف معيارُ C++‎ 17 هذا القيد عن طريق تعديل التنفيذ:

auto begin = c.begin();
auto end = c.end();
for(; begin != end; ++begin)
{
// ...
}

هنا يُسمح بأن تكون ‎begin‎ و ‎end‎ من نوعين مختلفين طالما أنه يمكن مقارنتهما للتحقّق من أنّهما غير متساويين. هذا يسمح بالتكرار على العديد من الحاويات مثل الحاويات المعرّفة عبر زوج مُكرّر/حارس iterator/sentinel.

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

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

• Chapter 64: Inline variables
• Chapter 117: Scopes
• Chapter 120: One Definition Rule (ODR)‎
• Chapter 122: Argument Dependent Name Lookup
• Chapter 129: Parameter packs
• Chapter 135: Digit separators
• Chapter 137: Side by Side Comparisons of classic C++ examples solved via C++ vs C++11 vs C++14 vs C++1

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

تُعرف اللغتان C وC++‎ بانّ أداءهما عال جدًّا - ويُعزى ذلك في الغالب إلى إمكانية التخصيص المكثّف للشيفرة، إذ يُسمح للمستخدم بتحسين الأداء عبر اختيار بنية الشيفرة وكيفية تنفيذها. وإن أردت تحسين الشيفرة فمن المهم أن تفهمها وتعرف كيفية استخدامها.

وتشمل بعض أخطاء التحسين الشائعة ما يلي:

• التحسين السابق لأوانه: قد يسوء أداء الشيفرات المعقّدة بعد التحسين ممّا يضيع الوقت ويقلل الكفاءة. يجب أن تكون الأولوية هي كتابة شيفرة صحيحة وقابلة للصيانة، وليس شيفرة مُحسَّنة.
• التحسين في الحالات غير المناسبة: إضافة تحميل زائد لأجل حالة احتمال حدوثها 1% لا يستحقّ أن تبطئ لأجله 99% من الحالات الأخرى.
• التحسين المصغّر Micro-optimization: تقوم المُصرِّفات بهذا الأمر بفعالية كبيرة، كما أن التحسين المصغَّر يمكن أن يضرّ بقدرة المُصرِّفات على زيادة تحسين الشيفرة.

وبعض أهداف التحسين النموذجية ما يلي:

• تقليل كمية العمل المطلوبة.
• استخدام خوارزميات / بنيات أكثر فاعلية.
• استغلال العتاد بشكل أفضل.

لكن قد تكون لعمليات التحسين تأثيرات جانبية سلبية، مثل:

• الاستخدام المكثّف للذاكرة.
• تعقيد الشيفرة وصعوبة قراءتها أو صيانتها.
• تعقيد الواجهات البرمجية API وتصميمات الشيفرة.

على أي حال، غالبًا ما يُعدِّل المُصرِّفُ البرنامجَ عند التصريف لتحسين أدائه، وهذا مسموح به وفقًا لقاعدة "كما لو" as-if rule. والتي تسمح بإجراء التغييرات والتحويلات التي لا تغيّر السلوك الملاحظ للبرنامج.

تحسين الصنف الأساسي الفارغ Empty Base Class Optimization

لا يمكن أن يشغل كائن ما أقل من بايت واحد، وإلّا لكانت أعضاء المصفوفات التي تضم عناصر من نفس النوع تحتل العنوان نفسه. لهذا، تكون ‎sizeof(T)>=1‎ صحيحة دائما. وكذلك لا يمكن أن يكون الصنف المشتق أصغر من صنفه الأساسي base class. لكن إن كان الصنف الأساسي فارغًا، فلن يُضاف حجمه بالضرورة إلى الصنف المشتق:

class Base {};
class Derived: public Base {
    public: int i;
};

وليس من الضروري هنا تخصيص بايت للصنف ‎Base‎ داخل ‎Derived‎ حتى يحتلّ كل كائن -بغض النظر عن نوعه- عنوانًا مميّزًا. وفي حال إجراء تحسين للصنف الأساسي الفارغ -ولم تكن هناك حاجة إلى الحشو padding-، فستكون العبارة ‎sizeof(Derived) ==sizeof(int)‎ صحيحة، أي أنّه لن يُجرى أيّ تخصيص إضافي للصنف الفارغ. هذا ممكن حتّى مع الأصناف الأساسية base classes المتعددة، إذ لا يمكن لعدّة أًصناف أساسية في ++C أن يكون لها نفس النوع، وعليه فلن تنشأ مشكلة من ذلك.

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

التحسين عن طريق تقليل الشيفرة المنفذة

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

هذه بعض الأمثلة على تقليل الشيفرات المنفّذة:

إزالة الشيفرات عديمة الفائدة

void func(const A *a); // دالة ما
// تخصيص غير ضروري للذاكرة + إلغاء تخصيص النسخة
auto a1 = std::make_unique<A>();
func(a1.get());
// استخدام المكدّس يمنع
auto a2 = A{};
func(&a2);

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

منذ الإصدار C++‎ 14، يُسمح للمُصرِّفات بتحسين هذه الشيفرة لإزالة تخصيص الذاكرة، ومطابقة التحرير matching deallocation.

تنفيذ الشيفرة مرة واحدة فقط

std::map<std::string, std::unique_ptr<A>> lookup;
// إدارج/بحث بطيئ
// داخل هذه الدالة، سنمر على القاموس مرّتين لأجل البحث عن العنصر، ومرّة ثالثة إن لم يكن موجودا
const A *lazyLookupSlow(const std::string &key) {
   if (lookup.find(key) != lookup.cend())
        lookup.emplace_back(key, std::make_unique<A>());
   return lookup[key].get();
}

// داخل هذه الدالة، سيحصل نفس التأثير الذي يحدث في النسخة الأبطأ لكن مع مضاعفة السرعة
// لأنّنا سنمر على القاموس مرة واحدة فقط
const A *lazyLookupSlow(const std::string &key) {
    auto &value = lookup[key];
    if (!value)
        value = std::make_unique<A>();
    return value.get();
}

يمكن استخدام أسلوب مشابه للتحسين عبر تنفيذ implement إصدار مستقر من ‎unique‎:

std::vector<std::string> stableUnique(const std::vector<std::string> &v) {
    std::vector<std::string> result;
    std::set<std::string> checkUnique;
    for (const auto &s : v) {
        // يُعاد الإدراج إن كان ناجحا، لذلك يمكن أن نعرف ما إذا كان العنصر موجودًا أم لا 
        // هذا يمنع الإدراج، والذي سيمر على القاموس مرّة لكل عنصر فريد
// على عناصر مكرّرة v يُكسِبنا هذا حوالي نصف الوقت إن لم تحتو
        if (checkUnique.insert(s).second)
            result.push_back(s);
    }        
    return result;
}

منع عمليات إعادة التخصيص والنسخ أو النقل عديمة الفائدة

منعنا في المثال السابق عمليّات البحث في std::set، بيْد أنّ هذا غير كافٍ، فما يزال المتجه ‎std::vector‎ يحتوي على خوارزمية مكلّفة ونامية ستحتاج إلى نقل ذاكرتها، يمكن منع هذا عبر حجز الحجم المناسب.

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

ملاحظة: يمكن أن تنتبه المصرفات لهذا الأمر وتحذف شيفرة التحقق من الشيفرة المولَّدة.

std::vector<std::string> stableUnique(const std::vector<std::string> &v) {
    std::vector < std::string > result;

    result.reserve(v.size());
    std::set < std::string > checkUnique;
    for (const auto &s : v) {
        // انظر المثال أعلاه
        if (checkUnique.insert(s).second)
            result.push_back(s);
    }
    return result;
}

استخدام حاويات أكفأ

استخدام بنيات البيانات الصحيحة في الوقت المناسب يمكن أن يحسّن التعقيد الزمني للشيفرة، انظر المثال التالي حيث يساوي تعقيد stableUnique هنا (N log(N، حيث N أكبر من عدد العناصر في v:

// log(N) > insert complexity of std::set
std::vector<std::string> stableUnique(const std::vector<std::string> &v) {
    std::vector<std::string> result;
    std::set<std::string> checkUnique;
    for (const auto &s : v) {
        // انظر فقرة التحسين عبر تقليل الشيفرة المنفّذة
        if (checkUnique.insert(s).second)
            result.push_back(s);
    }
    return result;
}

يمكننا تخفيض تعقيد التقديم إلى N عبر استعمال حاوية تستخدم تنفيذًا مختلفًا لتخزين عناصرها، مثل قاموس hash بدلًا من شجرة tree. وهناك أثر جانبي إضافي أيضًا، وهو تقليل استدعاء مُعامل المقارنة على السلاسل النصية، لأنّنا لن نحتاج إلى استدعائها إلّا في حال كانت ستُدرج السلسلة النصية في نفس المجموعة. انظر المثال التالي حيث يكون تعقيد stableUnique مساويًا لـ (N log (N، حيث N أكبر من عدد العناصر في v:

// أكبر من 1 std::unordered_set تعقيد الإدراج في
std::vector<std::string> stableUnique(const std::vector<std::string> &v) {
    std::vector<std::string> result;
    std::unordered_set<std::string> checkUnique;
    for (const auto &s : v) {
        // انظر فقرة التحسين عبر تقليل الشيفرة المنفّذة
        if (checkUnique.insert(s).second)
            result.push_back(s);
    }
    return result;
}

تحسين الكائنات الصغيرة Small Object Optimization

تحسين الكائنات الصغيرة هي تقنية تُستخدم في بنيات البيانات منخفضة المستوى، مثل ‎std::string‎ (يشار إليها أحيانًا باسم تحسين السلاسل النصية القصيرة/الصغيرة)، ويُقصد بها استخدام مساحة مكدّس كمخزن مؤقت buffer بدلًا من استخدام ذاكرة مخصّصة عندما يكون المحتوى صغيرًا بدرجة كافية لتسَعَه المساحة المحجوزة. وسنحاول منع تخصيص مساحة في الكومة heap، لكنّ ثمن هذا هو إضافة حمل إضافي overhead على الذاكرة، وإجراء بعض الحسابات الإضافية.

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

#include <cstring>
class string final
{
    constexpr static auto SMALL_BUFFER_SIZE = 16;
    bool _isAllocated{false}; ///< تذكّر إذا كنّا قد خصّصنا الذاكرة
    char *_buffer{nullptr}; ///< مؤشر يشير إلى المخزن المؤقت الذي نستخدمه 
    char _smallBuffer[SMALL_BUFFER_SIZE]= {'\0'}; 
///<  SMALL OBJECT مساحة المكدّس المُستخدمة لأجل الكائن الصغير
OPTIMIZATION
public:
    ~string()
    {
        if (_isAllocated)
            delete [] _buffer;
    }
    explicit string(const char *cStyleString)
    {
        auto stringSize = std::strlen(cStyleString);
        _isAllocated = (stringSize > SMALL_BUFFER_SIZE);
        if (_isAllocated)
            _buffer = new char[stringSize];
        else
            _buffer = &_smallBuffer[0];
            std::strcpy(_buffer, &cStyleString[0]);
        }
    string(string &&rhs)
        : _isAllocated(rhs._isAllocated)
        , _buffer(rhs._buffer)
        , _smallBuffer(rhs._smallBuffer) //<  غير ضروري عند التخصيص
    {
        if (_isAllocated)
        {
            // منع الحذف المزدوج للذاكرة
            rhs._buffer = nullptr;
        }
        else
        {
            // نسخ البيانات
            std::strcpy(_smallBuffer, rhs._smallBuffer);
            _buffer = &_smallBuffer[0];
        }
    }
    // حَذفنا التوابع الأخرى، مثل منشئ النسخ ومعامل الإسناد، لأجل تحسين القراءة والوضوح
};

كما ترى في الشيفرة أعلاه، فقد أُضيفت بعض التعقيدات الإضافية لمنع تنفيذ بعض عمليات ‎new‎ و ‎delete‎. وأصبح لدى الصنف مساحة أكبر للذاكرة، وقد لا يستخدَمها إلا في بضع حالات فقط.

غالبًا ما سيُحاول ترميزَ القيمة البوليانية ‎_isAllocated‎ داخل المؤشّر ‎_buffer‎ عبر معالجة البتّات من أجل تقليل حجم النُسخة (intel 64 bit: يمكن أن يقلّل الحجم بمقدار 8 بايت)، لكن هذا التحسين غير ممكن إلا إن كانت قواعد المحاذاة الخاصّة بالمنصة معروفة.

حالات الاستخدام

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

قد تجد بعض الاستخدامات في ‎std::basic_string<>‎ و ‎std::function<>‎ في تطبيقات implementations المكتبة القياسية الشائعة في C++‎ 11.

وبما أن هذا التحسين لا يمنع تخصيصات الذاكرة إلا عندما تكون البيانات المُخزّنة أصغر من القيمة المضافة، فستظهر فائدته بالخصوص في الأصناف التي تُستخدم غالبًا مع البيانات الصغيرة. لكن هناك عيب فيه وهو الحاجة إلى جهد إضافي عند تحريك المخزن المؤقت، وهذا يجعل عمليّات النقل أكثر كلفة موازنة بالحالات التي لا يُستخدم المخزن المؤقّت فيها، خاصة عندما يحتوي المخزن المؤقّت على نوع بيانات غير قديم non-POD type.

توسيع التضمين والتضمين

توسيع التضمين Inline expansion، أو التضمين inlining وحسب، هي تقنية تحسين يستخدمها المُصرِّف تقوم على تعويض استدعاء دالة بمتن تلك الدالّة. هذا يقلّل من الحمل الزائد overhead لاستدعاء الدوالّ، ولكن على حساب الذاكرة، إذ أنّ الدالّة قد تُكرّر عدّة مرات.

// :المصدر
int process(int value) {
    return 2 * value;
}
int foo(int a) {
    return process(a);
}
// :البرنامج بعد التضمين
int foo(int a) {
    return 2 * a; // foo() في process() نسخ متن
}

تُستخدم تقنية التضمين غالبًا مع الدوال الصغيرة، حيث يكون الحمل الزائد لاستدعاء الدالّة صغيرًا مقارنةً بحجم جسم الدالّة.

تحسين الصنف الأساسي الفارغ Empty base optimization

يجب أن لا يقلّ حجم أي كائن أو عضو من كائن فرعي عن القيمة 1، حتى لو كان ذلك النوع فارغًا (أي حتى لو لم يحتوٍ الصنف ‎class‎ أو البنية ‎struct‎ على أعضاء بيانات غير ساكنة)، وذلك لأجل ضمان أن تكون عناوين الكائنات المختلفة التي تنتمي لنفس النوع مختلفة دائمًا.

بالمقابل، فإنّ القيود على الكائنات الفرعية من الصنف الأساسي base class subobjects أقل بكثير، ويمكن تحسينها بشكل كامل انطلاقًا من مخطط الكائن:

#include <cassert>

struct Base {}; // صنف فارغ
struct Derived1: Base {
    int i;
};
int main() {
    // حجم أيّ كائن من صنف فارغ يساوي 1 على الأقل
    assert(sizeof(Base) == 1);
    // تطبيق تحسين الصنف الفارغ
    assert(sizeof(Derived1) == sizeof(int));
}

يُستخدم تحسين الصنف الفارغ عادةً في أصناف المكتبة القياسية الواعية بتخصيص كل من الذاكرة:

• std::vector‎.
• std::function.
• std::shared_ptr.

أو غيرها، وذلك لتجنّب شغل أي مساحة تخزين إضافية من قبل عضو مُخصِّص allocator member إذا كان ذلك المُخصّص عديم الحالة stateless. ويمكن تحقيق ذلك عن طريق تخزين أحد أعضاء البيانات المطلوبة، مثل: مؤشّرات ‎begin‎ و ‎end‎، أو ‎capacity‎ الخاصّة بالمتجهات.

التشخيص Profiling

التشخيص باستخدام gcc وgprof

يتيح لك برنامج التشخيص gprof الخاصّ بـ GNU gprof تشخيص شيفرتك. ولأجل لاستخدامه، عليك إنجاز الخطوات التالية:

1. ابنِ التطبيق مع الإعدادات المناسبة لتوليد معلومات التشخيص.
2. قم بتوليد معلومات التشخيص عن طريق تشغيل التطبيق المبني.
3. اعرض معلومات التشخيص المُولّدة باستخدام أداة gprof.

أضف راية ‎-pg‎ لأجل بناء التطبيق مع إعدادات توليد معلومات التشخيص المناسبة، انظر:

$ gcc -pg *.cpp -o app

أو:

$ gcc -O2 -pg *.cpp -o app

وهكذا دواليك. بمجرد إنشاء التطبيق (نفترض أنّ اسمه ‎app‎)، نفِّذه كالمعتاد:

$ ./app

من المفروض أن ينتج هذا الأمرُ ملفًّا يُسمّى ‎gmon.out‎. إن أردت رؤية نتائج التشخيص، نفّذ الأمر التالي:

$ gprof app gmon.out

(لاحظ أننا وقرنا كلًّا من التطبيق وكذلك الخرج الناتج). ويمكنك توجيه الخرج أو إعادة توجيهه:

$ gprof app gmon.out | less

يجب أن تكون نتيجة الأمر الأخير مطبوعة على شكل جدول، ستمثّل صفوفهُ الدوالَّ، أمّا أعمدته فتشير إلى عدد الاستدعاءات، وإجمالي الوقت المستغرق، والوقت الذاتي المستغرق - self time spent - (أي الوقت المستغرق داخل الدالة ما عدا استدعاءات الدوال الداخلية).

إنشاء مخططات الاستدعاءات callgraph بواسطة gperf2dot

بالنسبة للتطبيقات الكبيرة، فقد يصعب فهم تنسيق التشخيص المُستَوي flat execution profiles، لهذا تنتج العديد من أدوات التشخيص رسومًا تخطيطية لتسهيل قراءتها.

تحوّل أداة gperf2dot خرْج النص الذي تنتجه العديد من المُشخِّصات، مثل: Linux perf، وcallgrind، وoprofile إلى رسم تخطيطي، يمكنك استخدام هذه الأداة عن طريق تشغيل المشخّص profiler الذي تعمل به مثل ‎gprof‎:

# التصريف مع رايات التشخيص
g++ *.cpp -pg
# توليد بيانات التشخيص
./main
# ترجمة بيانات التشخيص إلى نص، وإنشاء صورة
gprof ./main | gprof2dot -s | dot -Tpng -o output.png

تشخيص استخدام وحدة المعالجة المركزية بواسطة gcc وGoogle Perf

توفّر أدوات Google Perf برنامج تشخيص لوحدة المعالجة المركزية CPU، مع واجهة استخدام سهلة نسبيًا.

لاستخدامها عليك:

1. تثبيت أدوات Google Perf .
2. تصريف الشيفرة كالمعتاد.
3. إضافة مكتبة التشخيص ‎libprofiler‎ إلى مسار تحميل المكتبات في وقت التشغيل.
4. استخدم ‎pprof‎ لتوليد تشخيص نصّي، أو رسم تخطيطي. مثلّا:

g++ -O3 -std=c++11 main.cpp -o main
# تنفيذ المُشخِّص
LD_PRELOAD=/usr/local/lib/libprofiler.so CPUPROFILE=main.prof CPUPROFILE_FREQUENCY=100000 ./main

حيث:

• تشير ‎CPUPROFILE‎ إلى ملف بيانات التشخيص، و
• تشير ‎CPUPROFILE_FREQUENCY‎ إلى تردّد عيّنات المشخّص profiler sampling frequency. إن أردت إجراء المعالجة اللاحقة post-process لبيانات التشخيص، فاستخدم ‎pprof‎، ويمكنك إنشاء تشخيص استدعاءات flat call profile على هيئة نصّ:

$ pprof --text ./main main.prof
PROFILE: interrupts/evictions/bytes = 67/15/2016
pprof --text --lines ./main main.prof
Using local file ./main.
Using local file main.prof.
Total: 67 samples
22 32.8% 32.8% 67 100.0% longRunningFoo ??:0
20 29.9% 62.7% 20 29.9% __memmove_ssse3_back
/build/eglibc-3GlaMS/eglibc-2.19/string/../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1627
4 6.0% 68.7% 4 6.0% __memmove_ssse3_back
/build/eglibc-3GlaMS/eglibc-2.19/string/../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1619
3 4.5% 73.1% 3 4.5% __random_r /build/eglibc-3GlaMS/eglibc-2.19/stdlib/random_r.c:388
3 4.5% 77.6% 3 4.5% __random_r /build/eglibc-3GlaMS/eglibc-2.19/stdlib/random_r.c:401
2 3.0% 80.6% 2 3.0% __munmap
/build/eglibc-3GlaMS/eglibc-2.19/misc/../sysdeps/unix/syscall-template.S:81
2 3.0% 83.6% 12 17.9% __random /build/eglibc-3GlaMS/eglibc-2.19/stdlib/random.c:298
2 3.0% 86.6% 2 3.0% __random_r /build/eglibc-3GlaMS/eglibc-2.19/stdlib/random_r.c:385
2 3.0% 89.6% 2 3.0% rand /build/eglibc-3GlaMS/eglibc-2.19/stdlib/rand.c:26
1 1.5% 91.0% 1 1.5% __memmove_ssse3_back
/build/eglibc-3GlaMS/eglibc-2.19/string/../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1617
1 1.5% 92.5% 1 1.5% __memmove_ssse3_back
/build/eglibc-3GlaMS/eglibc-2.19/string/../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1623
1 1.5% 94.0% 1 1.5% __random /build/eglibc-3GlaMS/eglibc-2.19/stdlib/random.c:293
1 1.5% 95.5% 1 1.5% __random /build/eglibc-3GlaMS/eglibc-2.19/stdlib/random.c:296
1 1.5% 97.0% 1 1.5% __random_r /build/eglibc-3GlaMS/eglibc-2.19/stdlib/random_r.c:371
1 1.5% 98.5% 1 1.5% __random_r /build/eglibc-3GlaMS/eglibc-2.19/stdlib/random_r.c:381
1 1.5% 100.0% 1 1.5% rand /build/eglibc-3GlaMS/eglibc-2.19/stdlib/rand.c:28
0 0.0% 100.0% 67 100.0% __libc_start_main /build/eglibc-3GlaMS/eglibc-2.19/csu/libcstart.
c:287
0 0.0% 100.0% 67 100.0% _start ??:0
0 0.0% 100.0% 67 100.0% main ??:0
0 0.0% 100.0% 14 20.9% rand /build/eglibc-3GlaMS/eglibc-2.19/stdlib/rand.c:27
0 0.0% 100.0% 27 40.3% std::vector::_M_emplace_back_aux ??:0

أو يمكنك إنشاء رسم تخطيطي في ملف pdf باستخدام الأمر:

pprof --pdf ./main main.prof > out.pdf

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

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

•  Chapter 143: Optimization in C++‎ 
• Chapter 144: Optimization
• Chapter 145: Profiling

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

يقضي مطوّرو C++‎ الكثير من وقتهم في تنقيح الأخطاء (debugging)، ويهدف هذا المقال إلى مساعدتك في هذه المهمة وإعطائك بعض التقنيات المفيدة، لكن لا تتوقع قائمة شاملة للمشاكل وحلولها التي تدعمها هذه الأدوات.

اختبار الوحدات في C++‎

يسعى اختبار الوحدات (Unit testing) إلى التحقق من صحّة وسلامة وحدات الشيفرة (units of code)، ويشير مصطلح "وحدات الشيفرة" في C++‎ غالبًا إلى الأصناف أو الدوال أو مجموعات مؤلّفة منهما.

ويُجرى اختبار الوحدات غالبًا باستخدام "أُطر اختبار" متخصصة أو "مكتبات اختبار"، والتي تستخدِم غالبًا صياغات أو أنماط غير اعتيادية، وسنراجع في هذا الموضوع بعض استراتيجيات ومكتبات وأطر اختبار الوحدات.

اختبار جوجل

اختبار جوجل (Google Test) هو إطار لاختبار C++‎ من Google، ويتطلّب استخدامُه بناء مكتبة ‎gtest‎ وربطها بإطار الاختبار الخاص بك.

مثال بسيط، سنقسم المثال بداعي الشرح …

// main.cpp
#include <gtest/gtest.h>
#include <iostream>

أنشئت حالات اختبار جوجل بواسطة وحدات ماكرو خاصة بالمعالج الأولي لـ ++C، وسنوفر المعامِليْن test name و test suite، نتابع …

TEST(module_name, test_name) {
    std::cout << "Hello world!" << std::endl;

كذلك توفر Google Test وحدات ماكرو لأجل التوكيدات (assertions):

    ASSERT_EQ(1+1, 2);
}

يمكن تشغيل اختبار جوجل يدويًا من دالة ()main أو ربطها بمكتبة gtest_main لدالة ()main معدَّة سلفًا لقبول حالات اختبار جوجل، …

int main(int argc, char** argv) {
    ::testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}
// أمر البناء: g++ main.cpp -lgtest

catch

Catch هي مكتبة ترويسة (header only library) تسمح لك باستخدام كل من نمطي الاختبار TDD و BDD.

الشيفرة التالية مأخوذة من صفحة توثيق Catch:

SCENARIO("vectors can be sized and resized", "[vector]") {
    GIVEN("A vector with some items") {
        std::vector v(5);

        REQUIRE(v.size() == 5);
        REQUIRE(v.capacity() >= 5);

        WHEN("the size is increased") {
            v.resize(10);

            THEN("the size and capacity change") {
                REQUIRE(v.size() == 10);
                REQUIRE(v.capacity() >= 10);
            }
        }
        WHEN("the size is reduced") {
            v.resize(0);

            THEN("the size changes but not capacity") {
                REQUIRE(v.size() == 0);
                REQUIRE(v.capacity() >= 5);
            }
        }
        WHEN("more capacity is reserved") {
            v.reserve(10);

            THEN("the capacity changes but not the size") {
                REQUIRE(v.size() == 5);
                REQUIRE(v.capacity() >= 10);
            }
        }
        WHEN("less capacity is reserved") {
            v.reserve(0);

            THEN("neither size nor capacity are changed") {
                REQUIRE(v.size() == 5);
                REQUIRE(v.capacity() >= 5);
            }
        }
    }
}

سيُبلَغ عن هذه الاختبارات على النحو التالي عند التشغيل:

Scenario: vectors can be sized and resized Given: A vector with some items When: more capacity is reserved Then: the capacity changes but not the size

التحليل الساكن Static analysis

التحليل الساكن طريقة لتفحّص الشيفرة للبحث عن الأنماط التي ترتبط عادة بالأخطاء المشهورة وتدل عليها، هذه التقنية تستغرق وقتًا أقل من مراجعة الشيفرة، لكن تقتصر عمليات التحقق التي تقوم بها على الحالات المُبرمجة في الأداة. وتتضمّن عمليات مثل التحقّق استخدام الفاصلة المنقوطة بشكل غير صحيح بعد عبارة ‎(if (var);)‎ مثلًا، وخوارزميات الشُّعَب (graph algorithms) المتقدمة التي تحدد ما إذا كان المتغيّر مُهيَّأً أم لا.

تحذيرات المُصرِّف Compiler warnings

من السهل تمكين التحليل الساكن، فهناك إصدارات مُبسّطة مُضمّنة سلفًا في مصرّفك:

• clang++ -Wall -Weverything -Werror ...‎
• g++ -Wall -Weverything -Werror ...‎
• cl.exe /W4 /WX ...‎

إذا مكّنتَ هذه الخيارات، ستلاحظ أنّ كل مُصرِّف سيعثر على أخطاء لا تنتبه إليها المصرّفات الأخرى، وستحصل على أخطاء على تقنيات قد تكون صالحة في سياقات محدّدة. فمثلًا، قد تكون ‎while (staticAtomicBool);‎ مقبولة حتى لو لم تكن ‎while (localBool);‎ كذلك.

لذلك، على عكس مراجعة الشيفرة، فأنت تستخدم أداة تفهم شيفرتك، وتنبّهك إلى الكثير من الأخطاء، وأحيانًا قد لا تتفق معك. قد تضطر إلى وقف التحذير محليًا في هذه الحالة نظرًا لأنّ الخيارات المذكورة أعلاه قد تُمكِّن جميع التحذيرات، بما في ذلك التحذيرات التي لا تريدها (مثلًا، لماذا يجب أن تكون شيفرتك متوافقة مع C++‎ 98؟). في هذه الحالة، يمكنك تعطيل تحذير بعينه:

• clang++ -Wall -Weverything -Werror -Wno-errortoaccept ...‎

• ‎‎‎‎g++ -Wall -Weverything -Werror -Wno-errortoaccept ...‎‎

• ‎‎‎‎cl.exe /W4 /WX /wd<no of warning>...‎‎

  صحيح أنّ تحذيرات المصرّف ستساعدك أثناء التطوير، إلّا أنّها تُبطئ عملية التصريف، لهذا قد لا ترغب في تمكينها افتراضيًا في كل مرة، فإما أن تشغّل تحذيرات المصرّف افتراضيًا، أو يمكنك تمكين التكامل المستمر (continuous integration) باستخدام عمليات تحقق أكثر كلفة (أو كليهما).

أدوات خارجية

إذا قرّرت العمل بالتكامل المستمر (continuous integration)، فإنّ استخدام الأدوات الأخرى ليست ذات فائدة. وتحتوي أداة مثل clang-tidy على قائمة من عمليّات التحقق التي تغطي مجموعة واسعة من المشاكل، منها:

• الأخطاء الفعلية
• منع التشريح (Prevention of slicing)
• توكيدات (Asserts) مع آثار جانبية
• التحقّق من إمكانية القراءة
• إزاحات بادئة (indentation) غير صحيحة
• التحقق من تسمية المُعرِّف (Check identifier naming)
• التحقّق من التحديث (Modernization checks)
• استخدام make_unique()‎
• استخدام nullptr *التحقّق من الأداء
• إيجاد النسخ غير الضرورية
• البحث عن خوارزميات الاستدعاء غير الفعّالة

قد لا تكون القائمة كبيرة، إذ أنّ Clang تحتوي على الكثير من التحذيرات، إلّا أنها ستجعل شيفرتك أكثر أمانًا.

أدوات أخرى

توجد أدوات أخرى مماثلة بنفس الغرض، مثل:

• محلل visual studio الساكن كأداة خارجية
• clazy، إضافة خاصّة بمصرّف Clang للتحقق من شيفرات Qt

الخلاصة

توجد الكثير من أدوات التحليل الساكن لـ C++‎، سواء المضمّنة في المُصرِّف، أو الأدوات الخارجية، ولا تأخذ تجربتها الكثير من الوقت عند الاكتفاء بالعمل بالإعدادات السهلة، وستساعدك على رصد أخطاء قد لا تنتبه لها عند مراجعة الشيفرة.

تحليل Segfault مع GDB

سنستخدم نفس الشيفرة التي استخدمناها في المثال أعلاه.

#include <iostream>

void fail() {
    int *p1;
    int *p2(NULL);
    int *p3 = p1;
    if (p3) {
        std::cout << *p2 << std::endl;
    }
}
int main() {
    fail();
}

أولًا، سنحاول تصريفها:

g++ -g -o main main.cpp

ثم نشغّلها بواسطة gdb:

gdb ./main

الآن، سنكون في صدفة gdb. اكتب الأمر run.

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/opencog/code-snippets/stackoverflow/a.out
Program received signal SIGSEGV, Segmentation fault.
0x0000000000400850 in fail () at debugging_with_gdb.cc:11
11 std::cout << *p2 << std::endl;

لاحظ أنّ خطأ التجزئة (segmentation fault) قد حدث في السطر 11، لذا فالمتغيّر الوحيد المُستخدم في هذا السطر هو المؤشّر p2. يمكن التحقّق من محتواه بطباعة ما يلي:

(gdb) print p2
$1 = (int *) 0x0

نلاحظ أنّ p2 هُيِّئ عند القيمة 0×0، والتي تكافئ NULL. في هذا السطر، حاولنا تحصيل (dereference) مؤشّر فارغ، لذا علينا إصلاح هذا الخلل.

تنظيف الشيفرات

يبدأ التنقيح بفهم الشيفرة التي تحاول تنقيحها. انظر المثال التالي عن شيفرة سيّئة:

int main() {
    int value;
    std::vector < int > vectorToSort;
    vectorToSort.push_back(42);
    vectorToSort.push_back(13);
    for (int i = 52; i; i = i - 1) {
        vectorToSort.push_back(i *2);
    }
    /// مُحسّنة لاستخدامها في ترتيب المتجهات الصغيرة
    if (vectorToSort.size() == 1);
    else {
        if (vectorToSort.size() <= 2)
            std::sort(vectorToSort.begin(), std::end(vectorToSort));
    }
    for (value: vectorToSort) std::cout << value << ' ';
    return 0;
}

هذه الشيفرة أفضل:

std::vector < int > createSemiRandomData() {
    std::vector < int > data;
    data.push_back(42);
    data.push_back(13);
    for (int i = 52; i; --i)
        vectorToSort.push_back(i *2);
    return data;
}
    /// مُحسّنة لاستخدامها في ترتيب المتجهات الصغيرة
void sortVector(std::vector &v) {
    if (vectorToSort.size() == 1)
        return;
    if (vectorToSort.size() > 2)
        return;
    std::sort(vectorToSort.begin(), vectorToSort.end());
}
void printVector(const std::vector<int> &v) {
    for (auto i: v)
        std::cout << i << ' ';
}
int main() {
    auto vectorToSort = createSemiRandomData();
    sortVector(std::ref(vectorToSort));
    printVector(vectorToSort);
    return 0;
}

بغض النظر عن نمط التشفير الذي تفضله، سيساعدك الثّبات على نفس النمط على فهم شيفرتك، ويمكن رصد فرصتين لتحسين قراءة الشيفرة بالنظر إلى الشيفرة أعلاه، وكذلك تسهيل تنقيحها:

استخدام دوال منفصلة للإجراءات المنفصلة

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

هناك ميزة أخرى، وهي أنّ الشيفرة التي عليك قراءتها وحفظها ستكون أقصر عند تفحّص الشيفرة، إذ ستحتاج الآن إلى قراءة 3 أسطر فقط من الشيفرة في دالة ‎main()‎ لفهمها، بدلًا من قراءة الدالّة بأكملها.

والميزة الثالثة هي أنّه نظرًا لكون الشيفرةً المُتحقَّق منها أقصر، فإن عينك ستتدرب الآن على رصد الأخطاء في غضون ثوانٍ.

استخدام تنسيقات وإنشاءات متّسقة

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

ويوصى باستخدام أداة مخصّصة لتنسيق الشيفرة نظرًا لأنّ هذه المهمّة قد تستغرق وقتًا طويلاً، وتدعم معظم بيئات التطوير المتكاملة (IDEs) هذه الميزة بشكل أو بآخر.

قد تلاحظ أنّ نمط البرمجة لا يقتصر على استخدام المسافات الفارغة والسطور الجديدة، فلم نعد نمزج بين النمط الحر (free-style) والدوال التابعة لبدء / إنهاء الحاويات (‎v.begin()‎ و ‎std::end(v)‎).

تسليط الضوء على الأجزاء الهامّة من شيفرتك

بغض النظر عن النمط الذي تستخدمه، فإنّ الشيفرة أعلاه تحتوي على عدد من الملاحظات التي قد تعطيك تلميحًا حول الأمور المهمّة في الشيفرة:

• تعليق يتضمّن الكلمة "مُحسَّن" ، في إشارة إلى استخدام بعض التقنيات الجذابة.
• بعض تعليمات return المبكّرة في ‎sortVector()‎ تشير إلى أنّنا نريد فعل شيء خاصّ.
• ‎std::ref()‎ - تشير إلى أنّ شيئًا ما يحدث في ‎sortVector()‎.

الخلاصة

الشيفرات النظيفة أسهل في الفهم وتقلل الوقت اللازم لتنقيحهَا، فقد يتمكّن مُراجِع الشيفرة من رصد الأخطاء منذ الوهلة الأولى في المثال الثاني، بينما قد تكون الأخطاء أخفَى في المثال الأوّل. (ملاحظة الخطأ موجود في: عملية الموازنة مع العدد ‎2‎.)

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

ترجمة -بتصرّف- للفصل Chapter 142: C++ Debugging and Debugprevention Tools & Techniques والفصل Chapter 141: Unit Testing in C++‎ من كتاب C++ Notes for Professionals

ينبغي تصريف البرامج المكتوبة بلغة C++‎ قبل أن تتمكن تلك البرامج من العمل، وستجد مجموعة كبيرة ومتنوّعة من برامج التصريف أو المصرِّفات (compilers) المتاحة والمناسبة لنظام التشغيل الذي تعمل به.

التصريف بواسطة GCC

التصريف دون تحسين مفيد في المراحل الأولى من التطوير والتنقيح، على الرغم من أنّ خيار ‎-Og‎ موصىً به في الإصدارات الحديثة من GCC، وبناء عليه فيمكن تصريف وربط ملف تنفيذي وغير محسَّن على افتراض أن هناك ملفًا مصدريًا واحدًا يسمى main.cpp، وذلك على النحو التالي:

g++ - o app - Wall main.cpp - O0

ولإنتاج ملف مُحسّن قابل للتنفيذ لاستخدامه في الإنتاج، استخدم أحد خيارات ‎-O‎ (راجع: ‎،-O1‎، ‎-O2‎، ‎-O3‎، ‎-Os‎، ‎-‎‎Ofast‎):

g++ - o app - Wall - O2 main.cpp

في حال حذف الخيار ‎-O، سيُستخدَم ‎-O0 الذي يعني إلغاء التحسينات، كخيار افتراضي، واعلم أن تحديد ‎-O بدون رقم يجعله مساويًا لـ ‎-O1.

وكخيار بديل، يمكن أن نستخدم رايات التحسين (optimization flags) من مجموعات ‎O‎ -أو تحسينات تجريبية أخرى- مباشرةً. انظر المثال التالي حيث يبني البرنامج مع التحسين ‎-O2‎، بالإضافة إلى راية واحدة من مستوى التحسين ‎-O3‎:

g++ -o app -Wall -O2 -ftree-partial-pre main.cpp

لإنتاج ملفّ تنفيذي مُحسّن لأجل منصة معيّنة -لاستخدامه على جهاز له نفس المعمارية-، استخدم:

g++ -o app -Wall -O2 -march=native main.cpp

سوف ينتُج عن الشيفرَتين أعلاه ملفٌّ ثنائي (binary file) يمكن تشغيله باستخدام ‎.\app.exe‎ على Windows، أو باستخدام ‎./app‎ على Linux و Mac OS، كما يمكن أيضًا تخطي الراية ‎-o‎، وفي هذه الحالة سينشئ GCC الملفّ التنفيذي الافتراضي ‎a.exe‎ على Windows و ‎a.out‎ على الأنظمة الشبيهة بيونكس (Unix-like).

لأجل تصريف ملف دون ربطه، استخدم الخيار ‎-c‎:

g++ -o file.o -Wall -c file.cpp

سينتج عن هذا ملفٌّ يحمل الاسم ‎file.o‎، والذي يمكن ربطه لاحقًا بملفّات أخرى لإنتاج ملف ثنائي:

g++ -o app file.o otherfile.o

انظر gcc.gnu.org للمزيد من التفاصيل حول خيارات التحسين، خاصة ‎-Og‎، وهو التحسين مع التركيز على تجربة التنقيح (debugging)، الذي يوصى باستخدامه في دورات تحرير-تصريف-تنقيح القياسية - standard edit-compile-debug cycle)، وكذلك ‎-Ofast‎ الذي يشمل جميع التحسينات، بما في ذلك تلك التي تتجاهل الامتثال الصارم للمعايير.

تُمكِّنك راية ‎-Wall‎ من إطلاق تحذيرات من بعض الأخطاء الشائعة، وينبغي أن تُستخدم دائما، ويوصى باستخدام ‎-Wextra‎ لتحسين جودة الشيفرة، وكذلك رايات التحذير الأخرى التي لا تُمكَّن تلقائيًا من قِبل ‎-Wall‎ و ‎-‎‎Wextra‎.

إذا كانت الشيفرة تتوقع معيارًا محدّدًا للغة C++‎، فيمكنك تحديد المعيار الذي تريد استخدامه عن طريق تضمين راية ‎-std=‎. وتتوافق القيم المدعومة مع سنة الإصدار النهائي لمعيار ISO C++‎، واعتبارا من GCC 6.1.0 فإنّ القيم الصالحة لـ ‎std=‎ هي: ‎c++98‎ / ‎c++03‎، ‎c++11‎، ‎c++14‎، و‎c++17‎ / ‎c++1z‎. لاحظ أن القيم المفصولة بشرطةٍ مائلة / متكافئة.

g++ -std=c++11 <file>

يتضمّن GCC بعض الإضافات (Extensions) (extensions) الخاصة بالمُصرِّف، والتي تُعطَّل عندما تتعارض مع معيار قياسي محدّد من قبل راية ‎-std=‎، فإذا أردت التصريف مع كل الإضافات (Extensions) المُمَكَّنة، فاستخدام القيمة ‎gnu++XX‎، حيث تمثّل ‎XX‎ أيًّا من السنوات المذكورة أعلاه.

ويُستخدَم المعيار الافتراضي في حالة عدم تعريف أيّ منها، وبالنسبة لإصدارات GCC التي تسبق 6.1.0 فإنّ الإعداد الافتراضي هو ‎-‎std‎ = ‎gnu‎++03، أما في GCC 6.1.0 والإصدارات الأحدث فإن الإعداد الافتراضي هو ‎-std=gnu++14‎.

لاحظ أنّه نظرا لوجود بعض الأخطاء (bugs) في GCC، فيجب أن تكون راية pthread- حاضرة في التصريف والربط إن أردت أن يدعم GCC معيار الخيوط (threading) الذي أُدخل في C++‎11، مثل ‎std::thread‎ و ‎std::wait_for‎. قد لا ينتج عن حذفها عند استخدام الخيوط أيّ تحذيرات، ولكن قد تحصل على نتائج غير صحيحة في بعض المنصّات.

الربط بالمكتبات Linking with libraries

استخدم خيار ‎-l‎ لتمرير اسم المكتبة:

g++ main.cpp -lpcre2-8
# 8bit code units (UTF-8) في وحدات الشيفرات ثمانية البتّات PCRE2 هي مكتبة pcre2-8 

إذا لم تكن المكتبة موجودة في مسار المكتبة القياسية، فأضف المسار باستخدام ‎-L‎:

g++ main.cpp -L/my/custom/path/ -lmylib

يمكن ربط عدّة مكتبات معًا:

g++ main.cpp -lmylib1 -lmylib2 -lmylib3

إذا كانت إحدى المكتبات تعتمد على مكتبة أخرى، فضع المكتبة المعتِمدة قبل المكتبة المستقلة:

g++ main.cpp -lchild-lib -lbase-lib

أو اترك الرابط (linker) يتكفّل بتحديد الترتيب عبر الخيارات ‎--start-group‎ و ‎--end-group‎ (ملاحظة هذا له تكلفة كبيرة على الأداء):

g++ main.cpp -Wl,--start-group -lbase-lib -lchild-lib -Wl,--end-group

التصريف باستخدام Visual Studio (واجهة رسومية)

1. نزِّل Visual Studio Community 2015 وثبِّته.
2. افتح Visual Studio Community .
3. انقر على File، ثم NewK ثم Project.

4. انقر على Templates ثم ++Visual C ثم Win32 Console Application، ثم ضع اسمًا للمشروع وليكن MyFirstProgram.

5. انقر على Ok.
6. انقر على "Next " في النافذة التالية.

7. اختر الخانة ‎Empty project‎ تحت الخيارات الإضافية (Additional options) ثم انقر على "Finish":

8. انقر بالزر الأيمن فوق مجلد ملف المصدر ثم ‎Add، ثم New Item:

9. حدّد ملف C++‎ وقم بتسمية main.cpp، ثم انقر فوق Add:

10. انسخ والصق الشيفرة التالية في الملف الجديد main.cpp:

#include <iostream>

int main() {
    std::cout << "Hello World!\n";
    return 0;
}

ينبغي أن تبدو بيئة العمل لديك كما يلي:

11. انقر على Debug ثم Start Without Debugging، (أو اضغط على ctrl + F5):

12. يجب أن تحصل على الخرج التالي في سطر الأوامر:

مُصرِّفات الشبكة Online Compilers

توفّر العديد من المواقع مصرّفات C++‎ يمكن الوصول إليها عبر شبكة الإنترنت، وتختلف مزايا وإمكانيات مصرّفات الشبكة من موقع إلى آخر، ولكنها عادة ما تسمح بالقيام بما يلي:

• لصق الشيفرة في نموذج في المتصفّح.
• تحديد بعض خيارات المصرّف، وتصريف الشيفرة.
• الحصول على خرج المصرّف و/أو البرنامج.

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

قد تكون مصرّفات الشبكة مفيدة للأغراض التالية:

• تشغيل مقتطف صغير من شيفرة جهاز يفتقر إلى مصرّف C++‎ (مثل الهواتف الذكية والأجهزة اللوحية وما إلى ذلك).
• التحقّق من أنّ الشيفرة تُصرَّف بنجاح في مختلف المُصرِّفات، وتعمل بنفس الطريقة بغض النظر عن المُصرِّف الذي صُرِّفت فيه.
• تعلُّم أو تعليم أساسيات C++‎.
• تعلّم ميزات C++‎ الحديثة (C++‎ 14 و C++‎ 17 في المستقبل القريب) إذا لم يكن لديك مصرّف C++‎ حديث على جهازك.
• رصد الأخطاء التي يمكن أن تكون موجودة في المصرّف الذي تعمل به بمقارنته بمجموعة كبيرة من المصرّفات الأخرى.
• التحقق ممّا إذا كانت الإصدارات اللاحقة من المصرّف الذي تعمل قد صُحِّحت في حال لم تتوفر تلك الإصدارات على جهازك.
• حل المشاكل والتمارين عبر الشبكة.

بالمقابل، لا ينبغي استخدام مُصرِّفات الشبكة لأجل:

• تطوير برامج كاملة (ولو كانت صغيرة) باستخدام C++‎، وفي العادةً فإن مصرّفات الشبكة لا تسمح بالارتباط مع مكتبات خارجية، أو تنزيل أدوات البناء.

• إجراء حسابات مكثفة. موارد الخادم الحسابية محدودة، لذلك سيوقَف أيّ برنامج يقدّمه المستخدم بعد بضع ثوانٍ من بدء تنفيذه، فوقت التنفيذ المسموح به يكفي عادة للاختبار والتعلم فقط.

• قرصنة ومهاجمة الخادم الذي يعمل عليه المُصرِّف، أو أيّ جهة خارجية مُستضافة على الشبكة.

  أمثلة على المصرفات الشبكية:

• codepad.org: مُصرِّف مع إمكانية مشاركة الشيفرة، وتحرير الشيفرة بعد التصريف، لكن التحذيرات و الأخطاء لا تعمل بشكل جيد.

• coliru.stacked-crooked.com: مصرّف يمكّنك من أن تحدّد سطر الأوامر، ويتيح لك اختيار أحد المُصرِّفين GCC أو Clang.

• cpp.sh: مُصرِّف يدعم C++‎ 14، لا يسمح لك بتحرير سطر أوامر المصرّف، ولكن يوفّر بعض الخيارات عبر عناصر التحكم في واجهة المستخدم الرسومية.

• gcc.godbolt.org: يوفر قائمة واسعة من إصدارات المُصرِّف، والمعماريات، وهو مفيد للغاية لمن يحتاج إلى التحقّق من عمل الشيفرة في عدّة مُصرِّفات مختلفة. والمصرفات التالية هي بعض المصرّفات المتاحة: GCC و Clang و MSVC ومصرّف Intel و ELLCC و Zapcc، مع توفّر واحد أو أكثر من هذه المصرّفات للمعماريّات ARM و ARMv8 (مثلARM64) و Atmel AVR و MIPS و MIPS64 و MSP430 و PowerPC و x86 و x64. أيضًا، يمكن تعديل وسائط سطر الأوامر الخاص بالمُصرِّف.

• ideone.com: يُستخدم على نطاق واسع لتوضيح سلوك الشيفرة، ويوفر كلًّا من GCC و Clang، لكنّه لا يسمح بتحرير سطر أوامر المصرّف.

• melpon.org/wandbox: يدعم العديد من إصدارات Clang و GNU / GCC.

• onlinegdb.com: بيئة تطوير متكاملة لكن محدودة، تتضمّن محررًا ومُصرِّفًا (gcc) ومنقّحًا (gdb).

• rextester.com: يوفر المُصرِّفات Clang و GCC و Visual Studio لكل من C و C++‎ (إضافة إلى مُصرِّفات خاصّة بلغات أخرى)، ومكتبة Boost.

• tutorialspoint.com/compile_cpp11_online.php: صدفة UNIX متكاملة، مع مصرّف GCC، ومستكشف مشاريع سهل الاستخدام.

• webcompiler.cloudapp.net: مُصرِّف لبرنامج Visual Studio 2015، مُقدّم من قبل Microsoft كجزء من RiSE4fun.

التصريف باستخدام Visual C++‎ (سطر الأوامر)

بالنسبة للمبرمجين الذين اعتادوا على العمل بالمصرّفَين GCC أو Clang، والذين يودّون الانتقال إلى Visual Studio، أو المبرمجين الذين يفضّلون العمل بسطر الأوامر بشكل عام، يمكن استخدام مصرّف Visual C++‎ من سطر الأوامر إلى جانب بيئة تطوير متكاملة (IDE).

وإذا كنت ترغب في تصريف شيفرتك من سطر الأوامر في Visual Studio، فسيكون عليك إعداد بيئة سطر الأوامر، عن طريق فتح:

 Visual Studio Command Prompt/Developer Command Prompt/x86 Native Tools Command Prompt/x64 Native Tools Command Prompt

أو شيئٍا من هذا القبيل (يختلف الأمر حسب إصدار Visual Studio الذي تعمل به)، أو في موجّه الأوامر، من خلال الانتقال إلى المجلّد الفرعي ‎VC‎ في مجلّد التثبيت الخاصّ بالمصرّف (يكون عادةً ‎\Program Files (x86)\Microsoft Visual Studio x\VC‎، حيث يمثّل ‎x‎ رقم الإصدار (مثل ‎10.0‎ لعام 2010، أو ‎14.0‎ لعام 2015)، ثمّ تنفيذ الملفّ ‎VCVARSALL‎ مع مُعامل سطر الأوامر المُحدّد هنا.

لاحظ أنّه على عكس GCC، فإنّ Visual Studio لا يوفّر واجهة للرابط (‎link.exe‎) عبر المصرّف (‎cl.exe‎)، ولكنّها توفّر الرابط (linker) كبرنامج منفصل، ويستدعيه االمُصرِّف عند الإنهاء.

ويمكن استخدام ‎cl.exe‎ و ‎link.exe‎ بشكل منفصل مع عدّة ملفّات وخيارات، أو إخبار ‎cl‎ بتمرير الملفّات والخيارات إلى ‎link‎ إذا كانت المهمّتان ستُنجزان معًا، وستُترجم خيارات الربط المُحدّدة لـ ‎cl‎ إلى خيارات خاصة بـ ‎link‎، وتُمرّر الملفات غير المُعالجة بواسطة ‎cl‎ مباشرة إلى الرابط ‎link‎.

انظر هذه الصفحة للمزيد عن وسائط ‎link‎.

لاحظ أنّ الوسائط التي تخصّ ‎cl‎ حسّاسة لحالة الأحرف، وذلك على خلاف وسائط ‎link‎، وأن بعض الأمثلة التالية تستخدم المتغيّر "current directory" الخاصّ بصدفة (shell) ويندوز، ‎%cd%‎، عند تحديد أسماء المسار المطلق (absolute path names)، ويُوسَّع هذا المتغيّر إلى مجلّد العمل الحالي (current working directory).

وفي سطر الأوامر، سيكون هو المجلّد الذي كنت تستخدمه عند تشغيل ‎cl‎، وهو محدَّد في موجّه الأوامر - command prompt - افتراضيًا (مثلًا، في موجّه الأوامر ‎C:\src>‎، فإنّ ‎%cd%‎ سيكون ‎C:\src\‎).

يمكنك تصريف وربط ملف تنفيذي غير مُحسَّن (unoptimised executable) بافتراض أنّ هناك ملفّا مصدريًا واحدًا يُسمّى ‎main.cpp‎ في المجلد الحالي، وهذا مفيد في مرحلة التطوير الأولي والتنقيح، عبر استخدام أيٍّ ممّا يلي:

cl main.cpp
// "main.obj" إنشاء ملف
// "main.obj" إجراء الربط مع
// "main.exe" إنشاء الملف القابل للتنفيذ

cl /Od main.cpp

في المثال السابق، سيتصرف cl /Od main.cpp كسابقه، لكن يكون "Od/" هو خيار "Optimisation: disabled"، ويكون الخيار الافتراضي عند عدم تحديد أي من خيارات "O/".

بافتراض أنّ هناك ملفًّا مصدريًا إضافيًا " niam.cpp " في نفس المجلّد، فستنشئ الشيفرة التالية الملفين "main.obj" و "niam.obj"، ثم يجري الربط معهما، ومن ثم ينشئ الملف التنفيذي "main.exe":

cl main.cpp niam.cpp

يمكنك أيضًا استخدام محارف البدل (wildcards)، ستنشئ الشيفرة التالية ملف كائن "main.obj" إضافة إلى ملف كائن لكل ملف cpp. في المجلد التالي: "%cd%\src" ثم تُجري الربط مع "main.obj" وكل ملف كائن مُنشأ، وستكون كل ملفات الكائن في المجلد الحالي، ثم تولِّد ملف main.exe.

cl main.cpp src\* .cpp

لإعادة تسمية الملف القابل للتنفيذ أو نقله، استخدم أحد الخيارات التالية:

cl /o name main.cpp
// "name.exe" تولد ملف قابل للتنفيذ
cl /o folder\ main.cpp
// "%cd%\folder" في المجلد "main.exe" إنشاء ملف
cl /o folder\name main.cpp
// "%cd%\folder" في المجلد "main.exe" إنشاء ملف
cl /Fename main.cpp
// "/o name" مثل
cl /Fename main.cpp
// "/o folder\" مثل
cl /Fefolder\name main.cpp
//  "/o folder\name" مثل

يمرِّر كلٌّ من ‎/o‎ و ‎/Fe‎ معاملاتِهما (دعنا نسميها ‎o-param‎) إلى ‎link‎ على شكل ‎/OUT:o-param‎، مع إلحاق الامتداد المناسب (بشكل عام ‎.exe‎ أو ‎.dll‎) لتسمية ‎o-param‎ بما يُناسب، في حين أنّ لـ ‎/o‎ و ‎/Fe‎ نفس الوظيفية - على حدّ علمي - إلّا أنّ الأخير هو المفضل في Visual Studio.

لقد أصبحت ‎/o‎ مهمَلة، ويبدو أنّها تًقدّم بشكل أساسي للمبرمجين الذين اعتادوا العمل بالمصرّفَين GCC و Clang. لاحظ أنّه على الرغم من أنّ المسافة الفارغة بين ‎/o‎ واسم المجلد المحدّد اختيارية، إلا أنه لا يمكن وضع مسافة بيضاء بين ‎/Fe‎ واسم المجلد المحدّد.

بالمثل، يمكن إنشاء ملف تنفيذي مُحسّن (لاستخدامه في مرحلة الإنتاج) على النحو التالي: سنحسِّن حجم الملف التنفيذي في السطر الأول لكن قد يكون هذا على حساب سرعة التنفيذ، أما في السطر الثاني فيحسِّن سرعة البرنامج، لكن ربما يجعل هذا حجم الملف أكبر.

cl /O1 main.cpp
cl /O2 main.cpp

هنا ننشئ ملفات خاصة لتحسين البرنامج، مما يسمح لسطر الأوامر أن يأخذ كل وحدات الترجمة في حسبانه خلال عملية التحسين، وسيمرر خيار توليد شيفرة الرابط-الوقت (Link-Time Code Generation) أو LTCG/، إلى الرابط LINK، ليخبره باستدعاء سطر الأوامر خلال مرحلة الربط لإجراء تحسينات إضافية. وينبغي ربط كائن الملف المُنشأ مع LTCG/ في حال عدم إجراء الربط في ذلك الوقت، كما يمكن استخدامها مع خيارات التحسين الأخرى في سطر الأوامر، …

cl /GL main.cpp other.cpp

أخيرًا، لإنتاج ملف تنفيذي مُحسَّن لأجل منصّة معيّنة (لاستخدامه في الإنتاج على جهاز ذي معمارية معيّنة)، فعليك اختيار موجّه الأوامر المناسب، أو مُعامل ‎VCVARSALL‎ المناسب للمنصّة المُستهدفة. ويجب أن يرصُد الرابط (‎link‎) المنصّة المطلوبة من ملفّات الكائن؛ وإلّا، فعليك استخدام الخيار ‎/MACHINE‎ لتعريف المنصّة المُستهدفة بشكل صريح. مثال: إذا أردت التصريف للتنفيذ على معمارية 64 بت، وتعذر على الرابط LINK أي يرى المنصة المستهدفة:

cl main.cpp / link / machine: X64

سينتج أيًا مما سبق ملفًا تنفيذيًا يحمل الاسم المحدّد من قِبل ‎/o‎ أو ‎/Fe‎، وفي حالة عدم توفير أيّ منهما، سيحمل اسمًا مطابقًا للملف المصدري الأول أو ملفِّ الكائن المحدّد للمُصرِّف.

cl a.cpp b.cpp c.cpp
// "a.exe" إنشاء
cl d.obj a.cpp q.cpp
// "d.exe" إنشاء
cl y.lib n.cpp o.obj
// "n.exe" إنشاء
cl / o yo zp.obj pz.cpp
// "yo.exe" إنشاء

لتصريف الملفّات دون ربط:

cl / c main.cpp
// "main.obj" إنشاء ملف

تخبر الشيفرةُ السابقة سطرَ الأوامر ‎cl‎ بالخروج دون استدعاء ‎link‎، وتنتج ملفّ كائن يمكن ربطه لاحقًا بالملفّات الأخرى لإنتاج ملف ثنائي. في الشيفرة التالية، ينشئ السطر الأول ملف الكائن niam.obj، ويجري الربط مع niam.obj و main.obj، ثم ينشئ الملف التنفيذي main.exe. ويجري السطر الثاني ربطًا مع niam.obj و main.obj، ثم ينشئ الملف التنفيذي main.exe.

cl main.obj niam.cpp

link main.obj niam.obj

هناك مُعاملات أخرى مهمّة لسطر الأوامر، ومن المفيد جدًا معرفتها، منها ما يلي:

• cl /EHsc main.cpp: يشير EHsc إلى أنه لن تُمسك إلا اعتراضات ++C القياسية، وأن دوال C الخارجية لن ترفع اعتراضات (exceptions). يوصى بهذا المعامل لمن يريد كتابة شيفرة محمولة ومتعددة المنصات.

• cl /clr main.cpp: يشير clr/ إلى أن الشيفرة يجب أن تُصرَّف لاستخدام اللغة المشتركة لوقت التشغيل، وهي آلة وهمية خاصة بإطار عمل NET.، وتسمح باستخدام لغة C++/CLI الخاصة بميكروسوفت إضافة إلى سطر أوامر ++C، وتنشئ ملفًا تنفيذيًا يتطلب NET. ليعمل.

• cl /Za main.cpp: يشير Za/ إلى وجوب تعطيل إضافات (Extensions) ميكروسوفت، وأن الشيفرة يجب أن تُصرَّف وفق مواصفات ISO للغة ++C حصرًا، وهذا ضروري لضمان محمولية البرنامج.

• cl /Zi main.cpp: يولد Zi/ ملف قاعدة بيانات PDB للبرنامج من أجل استخدامه عند تنقيح برنامج ما دون التأثير على مواصفات التحسين، ويُمرَّر خيار DEBUG/ إلى الرابط LINK.

• cl /LD main.cpp: يخبر LD/ سطرَ الأوامر أن يضبط LINK كي يولد ملف DLL بدلًا من ملف تنفيذي، وسينتج الرابط ملف DLL إضافة إلى ملفي EXP و LIB لاستخدامهما عند الربط. مرر ملف LIB المرتبط بملف DLL إلى سطر الأوامر أو الرابط عند تصريف تلك البرامج، وذلك لاستخدام الأخير في برامج أخرى.

• cl main.cpp /link /LINKER_OPTION: يمرر link/ كل ما بعده إلى الرابط مباشرة دون تحليل. استبدل LINKER_OPTION/ بخيارات الرابط التي تريد.

بالنّسبة للذين لديهم خبرة في التعامل مع اليونكسات وأشباهها، و/أو GCC / Clang و ‎cl‎ و ‎link‎، وأدوات سطر أوامر Visual Studio الأخرى، يمكنهم أن يقبلوا المُعاملات المُحدّدة باستخدام الواصلة - (مثل ‎-c‎) بدلًا من الشرطة المائلة (مثل ‎/c‎). إضافة إلى ذلك، يتعرّف نظام ويندوز على الشرطة المائلة العكسية \ (backslash) أو الأمامية / (slash) ويعدّهما فواصل صالحة للمسارات، لذلك يمكن استخدام المسارات التي على نمط يونكس وما شابهه.

يسهّل هذا تحويل أسطر أوامر المصرّف من ‎g++‎ أو ‎clang++‎ إلى ‎cl‎، أو العكس، بالحد الأدنى من التغييرات.

g++ - o app src / main.cpp
cl - o app src / main.cpp

ستحتاج إلى البحث عن أوامر مكافئة في توثيق المصرّف الذي تستخدمه و/أو في مواقع توثيق أخرى، وذلك عند محاولة نقل سطور الأوامر التي تستخدم خيارات معقّدة لـ ‎g++‎ أو ‎clang++‎.

وإن احتجت إلى استخدام ميزات لغة معيّنة في شيفرتك، فيلزم استخدام إصدار محدّد من MSVC. ومن الممكن في Visual C++‎ 2015 التحديث 3 اختيار إصدار المعيار الذي تريد اعتماده عند التصريف عبر الراية ‎/std‎، والقيمُ الممكنةُ هي ‎/std:c++14‎ و ‎/std:c++latest‎ (ستتبعُهما ‎/std:c++17‎ قريبًا).

ملاحظة في الإصدارات القديمة من هذا المُصرِّف، كانت بعض رايات المزايا متوفرة، بيْد أنّها كانت في الغالب تُستخدم لمعاينة الميزات الجديدة.

التصريف باستخدام Clang

بما أن الواجهة الأمامية لمصرّف Clang مُصمّمة لتكون متوافقة مع GCC، فإنّ معظم البرامج التي يمكن تصريفها عبر GCC ستُصرَّف كذلك عند استبدال ‎clang++‎ بـ‎g++‎ في برامج البناء النصية (build scripts)، وفي حال عدم إعطاء ‎-std=version‎، فسيُستخدَم الإصدار gnu11.

يمكن لمستخدمي ويندوز الذين اعتادوا على MSVC استبدال ‎clang-cl.exe‎ بـ ‎cl.exe‎. واعلم أن clang يحاول بشكل افتراضي أن يكون متوافقًا مع أحدث إصدار مُثبّت من MSVC. ويمكن استخدام clang-cl عبر تغيير ‎Platform toolset‎ في خاصّيات المشروع، وذلك عند التصريف باستخدام visual studio.

وفي كلتا الحالتين، سيكون clang متوافقًا عبر واجهته الأمامية وحسب، لكنه سيحاول أيضًا بناء ملفات ثنائية متوافقة. كذلك يجب على مستخدمي clang-cl أن ينتبهوا إلى أنّ التوافق مع MSVC ليس كاملًا.

لاستخدام clang أو clang-cl، يمكن استخدام التثبيت الافتراضي على توزيعات محدّدة من Linux، أو تلك المُجمَّعة في بيئات التطوير المتكاملة - IDEs - (مثل XCode على Mac). أما بالنسبة للإصدارات الأخرى من هذا المُصرِّف، أو في المنصّات التي لم يُثبّت عليها، فيمكن تنزيله من صفحة التنزيل الرسمية.

إذا كنت تستخدم CMake لبناء شيفرتك، فيمكنك تبديل االمُصرِّف عادة عن طريق تعيين متغيّرَي البيئة ‎CC‎ و ‎CXX‎ على النحو التالي:

mkdir build
cd build
CC=clang CXX=clang++ cmake ..
cmake --build .

عملية التصريف في C++‎

بعد تطوير برنامج بلغة C++‎، فإنّ الخطوة التالية هي تصريف ذلك البرنامج قبل تشغيله. والتصريف (compiling) هو العملية التي تحوّل البرنامج المكتوب بلغة قابلة للقراءة البشرية، مثل C و C++‎ وغيرهما، إلى شيفرة الآلة، وهي شيفرة يمكن أن تُفهمها وحدة المعالجة المركزية مباشرة. على سبيل المثال، إذا كان لديك ملفّ مصدَري مكتوب بلغة C++‎ باسم prog.cpp، وقمت بتنفيذ الأمر compile …

g++ -Wall -ansi -o prog prog.cpp

ستحدث 4 مراحل رئيسية عند إنشاء ملف تنفيذي من الملف المصدري.

1. يأخذ معالج C++‎ الأولي ملفّ الشيفرة المصدرية ويتعامل مع الترويسات (include#)، ووحدات الماكرو (‎#define‎) وموجّهات المعالج الأخرى.
2. تُصرّف شيفرة C++‎ المصدرية المُوسّعة التي تم إنتاجها من قبل معالج C++‎ الأوّلي إلى لغة التجميع (assembly) المناسبة للمنصّة.
3. تُصرَّف الشيفرة المجمّعة التي تم إنتاجها بواسطة المصرّف إلى كائن شيفرة (object code) مناسب للمنصة.
4. يُربط ملفّ كائن الشيفرة المُنتج من قبل المجمّع مع ملفّات كائنات الشيفرة الخاصة بمكتبات الدوال المُستخدمة، وذلك لإنتاج مكتبة أو ملف قابل للتنفيذ.

المعالجة الأولية Preprocessing

يُعالج المعالج الأولي تعليمات المعالج، مثل ‎#include و ‎#define، وهو غير واعٍ بصيغة C++‎، لذا يجب توخّي الحذر عند استخدامه.

يعمل المعالج الأوّلي على ملفّ ++C مصدري واحد عن طريق استبدال محتوى الملفّات المناسبة (والتي تكون عادة مجرّد تصريحات) بتعليمات ‎#include، ويستبدل وحدات الماكرو (‎#define)، ويختار عدة أجزاء من النص بحسب تعليمات ‎#if و ‎#ifdef و ‎#fndef.

يعمل المعالج الأوّلي على مجموعة من وحدات المعالجة الأوّلية (preprocessing tokens)، ويُعُرِّف استبدال الماكرو على أنّه استبدال مقاطع بمقاطع أخرى (يتيح المُعامل ## دمجَ شيفرَتين إذا كان ذلك مناسبًا).

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

قد تنتج بعض الأخطاء في هذه المرحلة عند استخدام التعليمتين #if و ‎#error. ونستطيع إيقاف العملية في مرحلة المعالجة الأولية باستخدام راية المصرّف أدناه:

g++ -E prog.cpp

التصريف

تُجرى خطوة التصريف على كل خرج من مخرجات المعالج الأوّلي (Preprocessor)، ويحلّل االمُصرِّف شيفرة C++‎ المصدرية الخالصة - دون أي تعليمات للمعالج الأولي الآن- ثمّ يحوّلها إلى شيفرة المجمّع، ثم يستدعي الواجهة الخلفية الأساسية (underlying backend)، وهي المجمّع في سلسلة الأدوات، التي تجمّع تلك الشيفرة وتحوّلها إلى شيفرة الآلة، وتنتج ملفًّا ثنائيًا وفق تنسيق معيّن (مثل ELF أو COFF أو a.out …).

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

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

يمكن وضع ملفات الكائنات الناتجة في أرشيفات خاصة تسمّى المكتبات الساكنة (static libraries)، لتسهيل استخدامها لاحقًا، ويُبلَّغ في هذه المرحلة عن أخطاء المصرّف "المعتادة"، مثل أخطاء الصيغة، أو أخطاء فشل تحليل التحميل الزائد.

لإيقاف العملية بعد خطوة التصريف، يمكن استخدام الخيار ‎-S:

g++ -Wall -ansi -S prog.cpp

التجميع Assembling

ينشئ المجمّع شيفرة الكائن، وقد ترى على نظام UNIX ملفّات ذات لاحقة ‎.o (أو .OBJ على MSDOS) للدلالة إلى ملفات كائنات الشيفرَة (object code files).

في هذه المرحلة، يحوّل المجمّع تلك الملفّات من شيفرة مُجمَّعة (assembly code) إلى تعليمات على مستوى الآلة، كما سيكون الملفُّ المُنشأ كائنَ شيفرة قابلة للنقل (relocatable object code)، ومن ثم ستنشئ مرحلةُ التصريف برنامجَ الكائن القابل للنقل، ويمكن استخدام هذا البرنامج في مواضع أخرى دون الحاجة إلى إعادة تصريفه مرّة أخرى.

لإيقاف العملية بعد خطوة التجميع، استخدم الخيار‎-c:

g++ -Wall -ansi -c prog.cpp

الربط Linking

الرابط (Linker) هو الذي ينتج مخرجات التصريف النهائية من كائنات الملفّات التي أنتجها المجمّع (Assembler)، وقد تكون المُخرجات إمّا مكتبة مشتركة (أو ديناميكية، رغم تشابه الأسماء، إلا أنّها تختلف عن المكتبات الساكنة المذكورة آنفًا)، أو يمكن أن تكون ملفّا تنفيذيًا.

ويربط جميع الكائنات عن طريق استبدال العناوين الصحيحة بالمراجع التي تشير إلى رموز غير مُعرَّفة (undefined symbols). يمكن تعريف تلك الرموز في ملفّات كائنات أخرى أو في مكتبات أخرى، وإذا عُرِّفت في مكتبات غير المكتبة القياسية، فعليك إخبار الرابط بذلك.

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

التصريف عبر Code::Blocks (واجهة رسومية)

1. نزِّل Code::Blocks وثبِّته، وإذا كنت تستخدم ويندوز فاحرص على اختيار الملفّ الذي يحتوي اسمُه على ‎mingw‎، إذ لا تثبّت الملفّات الأخرى أي مُصرِّفات.

2. افتح Code::Blocks وانقر على "Create a new project":

3. اختر "Console application" وانقر على "Go":

4. انقر على"Next"، واختر "C++‎"، انقر على "Next"، اختر اسمًا لمشروعك، واختر مجلدًا لحفظه، ثمّ انقر على "Next" ثمّ على "Finish".

5. يمكنك الآن تعديل وتصريف شيفرتك، ستجد شيفرة افتراضية تطبع السلسلة النصية "Hello world!" في سطر الأوامر. اضغط على أحد الأزرار الثلاثة compile/run في شريط الأدواتل تصريف و/أو تشغيل البرنامج:

للتصريف دون تشغيل، اضغط على ، وللتشغيل دون التصريف مرّة أخرى، اضغط على ، وللتصريف ثمّ التشغيل اضغط على .

تصريف وتشغيل البرنامج الافتراضي "مرحبا العالم!" سيُنتِج الخرج التالي:

مواصفات الربط Linkage specifications

تخبر مواصفات الربط (linkage specification) المُصرِّفَ بأن يصرِّف التصريحات بطريقة تسمح بربطها بالتصريحات المكتوبة بلغة أخرى، مثل C.

معالج الإشارات الخاصّ بأنظمة التشغيل المشابهة ليونيكس

بما أن معالج الإشارة (signal handler) يُستدعى عن طريق النواة (kernel) باستخدام صيغة الاستدعاء في لغة C، فيجب أن نطلب من االمُصرِّف أن يستخدم تلك الصيغة عند تصريف الدالّة.

volatile sig_atomic_t death_signal = 0;
extern "C" void cleanup(int signum) {
    death_signal = signum;
}
int main() {
    bind(...);
    listen(...);
    signal(SIGTERM, cleanup);
    while (int fd = accept(...)) {
    if (fd == -1 && errno == EINTR && death_signal) {
        printf("Caught signal %d; shutting down\n", death_signal);
        break;
        }
// ...
    }
}

إنشاء مكتبة بلغة C متوافقة مع C++‎

يمكن في العادةً تضمين ترويسات مكتبة C في برامج C++‎، لأنّ معظم التصريحات صالحة في كلا اللغتين. على سبيل المثال، انظر ملف ‎foo.h‎ التالي:

typedef struct Foo {
    int bar;
}
Foo;
Foo make_foo(int);

سيصرَّف تعريف ‎make_foo‎ بشكل منفصل ويُوزّع مع الترويسة على هيئة كائن.

يمكن لبرنامج C++‎ أن يُضمِّن ملف الترويسة ‎foo.h‎ عبر التعبير ‎#include <foo.h>‎، لكن لن يستطيع المُصرِّف أن يعرف أنّ الدالّة ‎make_foo‎ قد عُرِّفت وفق صيغة مكتوبة بلغة C، وسيحاول البحث عنه باسم آخر، وسيفشل في إيجاده.

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

يمكن حلّ هذه المشكلة عبر تغليف (wrap) كافة التصريحات في ترويسة في كتلة ‎extern "C"‎، انظر ..

#ifdef __cplusplus
extern "C" {
#endif
typedef struct Foo {
int bar;
} Foo;
Foo make_foo(int);
#ifdef __cplusplus
} /* "extern C" نهاية الكتلة */
#endif

والآن، عند تضمين ‎foo.h‎ من برنامج C، سيظهر كتصريح عادي، أمّا عند تضمين ‎foo.h‎ من برنامج مكتوب بلغة C++‎، فسيكون ‎make_foo‎ داخل كتلة ‎extern "C"‎، وسيعرف المصرّفُ كيف يبحث عن الأسماء، وسيستخدم صيغة الاستدعاء في C.

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

ترجمة -بتصرّف- للفصل Chapter 138: Compiling and Building والفصل Chapter 134: Linkage specifications من كتاب C++ Notes for Professionals

محدّدات أصناف التخزين هي كلمات مفتاحية يمكن استخدامها في التصريحات، ولا تؤثر على نوع التصريح لكنها تعدّل الطريقة التي تُخزّن بها الكيانات.

extern

محدّدُ صنف التخزين ‎extern‎ يستطيع التصريحَ بإحدى الطرق الثلاث التالية، وذلك وفقًا للسياق، فمثلًا:

1. يمكن استخدامه للتصريح عن متغيّر دون تعريفه، يُستخدَم عادة في ملفات الترويسات الخاصة بالمتغيّرات التي تُعرّف في ملف تنفيذ منفصل.

// نطاق عام
int x; // بالقيمة الافتراضية x تعريف: سيهيأ
extern int y; // معرَّف في مكان آخر، غالبًا في وحدة ترجمة أخرى y :تصريح.
extern int z = 42; // أيّ تأثير هنا "extern" تعريف: ليس للكلمة المفتاحية

2. إعطاء ارتباط خارجي (external linkage) لمتغيّر في نطاق فضاء الاسم، حتى لو كانت الكلمتان المفتاحيتان ‎const‎ و ‎constexpr‎ تتسبّبان في إنشاء ارتباط داخلي.

// النطاق العام
const int w = 42; // C وخارجي في ،C++ ارتباط داخلي في
static
const int x = 42; // C++ و C ارتباط داخلي في كل من
extern
const int y = 42; // C++ و C ارتباط خارجي في كل من
namespace {
    extern
    const int z = 42; // ارتباط داخلي لأنّه في فضاء اسم غير مُسمّى
}

3. إعادة التصريح (redeclaring) عن متغيّر في نطاق الكتلة إن صُرِّح عنه مسبقًا عبر الارتباط (linkage). أما خلاف ذلك، سيُصرّح عن متغيّر جديد عبر الارتباط، وسيكون عضوًا في أقرب فضاء اسم محيط.

// النطاق العام
namespace {
    int x = 1;
    struct C {
        int x = 2;
        void f() {
            extern int x; // x إعادة التصريح عن
            std::cout << x << '\n'; // طباعة 1 وليس 2
        }
    };
}
void g() {
    extern int y; // العامّة المُعرّفة في موضع آخر y ارتباط خارجي، ويشير إلى قيمة y لدى
}

يمكن أيضًا التصريح عن الدالّة على أنها ‎extern‎، لكنّ هذا ليس له أيّ تأثير وإنّما يُستخدم في العادةً كتلميح للقارئ بأنّ الدالّة المُصرَّح عنها هنا ستعُرَّف في وحدة ترجمة أخرى. ففي المثال التالي، يكون ()void f تصريحًا لاحقًا يعني أن f ستُعرَّف في وحدة الترجمة هذه، أما ()extern void g ليس تصريحًا لاحقًا، مما يعني أن g تُعرَّف في وحدة ترجمة أخرى، انظر:

void f(); 
extern void g(); 

في الشيفرة أعلاه، في حال التصريح عن ‎f‎ مع ‎extern‎ والتصريح عن ‎g‎ بدون ‎extern‎، لن يؤثر ذلك على صحة أو دلالات البرنامج، ولكن من المحتمل أن يربك القارئ.

register

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

++‎>

register هو محدّد صنف تخزين يخبر االمُصرِّف أنّ المتغيّر سيُستخدَم بكثرة، وتأتي الكلمة "register" من حقيقة أن المُصرِّف قد يختار تخزين هذا المتغيّر في سجل وحدة المعالجة المركزية (CPU register) لتسريع الوصول إليه. وقد أُهمِلت بدءًا من الإصدار C++‎ 11.

register int i = 0;
while (i < 100) {
    f(i);
    int g = i * i;
    i += h(i, g);
}

يُمكن تعريف كلٍّ من المتغيّرات المحلية ومُعامِلات الدوالّ بالكلمة المفتاحية ‎register‎، ولا تضع C++‎ قيودًا على ما يمكن فعله بالمتغيّرات المعرّفة بـ ‎register‎، على عكس لغة C. فكثلًا، يجوز أخذ عنوان متغيّر مصرّح عنه بـ ‎register‎، لكنّ هذا قد يمنع المُصرِّف من تخزين مثل هذا المتغيّر في السجل (register).

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

الكلمة المفتاحية ‎register‎ غير مستخدمة ومحفوظة، ولا ينبغي استخدامها.

static

لدى محدّد التخزين ‎static‎ ثلاث معانٍ مختلفة.

1. يعطي ارتباطًا داخليًا لمتغيّر أو دالّة مُصرَّح عنها في نطاق فضاء الاسم.

// دالة داخلية، لا يمكن الارتباط بها
static double semiperimeter(double a, double b, double c) {
    return (a + b + c) / 2.0;
}
// التصدير إلى العميل
double area(double a, double b, double c) {
    const double s = semiperimeter(a, b, c);
    return sqrt(s * (s - a) * (s - b) * (s - c));
}

2. تصرّح بأنّ المتغيّر له مدة تخزين ساكنة - static storage duration - (ما لم تكن خيطًا محليًا ‎thread_local‎)، ومتغيرات نطاق فضاء الاسم تكون ساكنة ضمنيًا، وتُهيّأ المتغيّرات المحلية الساكنة مرّة واحدة فقط، إذ يمرّ التحكّم في المرّة الأولى عبر تعريفها، ولا تُدمَّر بعد الخروج من نطاقها.

void f() {
    static int count = 0;
    std::cout << "f has been called " << ++count << " times so far\n";
}

3. عند تطبيقها على تصريح عن عضو صنف (class member)، فإنّها تجعل ذلك العضو ساكنًا.

struct S {
    static S* create() {
        return new S;
    }
};
int main() {
    S* s = S::create();
}

لاحظ أنّه إن كان العضو ساكنًا، ستَنطبق النقطتان 2 و 3 في نفس الوقت، إذ تضع الكلمة المفتاحية ‎static‎ عضو الصنف في عضو بيانات ساكن (static data member)، كما تجعله أيضًا في متغيّر ذي مدة تخزين ساكنة (static storage duration).

auto

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

يصرّح هذا المحدّد بأنّ المتغيّر لديه مدة تخزين آلية (automatic storage duration)، وهو غير ضروري نظرًا لأنّ مدة التخزين التلقائي هي الإعداد الافتراضي في نطاق الكتلة، كما لا يُسمح باستخدام المحدّد auto في نطاق فضاء الاسم.

void f() {
    auto int x;
    auto y;
auto int z; 

في المثال السابق، auto int x تكافئ int x، ولا تجوز auto y في ++C لكنها جائزة في C89، كذلك لا تجوز auto int z، إذ لا يمكن أن تكون متغيرات نطاق فضاء الاسم آلية.

تغيّر معنى ‎auto‎ في الإصدار C++‎ 11 بشكل كامل، ولم تعد محدّدًا للتخزين، وإنّما صارت تُستخدم في استنتاج الأنواع.

mutable

mutable هو محدّدٌ يمكن تطبيقه على تصريح عضو بيانات من صنف غير ساكن (non-static) وغير مرجعي (non-reference)، والعضو القابل للتغيير في صنفٍ لا يكون غيرَ ثابتٍ حتى لو كان الكائن ثابتًا.

class C {
    int x;
    mutable int times_accessed;
    public:
        C(): x(0), times_accessed(0) {}
    int get_x() const {
        ++times_accessed; // لا بأس: يمكن للدوال التابعة الثابتة أن تعدّل أعضاء البيانات غير الثابتة
        return x;
    }
    void set_x(int x) {
        ++times_accessed;
        this -> x = x;
    }
};

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

أضيف معنى ثانٍ للكلمة المفتاحية ‎mutable‎ في C++‎ 11، فعندما تتبع قائمة المُعاملات الخاصة بتعبير لامدا، فإنها تقمع المؤهّل الثباتي ‎const‎ الضمني الموجود في مُعامل استدعاء لامدا (lambda's function call operator). ولذلك يمكن لتعابير لامدا القابلة للتغيير (mutable) أنّ تعدّل قيم الكيانات التي حصلت عليها عن طريق النسخ.

std::vector < int > my_iota(int start, int count) {
    std::vector < int > result(count);
    std::generate(result.begin(), result.end(),
        [start]() mutable {
            return start++;
        });
    return result;
}

لاحظ أنّ ‎mutable‎ لا تُعدُّ محدّدَ صنف تخزين إذا استخدِمَت بهذه الطريقة لتشكيل تعابير لامدا تقبل للتغيير (أي mutable).

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

ترجمة -بتصرّف- للفصل Chapter 133: Storage class specifiers من كتاب C++ Notes for Professionals

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

تقنية RAII: تخصيص الموارد يكافئ التهيئة

تقنية RAII وتدعى اكتساب أو تخصيص الموارد هي تهيئة (Resource Acquisition Is Initialization) هو مصطلح شائع في إدارة الموارد، ويستخدم المؤشّرات الذكية (smart pointer) لإدارة الموارد في حالة الذاكرة الديناميكية، وتُمنح الموارد المكتسبة ملكية مؤشر ذكي أو مدير موارد مكافئ مباشرة عند استخدام أسلوب RAII. ولا يمكن الوصول إلى المورد إلا من خلال ذلك المدير، مما يمكِّن المدير من تتبّع مختلف العمليات الجارية على المورد.

على سبيل المثال، تحرِّر الكائنات من النوع ‎std::auto_ptr‎ مواردها تلقائيًا عندما تخرج عن النطاق، أو عندما تُحذف بطريقة أخرى.

#include <memory>
#include <iostream>
using namespace std;
int main() {
    {
        auto_ptr ap(new int(5)); 
        cout << *ap << endl; // تطبع 5
    } 
}

في المثال السابق، كان المورد هو الذاكرة الديناميكية، ودُمِّر auto-ptr ثم حُرِّر مورده تلقائيًا.

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

كانت المشكلة الرئيسية في كائنات std::auto_ptr أنّها لا يمكن أن تُنسخ دون نقل الملكية:

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

int main() {
    auto_ptr ap1(new int(5));
    cout << *ap1 << endl; // تطبع 5
    auto_ptr ap2(ap1); 
    cout << *ap2 << endl; // تطبع 5
    cout << ap1 == nullptr << endl;
}

تفسير الشيفرة السابقة:

• (auto_ptr ap2(ap1: تنسخ ap2 من ap1 وتنتقل الملكية إلى ap2.
• cout << ap1 == nullptr << endl: تطبع القيمة 1، ويخسر ap1 ملكيته للمورد.

وبسبب دلالات النسخ الغريبة تلك فإنّ هناك قيودًا على استخدام ‎std::auto_ptr‎، مثل أنها لا يمكن أن تُستخدم في الحاويات، وذلك لمنع حذف الذاكرة مرتين: فإذا كان لدينا كائنين من النوع ‎auto_ptrs‎ يملكان نفس المورد، سيحاول كلا الكائنين تحريره عند تدميرهما.

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

#include <memory>
#include <iostream>
using namespace std;
int main() {
    shared_ptr sp2; {
        shared_ptr sp1(new int(5));    // sp1 إعطاء الملكيّة إلى
        cout << *sp1 << endl        // تطبع 5
        sp2 = sp1;            // يملك كلاهما المورد ،sp1 من sp2 نسخ
        cout << *sp1 << endl;        // تطبع 5
        cout << *sp2 << endl;        // تطبع 5
    }                // الملكية الحصرية للمورد sp2  عن النطاق وتدميره، أصبح لـ sp1 خروج
    cout << *sp2 << endl;
}                // عن النطاق، وتحرير المورد sp2 خروج

القفل Locking

هذا مثال عن قفل سيّء:

std::mutex mtx;
void bad_lock_example()
{
    mtx.lock();
    try
    {
        foo();
        bar();
        if (baz())
        {
            mtx.unlock();    // ينبغي فتح القفل عند كل نقطة خروج
            return;
        }

        quux();
        mtx.unlock();        // يحدث فتح القفل العادي هنا
    }

    catch (...)
    {
        mtx.unlock();        // ينبغي فرض فتح القفل في حال طرح اعتراض
        throw;                // والسماح للاعتراض بالاستمرار
    }
}

تلك طريقة خاطئة لتنفيذ عمليتي القفل والفتح لكائنات المزامنة (mutex)، ولا بدّ أن يتحقّق المُبرمِجُ من أنّ جميع التدفّقات (flows) الناتجة عن إنهاء الدالّة تؤدّي إلَى استدعاء ‎unlock()‎، وذلك للتأكد أنّ فتح القفل باستخدام ‎unlock()‎ سيحرّر الكائن المزامنة الصحيح. وهذه عمليات هشة كما وضحنا أعلاه، لأنّها تتطّلب من المطوّرين متابعة النمط يدويًا. ويمكن حلّ هذه المشكلة باستخدام صنف مُصمّم خصّيصًا لتنفيذ تقنية RAII:

std::mutex mtx;
void good_lock_example()
{
    std::lock_guard<std::mutex > lk(mtx);    // المنشئ يقفل.
    // المدمِّر يفتح!
    // تضمن اللغة استدعاء المدمر.
    foo();
    bar();
    if (baz())
    {
        return;
    }

    quux();
}

‎lock_guard‎ هو قالب صنف بسيط للغاية يستدعي ‎lock()‎ ويمرّر إليه الوسيط المُمرّر إلى مُنشئه ويحتفظ بمرجع إلى ذلك الوسيط، ثمّ يستدعي ‎unlock()‎ على الوسيط في مدمّره، ممّا يعني ضمان فتح قفل mutex عند خروج ‎lock_guard‎ عن النطاق. ولا يهم سبب الخروج عن النطاق سواءً كان ذلك بسبب اعتراض أو عودة مبكّرة، ذلك أن جميع الحالات سيتمّ التعامل معها، وسيفتح القفل بشكل صحيح بغض النظر عن سير البرنامج.

ScopeSuccess

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

نستطيع باستخدام ‎int std::uncaught_exceptions()‎ أن ننفذ إجراءً لم يكن لينفَّذ إلّا في حالة النجاح (عدم رفع اعتراض في النطاق). وقد كانت ‎bool std::uncaught_exception()‎ فيما سبق تسمح برصد العمليّات الجارية لفكّ المكدّس (stack unwinding). انظر:

#include <exception>
#include <iostream>

template < typename F>
    class ScopeSuccess
    {
        private:
        F f;
        int uncaughtExceptionCount = std::uncaught_exceptions();
        public:
            explicit ScopeSuccess(const F &f): f(f) {}

        ScopeSuccess(const ScopeSuccess &) = delete;
        ScopeSuccess &operator=(const ScopeSuccess &) = delete;
        // f() might throw, as it can be caught normally.
        ~ScopeSuccess() noexcept(noexcept(f()))
        {
            if (uncaughtExceptionCount == std::uncaught_exceptions())
            {
                f();
            }
        }
    };
struct Foo
{
    ~Foo()
    {
        try
        {
            ScopeSuccess logSuccess
            {
            []()
                {
                    std::cout << "Success 1\n";
                }
            };
            // نجاح النطاق
            // أثناء فكّ المكدّس Foo حتى في حال تدمير
            // 0 < std::uncaught_exceptions() 
            // std::uncaught_exception() == true
        }

        catch (...) {}

        try
        {
            ScopeSuccess logSuccess
            {
            []()
                {
                    std::cout << "Success 2\n";
                }
            };

تزيد القيمة المعادة من std::uncaught_exceptions، …

            throw std::runtime_error("Failed");  
        }

وتنقص القيمة المعادة من std::uncaught_exceptions …

        catch (...)
        {
        }
    }
};
int main()
{
    try
    {
        Foo foo;
        throw std::runtime_error("Failed");    // std::uncaught_exceptions() == 1
    }

    catch (...)
    {
        // std::uncaught_exceptions() == 0
    }
}

سيكون الخرج:

Success 1

ScopeFail ‏(C++‎ 17)

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

يمكننا تنفيذ إجراء معيّن لا يُنفَّذ إلّا عند الفشل (رفع اعتراض في النطاق) بفضل ‎int std::uncaught_exceptions()‎، وكانت ‎bool std::uncaught_exception()‎ تسمح سابقًا برصد إن كانت هناك عملية جارية لفك المكدّس.

#include <exception>
#include <iostream>

template < typename F>
    class ScopeFail
    {
        private:
            F f;
        int uncaughtExceptionCount = std::uncaught_exceptions();
        public:
            explicit ScopeFail(const F &f): f(f) {}

        ScopeFail(const ScopeFail &) = delete;
        ScopeFail &operator=(const ScopeFail &) = delete;

يجب ألا ترفع ()f وإلا فستستدعى std::terminate، نتابع المثال …

        ~ScopeFail()
        {
            if (uncaughtExceptionCount != std::uncaught_exceptions())
            {
                f();
            }
        }
    };
struct Foo
{
    ~Foo()
    {
        try
        {
            ScopeFail logFailure
            {
            []()
                {
                    std::cout << "Fail 1\n";
                }
            };
            // نجاح النطاق
            // أثناء فكّ المكدّس Foo حتى في حال تدمير
            // 0 < std::uncaught_exceptions() في حال
            // std::uncaught_exception() == true أو سابقا

        }

        catch (...) {}

        try
        {
            ScopeFail logFailure
            {
            []()
                {
                    std::cout << "Failure 2\n";
                }
            };

تزيد القيمة المعادة من std::uncaught_exceptions ….

            throw std::runtime_error("Failed"); 
        }

تقل القيمة المعادة من std::uncaught_exceptions ….

        catch (...)
        {

        }
    }
};
int main()
{
    try
    {
        Foo foo;
        throw std::runtime_error("Failed");    // std::uncaught_exceptions() == 1
    }

    catch (...)
    {
        // std::uncaught_exceptions() == 0
    }
}

سيكون الخرج:

Failure 2

Finally/ScopeExit

إذا لم ترد كتابة أصناف خاصّة للتعامل مع بعض الموارد، فاكتب صنفًا عامًا على النحو التالي:

template < typename Function>
    class Finally final
    {
        public: explicit Finally(Function f): f(std::move(f)) {}
    ~Finally()
        {
            f();
        }    // (1) انظر أدناه
        Finally(const Finally &) = delete;
        Finally(Finally &&) = default;
        Finally &operator=(const Finally &) = delete;
        Finally &operator=(Finally &&) = delete;
        private: Function f;
    };
// عندما يخرج الكائن المُعاد عن النطاق f تنفيذ الدالة
template < typename Function>
    auto onExit(Function && f)
    {
        return Finally<std::decay_t < Function>>
        {
            std::forward<Function> (f)
        };
    }

وهذا مثال على استخدام ذلك الصنف:

void foo(std::vector<int> &v, int i)
{
    // ...
    v[i] += 42;
    auto autoRollBackChange = onExit([ &]()
    {
        v[i] -= 42;
    });
    // ... `foo(v, i + 1)` شيفرة تكرارية
}

ملاحظة (1): يجب أخذ الملاحظات التالية حول تعريف المدمّر في الاعتبار عند التعامل مع الاعتراضات:

Finally() noexcept { f(); }: std::terminate // تُستدعى في حال رفع اعتراض
Finally() noexcept(noexcept(f())) { f(); }  // إلّا في حال رفع اعتراض أثناء فك المكدّس terminate() لا تُستدعى
Finally() noexcept { try { f(); } catch (...) { /* ignore exception (might log it) */} } )
              // لا تُستدعى std::terminate، لكن لا نستطيع معالجة الخطأ (حتى في حالة عدم فك المكدّس

كائنات المزامنة وأمان الخيوط Mutexes & Thread Safety

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

في نهاية العملية، تُخزّن القيمة 2 في المتغيّر بدلًا من 3، ذلك أن الخيط 2 يقرأ المتغيّر قبل أن يُحدِّث الخيط 1 ذلك المتغيّر. ما الحلّ إذن؟ يكون الحل في كائنات المزامنة … .

كائن المزامنة (mutex) هو كائن لإدارة الموارد، ومُصمّم لحل هذا النوع من المشاكل. فعندما يحاول خيط ما الوصول إلى مورد، فإنّه يستحوذ على كائن المزامنة لذلك المورد (resource's mutex). ويحرّر ذلك (releases) الخيطُ كائن المزامنة بمجرّد الانتهاء من العمل على المورد.

وعند استحواذ خيط على كائن مزامنةٍ فإنّ كلّ الاستدعاءات للاستحواذ على ذلك الكائن لن تعود إلى أن يُحرَّر.

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

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

المكتبة std::mutexهي تطبيق كائن المزامنة في C++‎ 11.

#include <thread>
#include <mutex>
#include <iostream>
using namespace std;

void add_1(int& i, const mutex& m) { // الدالة التي ستُنفّذ في الخيط
    m.lock();
    i += 1;
    m.unlock();
}
int main() {
    int
    var = 1;
    mutex m;
    cout << var << endl; // تطبع 1

    thread t1(add_1, var, m); // إنشاء خيط مع وسائط
    thread t2(add_1, var, m); // إنشاء خيط آخر
    t1.join(); t2.join(); // انتظار انتهاء الخيطين

    cout << var << endl; // تطبع 3
}

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

ترجمة -بتصرّف- للفصل Chapter 83: RAII: Resource Acquisition Is Initialization والفصل Chapter 132: Resource Management من كتاب C++ Notes for Professionals

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

إنشاء بيئة بناء باستخدام CMake

ينشئ CMake بيئات البناء للمُصرِّفات أو بيئات التطوير المتكاملة (IDE) انطلاقًا من تعريف مشروع واحد، وسوف توضّح الأمثلة التالية كيفية إضافة ملف CMake إلى برنامج "Hello World" متعدّد المنصات.

تأخذ ملفات CMake دائمًا الاسم "CMakeLists.txt"، ويجب أن تكون موجودة في مجلّد الجذر لكل مشروع، وربما في المجلدات الفرعية أيضا.

هذا مثال على ملف CMakeLists.txt:

cmake_minimum_required(VERSION 2.4)
project(HelloWorld)
add_executable(HelloWorld main.cpp)

يمكنك رؤية البرنامج يعمل مباشرة من هنا.

هذا الملفُّ يخبر أداةَ CMake باسم المشروع، وإصدار الملف المتوقع، وبعض التعليمات الضرورية لتوليد ملف تنفيذي (executable) يُسمّى "HelloWorld"، والذي يتطلب ملف ‎main.cpp‎.

في المثال التالي: أنشئ بيئة بناء للمُصرِّف أو بيئة تطوير متكاملة من سطر الأوامر:

> cmake .

ابن التطبيق بما يلي:

> cmake --build .

تولّد هذه الشيفرة بيئة البناء الافتراضية للنظام وفق نظام التشغيل والأدوات المُثبّتة، حافظ على الشيفرة المصدرية نظيفة من آثار البناء (build artifacts) باستخدام نمط تصميم "خارج المصدر" (out-of-source):

> mkdir build
> cd build
> cmake ..
> cmake --build .

يمكن لـ CMake أيضًا تجريد (abstract) الأوامر الأساسية للصدفة (shell) الخاصة بالمنصة من المثال السابق:

> cmake -E make_directory build
> cmake -E chdir build cmake ..
> cmake --build build

يتضمّن CMake مولدّات لعدد من أدوات البناء الشائعة وبيئات التطوير المتكاملة، ولإنشاء ملفات makefiles لأجل nmake الخاصة بـ Visual Studio:

> cmake -G "NMake Makefiles" ..
> nmake

التصريف باستخدام GNU

GNU Make هو برنامج مخصّص لأتمتة تنفيذ أوامر الصدفة، وينتمي لعائلة برامج Make، ويتمتع Make بشعبية كبيرة لدى مستخدمي أنظمة التشغيل الشبيهة بيونكس وتلك الموافقة لمعايير POSIX، بما في ذلك الأنظمة المشتقة من نواة لينُكس ونظام Mac OSX ونظام BSD، ويتميّز GNU Make بأنّه مرتبط بمشروع جنو الذي يرتبط بدوره بأنظمة التشغيل المبنية على جنو\لينكس الشهير.

هناك إصدارات أخرى من GNU Make متوافقة مع أنظمة تشغيل أخرى، مثل ويندوز و Mac OS X، وهذا البرنامج مستقر للغاية وله أثر تاريخي يبقيه مشهورًا، لهذا يُدرَّس GNU Make إلى جانب لغتي C و C++‎.

القواعد الأساسية

يجب أن تنشئ ملف Makefile في مجلّد المشروع لأجل التصريف بواسطة make. هذا مثال بسيط على ملف Makefile: سنقسم الملف أثناء سرد المثال للشرح …. Makefile

# إعداد بعض المتغيرات لاستخدامها مع الأمر
# g++ أولا، سنحدد المصرف
CXX=g++

# وغيرها g++ ثم نصرّف مع التنبيهات الموصى بها في
CXXFLAGS=-Wall -Wextra -pedantic

# هذا هو ملف الخرج
EXE=app

SRCS=main.cpp

يُستدَعى هذا الهدف عند استدعاء make في سطر الأوامر، وتقول (EXE)$ الموجودة على اليمين أن الهدف all يعتمد على الهدف (EXE)$. لاحظ أنه بما أن هذا هو الهدف الأول، فسيكون الهدف الافتراضي إن استُدعيَت make بدون هدف، نتابع المثال …

all: $(EXE)

# هذا يكافئ
# app: $(SRCS)

(SRCS)$ يمكن فصلها، مما يعني أن هذا الهدف سيعتمد على كل الملفات. لاحظ أن هذا الهدف له متن تابع (method body)، وهو الجزء المزاح بمسافة جدول واحدة (tab) وليس أربع مسافات فارغة. وسينفذ make الأمر التالي عند بناء هذا الهدف:

g++ -Wall -Wextra -pedantic -o app main.cpp

والذي يعني تصريف main.cpp مع التحذيرات، والإخراج إلى الملف app/.، نتابع …

$(EXE): $(SRCS)
@$(CXX) $(CXXFLAGS) -o $@ $(SRCS)

هذا الهدف ينبغي له أن يعكس الهدف all، وإن استدعيْتَ make مع وسيط مثل make clean فسيُستَدعى الهدف gets الموافق له، …

clean:
@rm -f $(EXE)

ملاحظة: تأكد من أن الإزاحات البادئة قد تمت بزر الجدول (tab)، ولا تستخدم 4 مسافات بيضاء من زر Space. وإلا فسيُطلق الخطأ ‎Makefile:10: *** missing separator. Stop.‎.

لتنفيذ هذه الشيفرة من سطر الأوامر، عليك كتابة ما يلي:

$ cd ~/Path/to/project
$ make
$ ls
app main.cpp Makefile
$ ./app
Hello World!
$ make clean
$ ls
main.cpp Makefile

عمليات البناء التزايدية التزايدي Incremental builds

تظهر فائدة make عندما تكثر الملفات، فماذا لو عدّلت الملف a.cpp دون الملف b.cpp؟ لن يكون من الحكمة إذًا أن تعيد تصريف b.cpp، لأنّ ذلك سيُهدر الوقت. في المثال أدناه، لنفرض أن لدينا الهيكل التالي لمجلد:

.
+-- src
|   +-- a.cpp
|   +-- a.hpp
|   +-- b.cpp
|   +-- b.hpp
+-- Makefile

فسيكون هذا ملف Makefile جيد:

CXX=g++
CXXFLAGS=-Wall -Wextra -pedantic
EXE=app
SRCS_GLOB=src/*.cpp
SRCS=$(wildcard $(SRCS_GLOB))
OBJS=$(SRCS:.cpp=.o)
all: $(EXE)
$(EXE): $(OBJS)
@$(CXX) -o $@ $(OBJS)
depend: .depend
.depend: $(SRCS)
@-rm -f ./.depend
@$(CXX) $(CXXFLAGS) -MM $^>>./.depend
clean:
-rm -f $(EXE)
-rm $(OBJS)
-rm *~
-rm .depend
include .depend

مرّة أخرى، لاحظ إزاحات الجدول البادئة. سيضمن ملفّ Makefile الجديد ألّا تصرّف إلّا الملفات التي عُدِّلت، وهذا سيقلّل وقت التصريف.

التوثيق

للحصول على المزيد من المعلومات عن make، راجع التوثيق الرسمي -بالإنجليزية- من مؤسسة البرمجيات الحرة وإجابة dmckee التفصيلية على موقع stackoverflow.

البناء بواسطة SCons

يمكنك بناء شيفرة "Hello World" متعدّدة المنصات باستخدام أداة Scons، وهي أداة بناء برامج تستخدم لغة بايثون.

أولاً، عليك إنشاء ملف يُسمّى ‎SConstruct‎ -سيبحث SCons عن هذا الملف افتراضيًا-، وينبغي أن يكون الملف -للآن- في مجلّد مع الملف ‎hello.cpp‎. اكتب السطر التالي في الملف الجديد:

Program('hello.cpp')

الآن، من سطر الأوامر، نفّذ الأمر ‎scons‎، ينبغي أن ترى شيئًا من هذا القبيل:

$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -o hello.o -c hello.cpp
g++ -o hello hello.o
scons: done building targets.

رغم أن التفاصيل ستختلف وفقًا لنظام التشغيل والمُصرِّف المُستخدم. سيساعدك الصنفان ‎Environment‎ و ‎Glob‎ على إعداد ما يجب بناؤه. على سبيل المثال، سيبني الملف ‎SConstruct‎ الملف التنفيذي hello باستخدام جميع ملفات cpp في مجلد src، كما أن CPPPATH الخاص به سيكون ‎/usr/include/boost‎، كما يحدّد معيار C++‎ 11، انظر:

env=Environment(CPPPATH='/usr/include/boost/',
CPPDEFINES=[],
LIBS=[],
SCONS_CXX_STANDARD="c++11"
)
env.Program('hello', Glob('src/*.cpp'))

Autotools

هي مجموعة من البرامج التي تُستخدَم لإنشاء نظام بناء جنو (GNU Build System) لأجل حزمة برامج معيّنة، وهي حزمة من الأدوات تعمل معًا لإنتاج العديد من موارد البناء، مثل ملفات Makefile -لتُستخدَم مع برنامج GNU Make، لهذا تُعدُّ هذه الحزمة المولّد المعياري لأنظمة البناء. فيما يلي بعض برامج Autotools الأساسية:

• Autoconf.
• Automake (لا تخلط بينها وبين ‎make‎).

والهدف من حزمة Autotools بشكل عام، هو توليد برنامج نصّي متوافق مع يونيكس (Unix-compatible script)، إضافة إلى ملفّ Makefile للسماح للأمر التالي بإنجاز عملية البناء -وكذلك تثبيت- معظم الحُزم:

./configure && make && make install

وترتبط حزمة Autotools على هذا النحو أيضًا ببعض مدراء الحزم (package managers)، خاصة تلك المرتبطة بأنظمة التشغيل التي تتوافق مع POSIX.

Ninja

يوصف نظام بناء Ninja في موقعه بأنه "نظام بناء صغير يركّز على السرعة"، وصُمِّم هذا النظام لكي تُبنى ملفاته بواسطة مولدات ملفات بناء النظام (build system file generators)، ويعتمد أسلوبًا منخفض المستوى (low-level) لبناء الأنظمة، وذلك على عكس مدراء أنظمة البناء عالية المستوى مثل CMake أو Meson.

كُتِب نظام Ninja أساسًا بلغة C++‎ و Python، وقد أُنشِئ كبديل لنظام البناء SCons في مشروع Chromium.

NMAKE (أداة صيانة برامج Microsoft)

NMAKE هي أداة سطر أوامر طوّرتها ميكروسوفت لاستخدامها مع Visual Studio و / أو أدوات سطر أوامر Visual C++‎. ويُنظر إليها على أنها نظام بناء يندرج ضمن مجموعة عائلة Make لأنظمة البناء، ولكنّه يتميّز ببعض الميزات الخاصّة التي تميّزه عن برامج Make الشبيهة بيونكس الأخرى، مثل دعم صياغة مسارات ملفات Windows (والتي تختلف عن مسارات الملفات في يونيكس).

أخطاء المصرف الشائعة (GCC)

مرجعّ غير معرَّف إلى "***"

تحدث أخطاء الرابط (linker) عندما يعجز عن العثور عن رمز مُستخدم، ويحدث هذا غالبًا عند عدم ربط إحدى المكتبات المستخدمة.

• qmake:

LIBS += nameOfLib

• cmake:

TARGET_LINK_LIBRARIES(target nameOfLib)

• استدعاء g++‎:

g++ -o main main.cpp -Llibrary/dir -lnameOfLib

قد ينسى المرء أيضًا تصريف وربط جميع ملفّات ‎.cpp‎ المستخدمة (تحدّد functionModule.cpp الدالّة المطلوبة):

g++ -o binName main.o functionsModule.o

error: '***' was not declared in this scope

يحدث هذا الخطأ في حال استخدام كائن غير معروف.

أخطاء متعلقة بالمتغيّرات

لن تُصرّف الشيفرة التالية، لأن المتغير i غير موجود في نطاق الدالة main:

#include <iostream>
int main(int argc, char *argv[])
{
    {
        int i = 2;
    }
    std::cout << i << std::endl; 
    return 0;
}

الحل:

#include <iostream>
int main(int argc, char *argv[])
{
    {
        int i = 2;
        std::cout << i << std::endl;
    }
    return 0;
}

أخطاء متعلقة بالدوال

يحدث هذا الخطأ غالبًا في حال عدم تضمين الترويسة المطلوبة (على سبيل المثال استخدام ‎std::cout‎ دون ‎#include <iostream>‎). ففي المثال التالي، لن تُصرّف الشيفرة التالية:

#include <iostream>
int main(int argc, char *argv[])
{
    doCompile();
    return 0;
}
void doCompile()
{
    std::cout << "No!" << std::endl;
}

الحلّ:

#include <iostream>
void doCompile(); // تصريح لاحق للدالة
int main(int argc, char *argv[])
{
    doCompile();
    return 0;
}
void doCompile()
{
    std::cout << "No!" << std::endl;
}

أو:

#include <iostream>
void doCompile() // تعريف الدالة قبل استخدامها
{
    std::cout << "No!" << std::endl;
}
int main(int argc, char *argv[])
{
    doCompile();
    return 0;
}

ملاحظة: يفسر المُصرِّف الشيفرة من الأعلى إلى الأسفل (للتبسيط فقط)، لذا يجب التصريح عن كل شيء (أو تعريفه) قبل استخدامه.

fatal error: ***: No such file or directory

يحدث هذا الخطأ عندما يعجز المُصرِّف عن العثور عن ملفّ معيّن (ملف مصدري يستخدم ‎#include "someFile.hpp"‎).

• qmake:

INCLUDEPATH += dir / Of / File

• cmake:

include_directories(dir/Of/File)

• استدعاء g++‎:

g++ -o main main.cpp -Idir/Of/File

عدم التوافقية مع لغة C

سنتحدّث في هذا القسم عن شيفرات C غير المتوافقة مع لغة C++‎ والتي ستعطل مصرّفاتها‎.

الكلمات المفتاحية المحجوزة

هناك كلمات مفتاحية لها غرض خاص في C++‎، فالشيفرة التالية مثلًا جائزة في C، لكن غير جائزة في C++‎.

int class = 5

وإصلاح هذه الأخطاء سهل، فكل ما عليك هو إعادة تسمية المتغيّر.

المؤشّرات ذات النوعية الضعيفة Weakly Typed Pointers

يمكن تحويل المؤشّرات في C إلى النوع ‎void*‎، أما في C++‎ فستحتاج إلى تحويل صريح explicit cast. انظر المثال التالي حيث تكون الشيفرة غير جائزة في C++‎، ولكن جائزة في C:

void* ptr;
int* intptr = ptr;

إضافة تحويل صريح (explicit cast) ستحل المشكلة لكن قد يسبّب مشاكل أخرى.

goto أو switch

لا يجوز في ++C أن تتخطي التهيئة باستخدام ‎goto‎ أو ‎switch‎. انظر المثال التالي حيث تكون الشيفرة صحيحة في C، وغير صحيحة في C++‎:

goto foo;
int skipped = 1;
foo;

قد يتطلب إصلاح هذه الأخطاء إعادة تصميم البرنامج.

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

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

• Chapter 130: Build Systems
• Chapter 139: Common compile/linker errors (GCC)‎
• Chapter 136: C incompatibilities

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

الصحة الثباتية (Const Correctness) أسلوب لتصميم الشيفرات، يعتمد على فكرة أنّه لا ينبغي أن تُتاح إمكانية تعديل نسخة معيّنة -على سبيل المثال الحق في الكتابة- إلّا للشيفرَات التي تحتاج إلى تعديل تلك النسخة، وبالمقابل، فإنّ أيّ شيفرة لا تحتاج إلى تعديل نُسخة ما لن تملك القدرة على تعديلها، أي سيكون لها حق القراءة فقط.

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

يتم ذلك عن طريق إعطاء التوابعِ مؤهلات (const CV-qualifiers)، وعن طريق وسم معاملات المؤشّرات / المراجع بالكلمة المفتاحية ‎const‎.

class ConstCorrectClass {
    int x;
    public:
        int getX() const {
            return x;
        } // الدالة ثابتة: أي أنها لن تعدل النسخة
    void setX(int i) {
        x = i;
    } // غير ثابتة: أي أنها ستعدل النسخة
};
// المعامل ثابت، أي أنّه لن يُعدّل
int const_correct_reader(const ConstCorrectClass& c) {
    return c.getX();
}
// المعامل غير ثابت: سيُعدَّل
void const_correct_writer(ConstCorrectClass& c) {
    c.setX(42);
}
const ConstCorrectClass invariant; // النسخة ثابتة: لن تُعدّل
ConstCorrectClass variant; // النسخة غير ثابتة: يمكن أن تُعدَّل
// …

// صحيح: استدعاء دالة ثابتة غير مُعدِّلة على نسخة ثابتة
const_correct_reader(invariant); 

// صحيح: استدعاء دالة ثابتة غير مُعدِّلة على نسخة قابة للتعديل
const_correct_reader(variant); 

// صحيح: استدعاء دالة ثابتة مُعدِّلة على نسخة قابلة للتعديل
const_correct_writer(variant); 

// خطأ: استدعاء دالة ثابتة مُعدِّلة على نسخة ثابتة
const_correct_writer(invariant);