تنظيم ملفات رأس فئة C++

Question

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

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

Answer 1

بعض الإرشادات العامة:

• قم بإقران واجهاتك مع التطبيقات.اذا كنت تمتلك foo.cxx, ، فمن الأفضل أن يتم الإعلان عن كل شيء محدد هناك foo.h.
• تأكد من أن كل ملف رأس يتضمن جميع الرؤوس الضرورية الأخرى أو الإعلانات الأمامية اللازمة للتجميع المستقل.
• قاوم إغراء إنشاء عنوان "كل شيء".إنهم دائمًا يسببون المتاعب على الطريق.
• ضع مجموعة من الوظائف المرتبطة (والمترابطة) في ملف واحد.تشجع Java والبيئات الأخرى فئة واحدة لكل ملف.مع C++، غالبًا ما تريد واحدًا مجموعة من فئات لكل ملف.ذلك يعتمد على هيكل التعليمات البرمجية الخاصة بك.
• تفضل الإعلان الأمامي أكثر #includeكلما أمكن ذلك.يتيح لك هذا كسر تبعيات الرأس الدورية.بشكل أساسي، بالنسبة للتبعيات الدورية عبر ملفات منفصلة، ​​فأنت تريد رسمًا بيانيًا لتبعية الملف يبدو كالتالي:
  • A.cxx يتطلب A.h و B.h
  • B.cxx يتطلب A.h و B.h
  • A.h يتطلب B.h
  • B.h مستقلة (وتعلن عن الفئات المحددة في A.h)

إذا كان المقصود من التعليمات البرمجية الخاصة بك أن تكون مكتبة يستهلكها مطورون آخرون، فهناك بعض الخطوات الإضافية التي من المهم اتخاذها:

• إذا لزم الأمر، استخدم مفهوم "الرؤوس الخاصة".أي أن الملفات الرأسية مطلوبة من قبل العديد من الملفات المصدرية، ولكنها لا تتطلبها الواجهة العامة أبدًا.يمكن أن يكون هذا ملفًا يحتوي على وظائف مضمّنة أو وحدات ماكرو أو ثوابت داخلية شائعة.
• افصل واجهتك العامة عن تطبيقك الخاص على مستوى نظام الملفات.أنا أميل إلى استخدام include/ و src/ الدلائل الفرعية في مشاريعي C أو C++، حيث include/ لديه كل رؤوسي العامة، و src/ لديه كل مصادري.والعناوين الخاصة.

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

Answer 2

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

المرة الوحيدة التي يفشل فيها الأمر هي إذا قمت بالتنقل بين الأجهزة، ويتضمن رأس xxx.h، على سبيل المثال، ما يلي: <pqr.h>, ، لكن <pqr.h> يتطلب التسهيلات التي يتم توفيرها بواسطة رأس <abc.h> على المنصة الأصلية (هكذا <pqr.h> يشمل <abc.h>)، ولكن لا يتم توفير التسهيلات من قبل <abc.h> على المنصة الأخرى (هم في def.h بدلا من ذلك، ولكن <pqr.h> لا يشمل <def.h>).وهذا ليس خطأً في القاعدة، ويمكن تشخيص المشكلة وحلها بسهولة أكبر إذا اتبعت القاعدة.

Answer 3

وتحقق من المقطع ملف الرأس في جوجل أسلوب دليل

Answer 4

توم الجواب هو واحد ممتاز!

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

والمنطق لهذا وصفا جيدا في كتاب ممتاز "المعجل C ++" ( الأمازون رابط - مطهرة لالنازيين الرابط النصي كيدي)

Answer 5

ونقطة واحدة أكثر بالإضافة إلى آخرين هنا:

<اقتباس فقرة>   

لا يتضمن أي تعريفات خاصة   في ملف التضمين. مثلا أي   تعريف التي يتم استخدامها فقط في   يجب أن يكون xxx.cpp في xxx.cpp، وليس   xxx.h.

ويبدو واضحا، ولكن أرى أنه في كثير من الأحيان.

Answer 6

وأود أن أضيف واحدة الممارسات الجيدة جدا (سواء في C و C ++) التي غالبا ما تخلى:

foo.c

#include "foo.h" // always the first directive

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

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