سي++ (تنطق: سي بلس بلس) (بالإنجليزية: ++C)‏ هي لغة برمجة كائنية، متعددة أنماط البرمجة، مصرفة، سكونية الأنماط. وتضم الكثير من ميزات لغات البرمجة عالية المستوى ومنخفضة المستوى. بدأ تطوير هذه اللغة امتدادًا للغة سي تحت اسم (سي مع الأصناف) من قبل بيارن ستروستروب في مختبرات بل عام 1979 وتم إضافة الكثير من الميزات الأخرى لاحقاً وتغير الاسم عام 1983 ليصبح سي++ من باب النادىبة عبر استخدام معامل الزيادة لجانب اسم لغة سي تأكيداً على أنها «التالي للغة سي».

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

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

بدأت سي++ بصفتها تحسينا للغة سي، أولاً عبر إضافة الأصناف ومن ثم التوابع الظاهرية وتحميل المعاملات الحسابية والوراثة المتعددة والقوالب ومعالجة الاستثناءات بالإضافة إلى ميزات الأخرى. بعد سنوات من التطوير تم تصديق سي++ عام 1998 معيار آيزوذوالاسم ISO/IEC 14882:1998. وفي عام 2003 تم تعديل المعيار وفقاً لوثيقة التسليم التقنية ISO/IEC 14882:2003. يتضمن المعيار الحالي ISO/IEC 14882:2011 مجموعة من الميزات التي تم الاتفاق عليها ونشرها مثل معيار حديث من المنظمة الدولية للمعايير في أيلول 2011 والذي عُرف سابقاً باسم سي++ 11.

التاريخ

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

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

عمل ستروستروب على تطوير مصرف اسمه «سي فرونت» (بالإنجليزية: Cfront)‏ يقوم بتصريف مصدر سي++ إلى مصدر سي مكافئ، وقد قام من خلاله بإضافة بعض الميزات الجديدة إلى لغة سي مثل الأصناف، الأصناف المشتقة، التنميط القوي (بالإنجليزية: strong typing)‏، التضمين (بالإنجليزية: inlining)‏، والقيم الافتراضية. تم طرح أول إصدار تجاري من سي++ في 14 تشرين الأول 1985.

في عام 1983 تم تغيير اسم اللغة من «سي مع الأصناف» إلى سي++ (حيث حتى ++ هومعامل الزيادة بلغة سي) كما تم إضافة مجموعة من الميزات متل التوابع الظاهرية، التحميل الزائد للمعاملات والتوابع، المراجع (بالإنجليزية: references)‏، الثوابت، التحكم بالذاكرة المدار من قبل المستخدم، تحقق محسن من الأنماط، والتعليقات السطرية باستخدام خطين مائلين (//) على نمط لغة البرمجة الأساسية المختلطة. في عام 1985 نُشر الإصدار الأول من كتاب لغة البرمجة سي++ ليُزَود المبرمجين بأحد أبرز المراجع عن هذه اللغة في وقت لم توصّف فيه اللغة بعد معيارا رسميا. عام 1989 نُشر الإصدار 2.0 من الكتاب وعام 1991 نٌشر الإصدار الثاني المحدّث منه. اشتملت الميزات الجديدة على الوراثة المتعددة، الأصناف المجردة (بالإنجليزية: abstract classes)‏، التوابع الأعضاء السكونية (بالإنجليزية: static member functions)‏، التوابع الأعضاء الساكنة (بالإنجليزية: const member functions)‏، والأعضاء المحمية. عام 1990 نُشر دليل سي++ المرجعي التفصيلي (The Annotated C++ Reference Manual) وكان حجر الأساس لمعيار اللغة المستقبلي. اشتملت الميزات اللاحقة على القوالب (بالإنجليزية: templates)‏ والاستثناءات وفضاءات الأسماء وتحويلات جديدة بين الأنماط والنمط البولياني.

ترافق تطور لغة سي++ مع تطور المخطة المعيارية. إذا مخطة الإدخال والإخراج (I/O stream) هي أولى الإضافات إلى المخطة المعيارية، توفر هذه المخطة بدائلاً لتوابع الإدخال والإخراج المعتادة في لغة سي مثل printf وscanf. تعتبر مخطة القوالب القياسية (Standard Template Library) إحدى أبرز الإضافات إلى المخطة المعيارية من بين الإضافات اللاحقة الكثيرة المتتالية. تتميز لغة سي++ عن باقي اللغات بقلة عدد الحدثات المفتاحية حيث حتى الوظيفية الأساسية تم إدراجها في المخطة المعيارية على غرار لغة سي.

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

لا تزال سي++ قيد الاستخدام بشكل واسع وتعتبر إحدى اللغات المفضلة في تطوير التطبيقات الاحترافية .

أصل تسمية سي++

يقول ستروستروب: «يؤكد الاسم الطبيعة التطورية للتغيرات المُحْدَثة على لغة سي» . أثناء فترة التطوير تم تسمية سي++ بصفة غير معتمدة بِـ«سي الجديدة» (بالإنجليزية: new C)‏، ثم تغيَّر الاسم إلى «سي مع الأصناف» (بالإنجليزية: C with classes)‏. يعود الفضل في التسمية النهائية (سي++) إلى ريك ماسيتي (أواسط عام 1983)، وقد استخدم هذه التسمية لأول مرة في كانون الأول عام 1983. عندما سُئل ماسيتي عام 1992 عن سبب تسمية اللغة بهذا الاسم أجاب أنه قام بذلك من باب المزاح. ويعود أصل الاسم إلى استخدام معامل الزيادة (++) من لغة سي والذي يقوم بزيادة قيمة المتغير المسند له والاستخدام الشائع لرمز (+) للدلالة على حصول تحسين في برنامج حاسوبي. النادىبة تكمن في حتى الاسم نفسه يحتوي على خطأ: ذلك حتى استخدام الزيادة اللاحقة (بالإنجليزية: post-increment)‏ يسبب زيادة المتحول بعد تقييم قيمة المتحول السابقة (على عكس الزيادة السابقة (بالإنجليزية: pre-increment)‏) بمعنى حتى لغة سي++ ليست أفضل من لغة سي، وإلا فقد كان من الأجدر استخدام الزيادة السابقة بحيث يصبح اسم اللغة سي++ بدلاً من استخدام الزيادة اللاحقة كما في الاسم الحالي..

لا توجد لغة باسم «سي+» فهماً أنه توجد لغة مختلفة تماماً اسمها +ABCL/c. وهنالك بعض اللغات التي سميت بشكل قريب من سي++ أشهرها لغة سي– ولغة سي شارب.

المعايير

قامت لجنة تعيير ++C (مجموعة عمل ISO/IEC JTC1/SC22/WG21) عام 1998 بتعيير لغة ++C ونشرت المعيار ISO/IEC 14882:1998 (المعروف بشكل غير رسمي باسم C98). بعد نشر المعيار ببعض السنوات تفحصت اللجنة تقارير عن أخطاء ومشاكل المعيار السابق ونشرت عام 2003 إصداراً مصححاً من معيار ++C اسمه ISO/IEC 14882:2003. نُشر تقرير تقني عام 2005 اسمه (التقرير التقني 1 (بالإنجليزية: Technical Report 1)‏، أواختصاراً TR1) . وصّف التقرير مجموعة من الامتدادات للمخطة المعيارية -على الرغم من أنه ليس جزءاً من معيار اللغة- بحيث يتم اعتماد هذه الامتدادات في الإصدار التالي من ++C.

C++11 هوالمراجعة الأحدث لمعيار ++C وقد عهد سابقاً باسم C++0x وتمت المصادقة عليه من قبل ISO/IEC في 12 آب 2011 ونشر باسم 14882:2011 . وهنالك خطط لمراجعة طفيفة (C++14) وأخرى رئيسية (C++17) في المستقبل .

فلسفة اللغة

في كتاب «تصميم وتطوير لغة ++C» (ستروستروب، 1994) يصف بيارن ستروستروب بعض القواعد التي استلهم منها تصميم ++C:

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

في كتاب «النموذج الكائني للغة ++C» (ليبمان، 1996) يشرح المحرر إمكانية تحويل مصرفات ++C العبارات البرمجية إلى توضعات داخل الذاكرة. إلا حتى هذا لا يمنع من طبيعة الحال مصممي المصرفات من اعتماد طرقهم الخاصة في كتابة مصرفات متوافقة مع المعيار المرجعي ++C.

المخطة المعيارية

يتكون المعيار C++98 من قسمين: النواة وهي اللغة ومخطة ++C المعيارية؛ تتضمن هذه المخطة مخطة القوالب المعيارية (STL) وإصداراً معدلاً بشكل طفيف من مخطة C المعيارية. يوجد الكثير من مخطات ++C التي ليست جزءاً من المعيار، كما أنه يمكن كتابة الكثير من المخطات بلغات أخرى مثل BASIC أوC أوFortran أوحتى Pascal بناءً على توصيف الربط (بالإنجليزية: linkage specification)‏. على جميع الأحوال فإن دعم هذه المخطات الإضافية يعتمد بشكل تام على دعم المصرف لها فقط، ذلك أنها ليست جزءاً من المعيار.

تتضمن مخطة ++C المعيارية مخطة C المعيارية مع بعض التعديلات بهدف أمثلتها مع لغة ++C. هنالك جزء كبير من مخطة ++C مبني على مخطة القوالب المعيارية. توفر هذه المخطة الكثير من الأدوات مثل الحاويات (بالإنجليزية: containers)‏ (على سبيل المثال vector وlist) والتكرارات (بالإنجليزية: iterators)‏ التي توفر تعاملاً مع الحاويات شبيهاً بكيفية التعامل التقليدية مع المصفوفات من ناحية الولوج إلى العناصر وتوفير الكثير من الخوارزميات مثل الترتيب والبحث. بالإضافة إلى ذلك يوجد الكثير من أنماط البيانات المجردة مثل map وmultimap وset وmultiset ويصدّر جميع منها قابلات موحّدة تمكن التعامل معها بسهولة. إذ يمكن على سبيل المثال استخدام القوالب لكتابة خوارزمية مجردة يمكنها التعامل مع أي نوع من الحاويات أوالسلاسل باستخدام التكرارات. يتم الولوج إلى مزايا هذه المخطة كما في لغة C من خلال استخدام موجه التضمين include# من أجل تضمين الملفات المعيارية الرأسية. توفر ++C مجموعة من الملفات الرأسية عددها 105، 27 منها لم تعد قيد التطوير (مهملة (بالإنجليزية: deprecated)‏).

كانت مخطة القوالب المعيارية STL بالأساس مخطة مطورة من طرف ثالث، في البداية كان HP وتحولت لاحقاً إلى SGI قبل حتى تدرج بشكل رسمي ضمن معيار ++C. ألكسندر ستيبانوف هوالمعماري الأساسي لهذه المخطة التي أتت حصيلة اختباره للخوارزميات والحاويات المجردة سنواتٍ طويلة. لما بدأ ستيبانوف استخدام لغة ++C سرعان ما اكتشف أنها اللغة المناسبة لكتابة الخوارزميات المجردة (مثل خوارزمية sort الخاصة بـ STL) والتي يمكنها العمل بسرعة أكبر من قريناتها مثل خوارزمية qsort مثلاً من مخطة C القياسية ويعود الفضل في ذلك إلى مزايا لغة ++C مثل التضمين (بالإنجليزية: inlining)‏ والربط وقت التصريف (بالإنجليزية: compile-time binding)‏ والتي تغني عن استخدام المؤشرات إلى التوابع.

لا يشير المعيار إلى هذه مخطة القوالب المعيارية باسم "STL"، ذلك أنها جزء فقط من المخطة المعيارية إلا حتى هذا الاسم يستخدم بشكل رائج للتمييز عن باقي محتويات المخطة المعيارية (مثل مخطة الإدخال والإخراج المعيارية، عولمة البرنامج (بالإنجليزية: internationalization)‏، التشخيص، مخطة C المعيارية المعدّلة، إلخ).

توفر الكثير من مصرفات ++C تطبيقاً لمخطة ++C المعيارية بما فيها STL وهنالك أيضاً تطبيقات خاصة بالمصرف من STL مثل STLPort. توجد الكثير من المشاريع التي توفر إصدارات مخصصة من مخطة ++C المعيارية وSTL ملائمة لأهداف تصميمية عديدة.

مزايا اللغة

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

# include <iostream>

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

من الجدير بالملاحظة حتى فشل التابع في إعادة قيمة يسبب سلوكاً غير معهد طالما كان توقيعه يشير إلى إعادة قيمة من نمط مخالف للنمط void (تقدم المصرفات عادة معلومات كافية لتشخيص معضلة مثل هذه). الاستثناء الوحيد لهذه القاعدة هوالتابع main والذي يعيد ضمنياً القيمة 0 طالما عدم الإشارة صراحة إلى ذلك.

المعاملات والتحميل الزائد للمعاملات

توفر لغة ++C ما يزيد عن 35 معاملاً بما فيها المعاملات الحسابية الأساسية ومعاملات التلاعب بالبتات ومعاملات إزالة الأدلة (الخاصة بالتعامل مع المؤشرات) ومعاملات المقارنة والمعاملات المنطقية وغيرها. يمكن تحميل معظم المعاملات بشكل زائد من قبل المستخدم مع بعض الاستثناءات الجديرة بالملاحظة مثل معاملات الولوج إلى الأعضاء (. و.*) وكذلك المعاملات الشرطية. تعتبر ميزة تحميل المعاملات بشكل زائد حجر الأساس في تمكين استخدام الأنماط الفهم من قبل المستخدم إضافة إلى تسهيل استخدام الأنماط المتاحة من اللغة نفسها (بحيث حتى المستخدم لا يستطيع تمييز الفوارق بينها). يعتبر التحميل الزائد للمعاملات أساسياً أيضاً في الكثير من الميزات المتقدمة للبرمجة باستخدام ++C مثل تقنية المؤشرات الذكية. من الجدير بالملاحظة حتى التحميل الزائد للمعاملات لا يغير من قواعد أسبقية المعاملات ولا يغير من عدد المتحولات التي يتعامل معها المعامل (يمكن على جميع الأحوال للمعامل حتى يهمل بعض المتحولات، إلا حتى المتحولات سيتم تقييمها قبل تطبيق المعامل). إذا التحميل الزائد لمعاملات "&&" و"||" يفقدها خاصية تقييم قصر الدارة التي تكسبها فعالية في الأداء.

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

تدعم ++C أربع طرق لإدارة الذاكرة:

• حجز سكوني للذاكرة: يُسند للمتحول السكوني قيمة أثناء ترجمة (تصريف) البرنامج كما تٌعطى المساحة المحجوزة مكاناً ثابتاً ضمن المصدر التطبيقي. تعهد المتحولات السكونية باستخدام الحدثة المفتاحية static (المقصود هنا حجز مكان سكوني وليس حجز عضوخاص بالصف).
• حجز أوتوماتيكي للذاكرة: يُصرح عن المتحول الأوتوماتيكي باستخدام اسمه ونمطه، يحجز لهذه المتحول مكان في المكدس لدى إسناد قيمة إليه. يتم استنادىء الباني عند تطبيق التعريف عن المتحول، ويتم استنادىء الهادم عندما يصبح المتحول خارج نطاق الرؤية وبعد استنادىء الهادم يتم تحرير الذاكرة المحجوزة.
• حجز ديناميكي للذاكرة: يتم حجز مكان للمتحول ضمن الكومة (بالإنجليزية: heap)‏ عن طريق الإدارة اليدوية للذاكرة باستخدام الحدثات المفتاحية new وdelete (لا تزال ++C تدعم توابع C التقليدية الخاصة بإدارة الذاكرة ()malloc و()free).
• تتيح بعض المخطات استخدام تقنية جمع القمامة. يُستخدم جامع القمامة بوم بشكل رائج لهذا الغرض.

إن تمكين المستخدم من إدارة الذاكرة بشكل تام شبيه بلغة C على عكس لغات البرمجة التي تعمد إلى إخفاء تفاصيل كهذه عن المبرمج مثل لغة Java وPerl وPHP وRuby.

القوالب

تتيح قوالب ++C البرمجة العمومية (بالإنجليزية: generic programming)‏. تدعم ++C كلاً من قوالب الصفوف وقوالب التوابع. يمكن إعطاء القوالب ثلاث أنواع من البارامترات: أنماط، ثوابت فهم وقت التصريف، وقوالب أخرى. يتم تخصيص القوالب وبناء نماذج منها وقت التصريف. لبناء نطقب يقوم المصرف باستبدال بارامترات النطقب بوسطاء محددة من أجل توليد تابع حقيقي أونموذج عن صنف.

بعض الاستبدالات غير ممكنة إلا أنها لا تولد أخطاءً، يعود الفضل في ذلك إلى سياسة تقرير التحميل الزائد للقوالب التي توصف بالعبارة التالية: «الفشل في الاستبدال ليس خطأ» (SFINAE) (بالإنجليزية: Substitution failure is not an error)‏ تحاول هذه السياسة استنباط الاستبدالات السليمة حتى وإن قادت بعض الاستنباطات إلى استبدالات خاطئة. تقدم القوالب أداة قوية يمكن استخدامها للبرمجة العمومية والميتا-برمجة (بالإنجليزية: metaprogramming)‏. باستخدام القوالب كذلك يمكن استخدامها في أمثَلة المصدر إلا حتى هذه القوة لا تأتي دون تكلفة. قد تزيد القوالب من حجم المصدر، ذلك حتى جميع تخصيص للنطقب ينتج نسخة من مصدر النطقب: إلا حتى نسخة توليد نسخة من أجل جميع مجموعة من وسطاء النطقب يكافئ إلى حد ما نفس حجم المى الناتج من كتابتها بشكل يدوي. إذا هذا السلوك مخالف للكائنات العمومية (بالإنجليزية: generics)‏ التي تعمل وقت التطبيق والمدعومة في عدد من اللغات (مثل لغة Java) حيث يحذف النمط وقت التصريف ويحفظ جسم وحيد للنطقب ليتم استخدامه وقت التطبيق.

تختلف القوالب عن الماكروز بعدة نواحٍ: على الرغم من حتى كلا الميزتين توفران تصريفاً شرطياً إلا حتى القوالب ليست محدودة بالاستبدال اللفظي فقط حيث حتى لديها اطلاعا على معاني ونظام التنميط الخاص باللغة بالإضافة إلى معهدتها بتعاريف الأنماط وقت التصريف كما يمكنها القيام بالكثير من المهام العالية المستوى مثل إمكانية ضبط التدفق برمجياً من خلال تقييم البارامترات ذات الأنماط المعروفة قسراً. لدى الماكروالقدرة على القيام بالتحكم الشرطي في التصريف بناءً على شروط محددة سلفاً إلا أنها غير قادرة على خلق أنماط جديدة أواستنادىء نفسها ذاتياً أوالقيام بتقييم الأنماط ويبقى تأثيرها محدوداً باستبدال السلاسل النصية و(عدم) تضمين النصوص مباشرة قبل التصريف. بمعنى آخر تستطيع الماكروز التحكم بتدفق التصريف بناءً على رموز فهم سابقاً إلا أنها -على خلاف القوالب- غير قادرة على إنشاء رموز جديدة بمفردها. تعتبر القوالب أداة لتحقيق تعدد الأشكال (بالإنجليزية: polymorphism)‏ السكوني والبرمجة العمومية.

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

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

الأصناف

تضيف ++C مزايا البرمجة الكائنية التوجه (OOP) إلى لغة C، فقد تم إضافة الأصناف التي تقدم بدورها الميزات كائنية التوجه الأربعة الشائعة في أغلب لغات البرمجة الكائنية التوجه (وكذلك بعض اللغات الغير كائنية التوجه): التجريد، التغليف، الوراثة، تعدد الأشكال. إحدى أبرز ميزات أصناف ++C التي تفرقها عن باقي اللغات هي دعم الهوادم الحتمية والتي توفر بدورها دعماً لمفهوم استحواذ المصدر عبر تهيئته (RAII) (بالإنجليزية: Resouce Acquisition is Initialization)‏.

التغليف

التغليف هوإخفاء المعلومات بهدف ضمان حتى بنى المعطيات والمعاملات سيتم استخدامها بالشكل المحدد ولجعل نموذج استخدامها أكثر وضوحاً بالنسبة للمطور. توفر لغة ++C إمكانية تعريف الإصناف والتوابع بصفتها تقنيات بدائية للتغليف. يمكن لأعضاء الصف حتى يعهد عاماً (بالإنجليزية: public)‏ أومحمياً (بالإنجليزية: protected)‏ أوخاصاً (بالإنجليزية: private)‏ لتطبيق مفهوم التغليف صراحةً. يمكن لأي تابع الولوج إلى عضوعام في حين لا يمكن الولوج إلى الأعضاء الخاصة إلا من قبل التوابع الأعضاء بالإضافة إلى التوابع والأصناف «الأصدقاء» أي تلك الممنوحة صلاحية الولوج إلى الأعضاء الخاصة بالصنف (باستخدام الحدثة المفتاحية friend). يمكن الولوج للعضوالمحمي من قبل كافة أعضاء الأصناف الوارثة إضافة إلى الصنف نفسه وجميع «أصدقاءه».

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

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

الوراثة

تتيح الوراثة لنمط بيانات ما حتى يكتسب خصائص نمط بيانات آخر. يمكن للوراثة من صنف القاعدي (أوالصنف الأب) حتى تعهد بصفتها وراثة عامة public أومحمية protected أوخاصة private. تتيح معهدات الوصول هذه تحديد فيما إذا كانت الأصناف المشتقة وعديمة الصلة تستطيع الولوج إلى الأعضاء العامة والمحمية الخاصة بالصنف القاعدي. إذا الوراثة العامة فقط هي التي تتناسب مع المعنى المقصود عادةً بالـ«وراثة» ويعتبر النوعان المتبقيان أقل استخداماً بشكل كبير. طالما تم حذف معهد الوصول تكون الوراثة بين «الصنف» المشتق و«الصنف» القاعدي خاصة في حين تكون الوراثة بين «البنية» (struct) المشتقة و«البنية» الأب عامة. يمكن تعريف الأصناف القاعدية بصفتها أصنافا وهمية virtual؛ في هذه الحالة تسمى الوراثة وهمية. تضمن الوراثة الوهمية وجود نموذج (instance) واحد فقط من الصنف القاعدي في بيان الوراثة بشكل يجلي الغموض الذي قد يحصل بسبب الوراثة المتعددة.

إن الوراثة المتعددة هي ميزة تكاد تنفرد بها لغة ++C إذ لا توجد هذه الميزة في أغلب لغات البرمجة الأخرى، تتيح الوراثة المتعددة لصنف ما حتى يُشتق من أكثر من صنف قاعدي واحد؛ تتيح هذه الميزة إنشاء علاقات وراثية أكثر دقة. عملى سبيل المثال يمكن لصنف «القط الطائر» حتى يرث من كلا الصنفين «قط» و«لبون طائر». بعض اللغات الأخرى مثل لغة Java ولغة #C تحقق هدفاً شبيهاً (على الرغم من كونه محدوداً أكثر) عبر إتاحة الوراثة من قابلات متعددة في حين حصر عدد الأصناف القاعدية بصنف واحد فقط (تتيح القابلات -على خلاف الأصناف- إمكانية التصريح عن التوابع الأعضاء دون إمكانية إضافة تحقيق لها أوإضافة أعضاء بيانية). يمكن تعريف قابلة كما في لغة #C ولغة Java في لغة ++C أيضاً بصفتها صنف يحتوي فقط على توابع ظاهرية صرفة (pure virtual)، يعهد هكذا الصنف باسم صنف قاعدي مجرد (ABC) (بالإنجليزية: Abstract Base Class)‏. تعرّف التوابع الأعضاء الخاصة بصنف قاعدي مجرد عادةً بشكل صريح في الصنف المشتق ولا يتم توريثها ضمنياً. تتمتع الوراثة الظاهرية في لغة ++C بميزة إجلاءٍ للغموض اسمها الهيمنة (بالإنجليزية: dominance)‏.

تعددية الأشكال

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

تعددية الأشكال الساكنة

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

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

توفر قوالب لغة ++C تقنية متطورة ومعقدة لكتابة مصدر عمومي متعدد الأشكال. تحديداً يتيح نمط النطقب غريب التكرار (بالإنجليزية: Curiously Recurring Template Pattern)‏ كتابة نماذج من تعدد الأشكال السكوني تحاكي بشكل قريب أسلوب كتابة تجاوز التوابع الظاهرية. تستطيع قوالب ++C التعهد على الأنماط وتتمتع بكونها تورينغ-كاملة، تمكّن هاتين الميزتين من استخدام المصرّف لحل الشرطية العودية وتوليد برامج هامة باستخدام ميتا-برمجة القوالب. خلافاً للمعتقد السائد فإن استخدام القوالب لا يولد مصدرا عديم الفائدة عند التصريف بشرط استخدام الإعدادات المناسبة للمصرف.

تعددية الأشكال الديناميكية

الوراثة

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

توفر ++C المعامل dynamic_cast الذي يتيح للبرنامج حتى يحاول بأمان (بدون أخطاء) تحويل نمط كائن إلى نمط آخر أكثر تحديداً (على خلاف التحويل إلى نمط أكثر عمومية المسموح دائماً). تعتمد هذه الميزة على معلومات التنميط وقت التطبيق (RTTI) (بالإنجليزية: Run-time type information)‏. يمكن للكائنات التي يعهد المبرمج سلفاً أنها من نمط معين حتى تُحول إلى ذلك النمط باستخدام المعامل static_cast الذي يتم التحقق منه وقت التصريف ولا ينطوي على أي جهد إضافي وقت التطبيق كما أنه لا يحتاج RTTI.

التوابع الأعضاء الظاهرية

بشكل عام عندما يتجاوز تابع من صف مشتق تابعاً من صف قاعدي يحدد الإصدار الواجب استنادىئه من ذلك التابع حسب نمط الكائن. يتم تجاوز تابع ما عندما لا يوجد اختلاف في عدد وأنماط الوسائط بين تعريفين أوأكثر من للتابع. بما أنه قد لا يمكن فهم نمط الكائن المشار إليه بدقة وقت التصريف طالما استخدام متحول من نمط مؤشر إلى صف قاعدي فإنه المصرف لن يعهد في هذه الفترة أي نسخة من التابع يجب استنادىؤها؛ لهذا السبب يؤجل هذا القرار إلى حين وقت التطبيق وتسمى هذه السياسة الترحيل الديناميكي (بالإنجليزية: dynamic dispatch)‏. تتيح التوابع الأعضاء الظاهرية أو"الطرق" استنادىء النحقيق الأكثر تحديداً من التابع المُستدعى حسب نمط الكائن وقت التطبيق. يتم تحقيق هذا الغرض بشكل رائج في تحقيقات لغة ++C عن طريق استخدام جداول التوابع الظاهرية. يمكن تجاوز استخدام جداول التوابع الظاهرية بإضافة الاسم المؤهل الكامل للصف قبل استنادىء التابع طالما فهم نمط الكائن إلا حتى الاستنادىءات العامة للتوابع الظاهرية يتم حلها وقت التطبيق باستخدام هذه الجداول.

بالإضافة إلى التوابع الأعضاء القياسية يمكن لتوابع التحميل الزائد للمعاملات والهوادم حتى تكون ظاهرية أيضاً. تقول القاعدة العامة أنه طالما وجود تابع عضوظاهري واحد على الأقل في الصف يجب حتىقد يكون هادم الصف ظاهرياً أيضاً. بما حتى نمط التابع وقت إنشائهقد يكون معروفاً وقت التصريف فإن البواني (وكذلك البواني الناسخة) لا يمكن حتى تكون ظاهرية. على الرغم من ذلك قد تظهر بعض الحالات التي يضطر فيها إنشاء نسخة من الكائن عند تمرير مؤشر إلى كائن مشتق كمؤشر إلى كائن قاعدي. الحل الشائع لحالة كهذه يمكن في إنشاء تابع ظاهري ()clone (أوأي اسم آخر) ينشئ ويعيد نسخةً من الصف المشتق لدى استنادىئه.

يمكن للتابع العضوحتىقد يكون "ظاهرياً صرفاً" (بالإنجليزية: pure virtual)‏ من خلال إضافة 0= في نهاية التصريح عن التابع وقبل الفاصلة المنقوطة. يسمى الصف الذي يحتوي تابعاً عضواً ظاهرياً صرفاً واحداً على الأقل باسم نمط بيانات مجرد. لا يمكن إنشاء كائنات من أنماط البيانات المجردة. يمكن فقط اشتقاق أنماط البيانات المجردة. أي صف مشتق يرث تابعاً ظاهرياً صرفاً (أوأكثر) يجب حتى يوفر تعريفاً غير-صرفٍ له لكي يمكن إنشاء كائنات منه. أي برنامج يحاول إنشاء كائنات من صف يحوي تابعاً ظاهرياً صرفاً أويرث تابعاً ظاهرياً صرفاً (دون توفير تعريف غير-صرف له) هوبرنامج سيئ التشكيل (بالإنجليزية: ill-formed)‏ بالنسبة لقواعد كتابة برنامج باستخدام ++C.

تجزئة ومعالجة كود ++C المصدري

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

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

أخيراً يجب حتى تستطيع أداة معالجة كود ++C التعامل مع عدد من لهجات ++C المستخدمة بشكل رائج (مثل تلك المدعومة من قبل GNU Compiler Collection و++Microsoft Visual C) وأن توفر المحللات وتحويلات الكود وإعادة توليد الكود المصدري المناسب لها. إذا الدمج بين خوارزميات المتطورة مثل خوارزمية مجزئ يسار يمين المعمم مع جداول الرموز وتقنية تحويل النصوص المصدرية يتيح بناء كافة أدوات معالجة ++C. توفر جميع المصرفات أدواتاً للتجزيء. على الرغم من حتى هنالك مصرف وحيد فقط يوفر مجزئاً يتمتع بالمرونة الكافية لدمجه مع أدوات الأخرى وهوClang حيث يمكن استعمال المجزئ الخاص به كمخطة ++C (أوC) جاهزة للاندماج في أدوات أخرى كبيئة تطوير متكاملة مثلاً.

التوافقية

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

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

القوالب المُصدّرة

تعتبر الحدثة المفتاحية export إحدى النقاط التي ساد حولها خلاف كبير. تهدف هذه الحدثة المفتاحية إلى إتاحة إمكانية فصل التصريح عن القوالب عن تعريفها. تأخر تحقيق هذه الميزة حتى عام 2003، أي بعد خمس سنوات من نشر المعيار، وكان ++Cameau C/C أول مصرف يقوم بذلك؛ خلال عام 2004 طُرحت النسخة بيتا من المصرف Borland C++ Builder X مع دعم للحدثة المفتاحية export. كلا المصرفان مبنيان على القابلة الأمامية من المصرف ++EDG C. في حين لا تدعم الكثير من المصرفات كـGCC هذه الميزة أساساً.

في كتاب ++Beginning ANSI C يقدم المؤلف إيفور هورتون مثالاً عن كود ++C يستخدم فيه هذه الحدثة المفتاحية بحيث لا يعمل على أغلب المصرفات دون الإشارة صراحة إلى السبب في ذلك. لقد أوصى المدير السابق للجنة معيار ++C هيرب شتر إلى ضرورة إزالة هذه الحدثة المفتاحية من الإصدارات المستقبلية لمعيار ++C بهدف حسم هذه المعضلة بشكل نهائي . وبالعمل فقد قررت لجنة معيار ++C خلال اجتماعها فيعشرة آذار 2010 إزالة مفهوم القوالب المصدّرة بشكل تام من المعيار C++11 إلا أنها قررت الإبقاء على الحدثة المفتاحية export من أجل الاستعمال المستقبلي.

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

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

أحد الاختلافات الشهيرة بين اللغتين هوقيام لغة C بالتحويل ضمنياً للنمط *void إلى أنماط مؤشرات أخرى في حين لا تقوم ++C بذلك (بهدف تعزيز ميزة التنميط الآمن). توجد أيضاً مشكلات في المحمولية بين اللغتين إذ تعهد لغة ++C الكثير من الحدثات المفتاحية الجديدة مثل new وclass والتي يمكن استخدامها كمعرّفات (أسماء متحولات على سبيل المثال) في برنامج مكتوب بلغة C.

لقد أزيلت بعض عقبات عدم التوافقية في تنقيح معيار لغة C (المسمى C99) الذي تم عام 1999، حيث أضيفت بعض ميزات ++C إلى لغة C كالتعليقات السطرية (//) وإمكانية الدمج بين التصاريح وبقية أجزاء الكود. في نفس الوقت أدخل المعيار C99 عدداً من الميزات الجديدة التي لا تدعمها لغة ++C مسببة عدم التوافق أوأنها موجودة في لغة ++C ولكن بأسلوب آخر مسببة زيادةً غير مرغوبة، على سبيل المثال تعهد C99 النمط complex المعهد بلغة ++C بالصف complex الموجود ضمن مخطة ++C القياسية، كذلك دعم C99 للمصفوفات ذات الأبعاد المتغيرة وتعريفها النمط boolean كـاسم مستعار بـtypedef في حين أنه نمط بيانات أساسي في لغة ++C، إضافة إلى إضافة الحدثة المفتاحية restrict. أٌدخلت بعض ميزات C99 الجديدة في الإصدار التالي من معيار ++C وهوC++11 :

• ميزات المعالج التحضيري (بالإنجليزية: preprocessor)‏ الخاص بـC99 (بما فيها الماكروذات العدد المتغير من الوسطاء والعمليات الحسابية على معاملات كبيرة القيمة)
• ()Pragma_
• النمط long long
• __func__
• الملفات الرأسية التالية:
  • cstdbool من (stdbool.h)
  • cstdint من (stdint.h)
  • cinttypes من (inttypes.h)

إن دمج كود C مع كود ++C يحتاج حتى يسبق تصريح أي تابع يتم التعامل معه من اللغتين معلومةً تشير إلى ضرورة استخدام C للقيام بربطه مع بقية البرنامج (يتم ذلك عبر استخدام {*...* "extern "C) تفادياً لاستخدام تقنية ربط ++C التي تغير اسم التابع (بهدف تمييز التوابع المحملة بشكل زائد عن بعضها).

انظر أيضا

• قائمة بمصرفات ++C/C
• الصفوف في ++C
• المتحولات (المتغيرات) في ++C
• الأنماط في ++C
• التحويل (القسر) بين الأنماط في ++C

مراجع

وصلات خارجية

• JTC1/SC22/WG21 (بالإنجليزية) - مجموعة عمل ISO/IEC الخاصة بلغة ++C
  • n3242.pdf (بالإنجليزية) - آخر مسودة متاحة من لجنة معيار ++C خاصة بالمعيار ISO/IEC IS 14882
  • n3337.pdf (بالإنجليزية) - أول مسودة بعد معيار C++11، تتضمن المسودة المعيار C++11 إضافة إلى بعض التعديلات التحريرية
• ورقة بحثية من بيارن ستروستروب يوضح فيها تاريخ تطور ++C من عام 1991 حتى 2006 (بالإنجليزية)
• الأسئلة الأكثر شيوعاً حول أسلوب وتقنية كتابة ++C على مسقط بيارن ستروستروب (بالإنجليزية)
• النسخة البسيطة من الأسئلة الأكثر شيوعاً عن لغة ++C من مارشال كلاين (بالإنجليزية)
• الأسئلة حول الأجوبة الأكثر شيوعاً عن لغة ++C من يوسي كراينين (بالعربية)
• منظمة معيار ++C (بالإنجليزية)، منظمة غير ربحية تهدف إلى تشجيع استخدام وفهم لغة ++C. بيارن ستروستروب هومدير هذه المنظمة

سي++ في المشاريع الشقيقة

---

• صور وملفات صوتية من كومنز
• خط من ويكي الخط