التدوين المجري

📅 آخر تحديث: ٢٣ يوليو ٢٠٢٦
✍️ نُشر في: ٢٣ يوليو ٢٠٢٦
الموسوعة الحرة

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

سيموني : ...BCPL [كان لديه] نوع واحد وهو كلمة 16 بت ... ليس الأمر مهمًا.

بوتش : إلا إذا واصلت استخدام التدوين المجري.

سيموني : بالتأكيد... لقد انتقلنا إلى اللغات المكتوبة أيضًا لاحقًا... لكن... كنا ننظر إلى اسم واحد وسأخبرك بالكثير عنه بالضبط... [ 1 ]

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

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

تاريخ

ابتكر تشارلز سيموني ، المبرمج الذي عمل في مركز أبحاث زيروكس بارك (Xerox PARC) بين عامي 1972 و1981، والذي أصبح لاحقًا كبير المهندسين المعماريين في مايكروسوفت ، نظام الترميز المجري الأصلي . يشير اسم هذا النظام إلى بلد سيموني الأصلي، وأيضًا، وفقًا لأندي هيرتزفيلد ، لأنه جعل البرامج "تبدو وكأنها مكتوبة بلغة أجنبية غامضة". [ 2 ] تُكتب أسماء المجريين "بترتيب معكوس" مقارنةً بمعظم الأسماء الأوروبية الأخرى؛ حيث يسبق اسم العائلة الاسم الشخصي . على سبيل المثال، كان الاسم الإنجليزي "Charles Simonyi" في المجرية يُكتب في الأصل "Simonyi Károly". وبالمثل، يسبق اسم النوع "الاسم الشخصي" في نظام الترميز المجري. كان أسلوب تسمية "النوع أخيرًا" المشابه في لغة سمول توك (مثل aPoint وlastPoint) شائعًا في مركز أبحاث زيروكس بارك خلال فترة عمل سيموني هناك.

أشارت ورقة سيموني حول الترميز إلى البادئات المستخدمة للدلالة على "نوع" المعلومات المخزنة. [ 3 ] [ 4 ] وكان اقتراحه يركز بشكل أساسي على تزيين أسماء المعرفات بناءً على المعلومات الدلالية لما تخزنه (أي غرض المتغير ). أصبح ترميز سيموني يُعرف باسم "Apps Hungarian" نظرًا لاستخدامه في قسم التطبيقات في مايكروسوفت. ثم طُوّر "Systems Hungarian" لاحقًا في فريق تطوير مايكروسوفت ويندوز . ولا يختلف "Apps Hungarian" تمامًا عما أصبح يُعرف باسم "Systems Hungarian"، إذ أن بعض البادئات التي اقترحها سيموني لا تحتوي على معلومات دلالية تُذكر (انظر الأمثلة أدناه). [ 4 ]

الأنظمة المجرية مقابل التطبيقات المجرية

يكمن الاختلاف بين تدوين الأنظمة وتدوين التطبيقات في الغرض من البادئات.

في نظام الترميز المجري، يشير البادئة إلى نوع البيانات الفعلي للمتغير. على سبيل المثال:

  • lAccountNum المتغير هو عدد صحيح طويل ( "l");
  • arru8NumberList المتغير عبارة عن مصفوفة من الأعداد الصحيحة غير الموقعة ذات 8 بت ( "arru8");
  • bReadLine(bPort,&arru8NumberList) دالة ذات قيمة بايت مُرجعة.
  • strName : يمثل المتغير سلسلة نصية ( "str") تحتوي على الاسم، ولكنه لا يحدد كيفية تنفيذ تلك السلسلة.

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

  • rwPosition : يمثل المتغير صفًا ( "rw");
  • usName يمثل المتغير سلسلة نصية غير آمنة ( "us")، والتي يجب "تنظيفها" قبل استخدامها (على سبيل المثال، انظر حقن التعليمات البرمجية والبرمجة النصية عبر المواقع للحصول على أمثلة على الهجمات التي يمكن أن تحدث باستخدام مدخلات المستخدم الخام).
  • szName : المتغير عبارة عن سلسلة منتهية بـ null ( "sz"); كان هذا أحد البادئات الأصلية التي اقترحها سيموني.

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

فيما يلي أمثلة من الورقة الأصلية: [ 3 ]

  • pXهو مؤشر إلى نوع آخر X ؛ وهذا يحتوي على معلومات دلالية قليلة جدًا.
  • dالبادئة تعني الفرق بين قيمتين؛ على سبيل المثال، قد يُمثل dY مسافة على طول المحور Y في الرسم البياني، بينما قد يُمثل المتغير y موقعًا مطلقًا. هذا الأمر دلالي بحت.
  • szهو سلسلة نصية منتهية بحرف فارغ. في لغة C، يحتوي هذا على بعض المعلومات الدلالية لأنه ليس من الواضح ما إذا كان متغير من النوع char* مؤشرًا إلى حرف واحد، أو مصفوفة من الأحرف، أو سلسلة نصية منتهية بحرف فارغ.
  • wيشير هذا إلى متغير عبارة عن كلمة. لا يحتوي هذا على أي معلومات دلالية تقريبًا، وربما يُعتبر لغةً هنغاريةً نظامية.
  • bيشير هذا الرمز إلى بايت، والذي قد يحمل معلومات دلالية، على عكس w، لأن نوع البيانات الوحيد بحجم بايت في لغة C هو char ، لذا يُستخدم أحيانًا لتخزين القيم العددية. قد يزيل هذا الرمز الالتباس حول ما إذا كان المتغير يحمل قيمة يجب التعامل معها كحرف أو رقم.

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

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

العلاقة بالرموز السحرية

في بعض لغات البرمجة، تُدمج في اللغة صيغة مشابهة تُسمى الآن "الرموز" ويفرضها المُصرّف . على سبيل المثال، في بعض إصدارات لغة BASIC ، name$يُشير الرمز ` <string>` إلى سلسلة نصية ، بينما count%يُشير الرمز `<int>` إلى عدد صحيح . الفرق الرئيسي بين الصيغة الهنغارية والرموز هو أن الرموز تُحدد نوع المتغير في اللغة، بينما الصيغة الهنغارية هي مجرد نظام تسمية لا يؤثر على تفسير الآلة لنص البرنامج.

أمثلة

عادة ما يتبع الاختصارات الخاصة بالمؤشرات والمصفوفات ، والتي لا تُعد أنواع بيانات فعلية، نوع عنصر البيانات نفسه:

  • pszOwner مؤشر إلى سلسلة منتهية بـ null
  • rgfpBalances : مصفوفة من قيم الفاصلة العائمة
  • aulColors مصفوفة من الأعداد الصحيحة الطويلة غير الموقعة (الأنظمة)

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

  • بالنسبة للمبرمجين الذين تعلموا برمجة ويندوز بلغة C، ربما تكون الأمثلة الأكثر تذكراً هي wParam(معامل حجم الكلمة) و lParam(معامل العدد الصحيح الطويل) لوظيفة WindowProc ().
  • hwndFoo : مقبض نافذة
  • lpszBar مؤشر طويل إلى سلسلة نصية منتهية بـ null

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

  • g_nWheels : عضو في نطاق اسم عالمي، عدد صحيح
  • m_nWheels : عضو في بنية/فئة، عدد صحيح
  • m_wheels، _wheels : عضو في بنية/فئة
  • s_wheels : عضو ثابت في فئة
  • c_wheels : عضو ثابت في دالة

المزايا

(بعض هذه الأمور تنطبق على الأنظمة المجرية فقط.)

يجادل المؤيدون بأن فوائد التدوين المجري تشمل ما يلي: [ 3 ]

  • يمكن معرفة نوع الرمز من اسمه. وهذا مفيد عند مراجعة الكود خارج بيئة التطوير المتكاملة - كما هو الحال في مراجعة الكود أو في نسخة مطبوعة - أو عندما يكون تعريف الرمز في ملف آخر غير ملف الاستخدام، مثل دالة.  
  • في اللغات التي تستخدم الكتابة الديناميكية أو اللغات غير المصنفة، تفقد الزخارف التي تشير إلى أنواع البيانات أهميتها. في هذه اللغات، لا تُعلن المتغيرات عادةً على أنها تحمل نوعًا محددًا من البيانات، لذا فإن الدليل الوحيد على العمليات التي يمكن إجراؤها عليها هو تلميحات يقدمها المبرمج، مثل نظام تسمية المتغيرات والتوثيق والتعليقات. وكما ذُكر سابقًا، تم توسيع الترميز المجري في هذه اللغات ( BCPL ).
  • قد يؤدي تنسيق أسماء المتغيرات إلى تبسيط بعض جوانب إعادة هيكلة التعليمات البرمجية (مع جعل جوانب أخرى أكثر عرضة للأخطاء).
  • يمكن استخدام متغيرات متعددة ذات دلالات متشابهة في كتلة من التعليمات البرمجية: dwWidth، iWidth، fWidth، dWidth.
  • يمكن تذكر أسماء المتغيرات بسهولة بمجرد معرفة أنواعها.
  • يؤدي ذلك إلى أسماء متغيرات أكثر اتساقًا.
  • يمكن اكتشاف عمليات تحويل الأنواع غير المناسبة والعمليات التي تستخدم أنواعًا غير متوافقة بسهولة أثناء قراءة التعليمات البرمجية.
  • في البرامج المعقدة التي تحتوي على العديد من الكائنات العامة (مثل نماذج VB/Delphi)، يُسهّل استخدام صيغة البادئة الأساسية عملية البحث عن المكون داخل المحرر. على سبيل المثال، btnقد يؤدي البحث عن السلسلة النصية إلى العثور على جميع كائنات الزر.
  • يساعد تطبيق الترميز المجري بطريقة أضيق، مثل تطبيقه فقط على متغيرات الأعضاء ، على تجنب تضارب التسمية .
  • يكون الكود المطبوع أكثر وضوحًا للقارئ في حالة أنواع البيانات، وتحويلات الأنواع، والتعيينات، والاقتطاعات، وما إلى ذلك.

العيوب

معظم الاعتراضات على استخدام الترميز المجري موجهة ضد الترميز المجري الخاص بالأنظمة ، وليس الترميز المجري الخاص بالتطبيقات . ومن بين المشكلات المحتملة ما يلي:

  • يُعدّ استخدام الترميز المجري غير ضروري عند إجراء فحص النوع بواسطة المُصرّف. تضمن مُصرّفات اللغات التي توفر فحصًا دقيقًا للأنواع، مثل باسكال ، أن استخدام المتغير يتوافق مع نوعه تلقائيًا؛ أما الفحص البصري فهو غير ضروري وعرضة للخطأ البشري.
  • تعرض معظم بيئات التطوير المتكاملة الحديثة أنواع المتغيرات عند الطلب، وتُشير تلقائيًا إلى العمليات التي تستخدم أنواعًا غير متوافقة، مما يجعل هذه الصيغة قديمة إلى حد كبير. في لغات البرمجة المشابهة للغة C، يكون النوع جزءًا من تعريف المتغير، بينما في لغات أخرى مثل Rust، يمكن تحديد النوع صراحةً في التعريف.
  • يصبح التدوين المجري مربكًا عندما يتم استخدامه لتمثيل عدة خصائص، كما في : وسيط ثابت ، وهو مرجع مرجعي يحتوي على محتويات عمود قاعدة بيانات من النوع varchar (30) والذي يعد جزءًا من المفتاح الأساسي للجدول . a_crszkvc30LastNameColLastName
  • قد يؤدي ذلك إلى عدم اتساق عند تعديل الكود أو نقله. إذا تم تغيير نوع متغير، فإما أن يكون تنسيق اسم المتغير غير متسق مع النوع الجديد، أو يجب تغيير اسم المتغير نفسه. ومن الأمثلة المعروفة على ذلك نوع WPARAM القياسي، والمعامل الرسمي wParam المصاحب له في العديد من تعريفات دوال نظام ويندوز. يشير الحرف 'w' إلى 'word'، حيث 'word' هو حجم الكلمة الأصلي لبنية الجهاز. كان في الأصل نوع 16 بت على بنى كلمات 16 بت، ولكن تم تغييره إلى 32 بت على بنى كلمات 32 بت، أو إلى 64 بت على بنى كلمات 64 بت في الإصدارات اللاحقة من نظام التشغيل مع الاحتفاظ باسمه الأصلي (نوعه الأساسي الحقيقي هو UINT_PTR، أي عدد صحيح غير مُوقّع كبير بما يكفي لاحتواء مؤشر). إن المعاوقة الدلالية، وبالتالي ارتباك المبرمجين وعدم الاتساق من منصة إلى أخرى، تفترض أن 'w' تعني كلمة من بايتين و 16 بت في تلك البيئات المختلفة.
  • في أغلب الأحيان، تتطلب معرفة استخدام متغير ما معرفة نوعه. علاوة على ذلك، إذا لم يكن استخدام المتغير معروفًا، فلا يمكن استنتاجه من نوعه.
  • يقلل التدوين المجري من فوائد استخدام محررات التعليمات البرمجية التي تدعم الإكمال التلقائي لأسماء المتغيرات، حيث يتعين على المبرمج إدخال محدد النوع أولاً، وهو ما يزيد من احتمالية حدوث تعارض مع متغيرات أخرى مقارنة باستخدام أنظمة التسمية الأخرى.
  • يجعل ذلك الكود أقل قابلية للقراءة، من خلال إخفاء الغرض من المتغير باستخدام بادئات النوع والنطاق. [ 8 ]
  • قد لا تُغني المعلومات الإضافية عن الأسماء الأكثر وصفًا. على سبيل المثال، لا يُوضح اسم "sDatabase" ماهية قاعدة البيانات للقارئ، بينما قد يكون اسم "databaseName" أكثر وصفًا.
  • عندما تكون الأسماء وصفية بما فيه الكفاية، قد تكون معلومات النوع الإضافية زائدة. على سبيل المثال، من المرجح أن يكون الاسم الأول (firstName) سلسلة نصية. لذا فإن تسميته sFirstName لا يؤدي إلا إلى إضافة فوضى إلى الكود.
  • يصعب تذكر الأسماء.
  • يمكن استخدام متغيرات متعددة ذات دلالات مختلفة في كتلة من التعليمات البرمجية بأسماء متشابهة: dwTmp، iTmp، fTmp، dTmp .

آراء بارزة

  • روبرت سيسيل مارتن (ضد التدوين المجري وجميع أشكال الترميز الأخرى):

    ... في الوقت الحاضر، تُعدّ HN وغيرها من أشكال ترميز الأنواع مجرد عوائق. فهي تُصعّب تغيير اسم أو نوع متغير أو دالة أو عضو أو فئة. كما تُصعّب قراءة الكود. وتُتيح إمكانية تضليل نظام الترميز للقارئ. [ 9 ]

  • لينوس تورفالدز (ضد سيستمز هنغاريا):

    إن ترميز نوع الدالة في اسمها (ما يسمى بالتدوين المجري) هو أمر غير منطقي - فالمترجم يعرف الأنواع على أي حال ويمكنه التحقق منها، وهذا لا يؤدي إلا إلى إرباك المبرمج. [ 10 ]

  • ستيف ماكونيل (لأعمال التطبيقات الهنغارية):

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

  • بيارن ستروستروب (ضد شركة Systems Hungarian لصالح C++):

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

  • جويل سبولسكي (للتطبيقات الهنغارية):

    إذا قرأتَ ورقة سيموني بعناية، ستجد أنه كان يقصد نفس اصطلاح التسمية الذي استخدمته في المثال أعلاه، حيث قررنا أن `<string>` usتعني سلسلة نصية غير آمنة، و`<string>` sتعني سلسلة نصية آمنة. كلاهما من النوع `<string>` string. لن يُساعدك المُصرّف إذا أسندتَ أحدهما للآخر، ولن يُخبرك نظام الإكمال التلقائي الذكي (IntelliSense) بأي شيء . لكنهما مختلفان دلاليًا. يجب تفسيرهما ومعالجتهما بشكل مختلف، وسيتعين استدعاء دالة تحويل ما إذا أسندتَ أحدهما للآخر، وإلا ستواجه خطأً أثناء التشغيل. هذا إن حالفك الحظ. لا تزال لتطبيقات الهنغارية قيمة كبيرة، فهي تُحسّن من تراكيب البيانات في الكود، مما يُسهّل قراءته وكتابته وتصحيحه وصيانته، والأهم من ذلك، أنها تجعل الكود الخاطئ يبدو خاطئًا... (كان تطبيق أنظمة الهنغارية) سوء فهم دقيقًا ولكنه كامل لنية سيموني وممارسته. [ 4 ]

  • تُثني إرشادات تصميم مايكروسوفت [ 13 ] المطورين عن استخدام تدوين النظام الهنغاري عند اختيار أسماء العناصر في مكتبات فئات .NET، على الرغم من شيوعه في منصات تطوير مايكروسوفت السابقة مثل Visual Basic 6 وما قبلها. ولا تتناول هذه الإرشادات اصطلاحات تسمية المتغيرات المحلية داخل الدوال.

انظر أيضاً

مراجع

  1. ↑ سيموني، تشارلز ؛ بوتش، غرادي (2008). "التاريخ الشفوي لتشارلز سيموني" (ملف PDF) . Archive.computerhistory.org . متحف تاريخ الحاسوب . مؤرشف (ملف PDF) من الأصل بتاريخ 10 سبتمبر 2015. تم الاطلاع عليه بتاريخ 5 أغسطس 2018 .
  2. ↑ روزنبرغ، سكوت (1 يناير 2007). "أي شيء يمكنك فعله، يمكنني فعله ميتا" . مجلة إم آي تي ​​للتكنولوجيا . تم الاطلاع عليه بتاريخ 21 يوليو 2022 .
  3. 1 2 3 تشارلز سيموني (نوفمبر 1999). "التدوين المجري" . مكتبة MSDN . شركة مايكروسوفت .
  4. 1 2 3 سبولسكي، جويل (11 مايو 2005). "جعل الكود الخاطئ يبدو خاطئًا" . جويل عن البرمجيات . تم الاسترجاع في 13 ديسمبر 2005 .
  5. ↑ بوسيا-مانيا-تونيس، ر. (يناير 2009). "دليل الممارسات الجيدة في استخدام المترجمات مفتوحة المصدر مع محلل AGCC المعجمي". المعلوماتية الاقتصادية . 13 (1): 75-83 . ISSN 1453-1305 . S2CID 5874166. Wikidata Q140426271 .   
  6. ↑ "إرشادات أسلوب برمجة Webkit" . Webkit.org . تم الاطلاع عليه بتاريخ 17 مارس 2015 .
  7. ^ ستيفنز ، آل (فبراير 1999). "المظروف من فضلك". مجلة الدكتور دوب . 24 (2): 111-113 . ISSN 1044-789X . ويكي بيانات Q140426226 .  
  8. ↑ جونز، ديريك م. (2009). معيار C الجديد: تعليق ثقافي واقتصادي (ملف PDF) . أديسون-ويسلي. ص 727. ISBN  978-0-201-70917-9تمت أرشفة الملف (PDF) من النسخة الأصلية بتاريخ 2011-05-01.
  9. ↑ مارتن، روبرت سيسيل (2008). الكود النظيف: دليل لحرفية تطوير البرمجيات الرشيقة . ريدموند، واشنطن: برنتيس هول بي تي آر. رقم ISBN 978-0-13-235088-4.
  10. ↑ "أسلوب برمجة نواة لينكس" . وثائق نواة لينكس . تم الاطلاع عليه بتاريخ 9 مارس 2018 .
  11. ↑ ماكونيل، ستيف (2004). كود كومبليت ( الطبعة الثانية). ريدموند، واشنطن: مطبعة مايكروسوفت . ISBN  0-7356-1967-0.
  12. ^ ستروستروب ، بيارن (2007). "الأسئلة الشائعة حول أسلوب وتقنية C++ لـ Bjarne Stroustrup" . تم الاسترجاع 15 فبراير 2015 .
  13. ↑ "إرشادات تصميم لتطوير مكتبات الفصول الدراسية: اصطلاحات التسمية العامة" . تم الاطلاع عليه بتاريخ 2008-01-03 .