C ++ مشروع قانون المصدر المصدر

Question

أحد الطرق الشعبية لتنظيم دليل المشروع هو أكثر أو أقل مثل هذا:

MyLib + - mylib_class_a.h mylib_class_a.cpp mylib_library_private_helpers.h mylib_library_private_helpers.cpp myapp + - other_class.h الأخرى_class.cpp app.cpp

app.cpp:

#include "other_class.h"
#include <mylib_class_a.h> // using library MyLib

الجميع .h و .cpp الملفات لنفس المكتبة هي في نفس الدليل. لتجنب تصادم الاسم، غالبا ما تكون أسماء الملفات بادئة مع اسم الشركة و / أو اسم المكتبة. ستكون MyLIB في مسار البحث عن رأس MyApp، وما إلى ذلك، أنا لست من محبي أسماء الأفلام البادئة، لكنني أحب فكرة النظر إلى #include ومعرفة بالضبط حيث ينتمي هذا الملف الرأس. لا أكره هذا النهج في تنظيم الملفات، لكنني أعتقد أنه يجب أن يكون هناك طريقة أفضل.

منذ أن أبدأ مشروعا جديدا، أريد أن طلب بعض الأفكار دليل الدليل. حاليا أنا أحب هذه هيكل الدليل:

Proja + - تشمل + - Proja + - Mylib + - Class_a.h + - تطبيق + - Other_Class.h + - SRC + - MyLib + - Class_a.cpp Librate_private_helpers.h Library_private_helpers.cpp + --APP + - other_class.cpp app.cpp util.h

app.cpp:

#include "util.h" // private util.h file
#include <ProjA/app/other_class.h> // public header file
#include <ProjA/mylib/class_a.h> // using class_a.h of mylib
#include <other3rdptylib/class_a.h> // class_a.h of other3rdptylib, no name collision
#include <class_a.h> // not ProjA/mylib/class_a.h
#include <ProjA/mylib/library_private_helpers.h> // error can't find .h 

.cpp الملفات والخاصة (مرئية فقط للمكتبة الفورية) .h يتم تخزين الملفات بموجب دليل SRC (SRC يطلق عليه في بعض الأحيان LIB). يتم تنظيم ملفات الرأس العامة في بنية دليل للمشروع / LIB وإدراجها عبر <ProjectName/LibraryName/headerName.h>. وبعد أسماء الملفات غير مسبوقة بأي شيء. إذا كنت بحاجة إلى باقة MyLIB لاستخدامها من قبل فرق أخرى، فيمكنني ببساطة تغيير My Makefile لنسخ الملفات الثنائية المناسبة وتشمل كل دليل / ProJA.

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

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

Answer 1

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

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

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

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

عادة ما تكون القبلة دائما الحل في البرمجة -> احتفظ بكل شيء بسيطة قدر الإمكان.

Answer 2

لماذا لا تفعل شيئا مثل الأول، فقط استخدم الدليل الذي MyLib يقع في كجزء من توجيه التوجيهات، مما يقلل من البادئة السخيفة:

#include <MyLib/ClassA.h>

هذا يخبرك أين هم من. أما بالنسبة للاختيار الثاني، فأنا شخصيا منزعجا حقا عندما يكون لدي ملف رأس أو ملف مصدر مفتوح، واضطر إلى التنقل عبر بنية الدليل للعثور على الآخر وفتحه. مع مثالتك الثانية، إذا كان لديك src/mylib/class_a.cpp فتح، وأراد تحرير الرأس، في العديد من المحررين، عليك العودة إلى مستويين، ثم في include/ProjA قبل العثور على الرأس. وكيف نعرف أن الرأس في ProjA الدليل الفرعي دون بعض أدنى فكرة خارجية أخرى؟ بالإضافة إلى ذلك، من السهل جدا أن يتم نقل ملف واحد أو آخر ليتم نقله إلى مكان مختلف يمثل "أفضل" كيف يتم استخدامه، دون أن يتم نقل الملف البديل. هذا فقط يعطيني الصداع عندما واجهت ذلك في وظيفتي (ولدينا بعض أجزاء من الكود الخاص بنا حيث فعل الناس كل مشكلة محتملة ذكرت للتو).

Answer 3

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

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