هل من المستحيل كتابة مكتبة رأس فقط؟

Question

هل هناك من أي وقت مضى مثل هذا النمط من التبعية بحيث من المستحيل الحفاظ على كل شيء في ملفات الرأس فقط؟ ماذا لو فرضنا قاعدة فئة واحدة لكل رأس فقط؟

لأغراض هذا السؤال ، دعونا نتجاهل الأشياء الثابتة :)

Answer 1

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

Answer 2

من الممكن ، أود أن أقول ، في حالة صريحة من عدم استخدام عدد من ميزات اللغة: كما لاحظت ، بعض استخدامات static الكلمة الرئيسية.

قد يتطلب الأمر بعض الخدعة ، ولكن يمكن مراجعتها.

1. ستحتاج إلى الحفاظ على تمييز الرأس / المصدر كلما احتجت إلى كسر دورة التبعية ، على الرغم من أن الملفان سيكونان ملفات رأس في الممارسة العملية.
2. يجب الإعلان عن الوظائف الحرة (غير المملوكة) مضمّنة ، يجوز للمترجم ضمنها ، ولكن إذا تم إعلانها ، فلن يشتكي من إعادة تعريفها عندما يقوم العميل بتشغيل مكتبة / قابلة للتنفيذ.
3. يجب محاكاة البيانات المشتركة عالميًا (المتغيرات العالمية والسمات الثابتة للفئة) باستخدام السمة الثابتة المحلية في وظائف / طرق الفئة. في الممارسة العملية ، لا يهم سوى القلق من المتصل (يضيف فقط ()). لاحظ أنه في C ++ 0x ، يصبح هذا هو الطريقة المفضلة لأنه مضمون أن يكون آمنًا لخيط الخيط مع الاستمرار في الحماية من الإخفاق في أمر التهيئة ، حتى ذلك الحين ... إنه ليس آمنًا ؛)

فيما يتعلق بتلك النقاط الثلاث ، أعتقد أنك ستتمكن من كتابة مكتبة رأسًا بالكامل فقط (أي شخص يرى شيئًا آخر فاتني؟)

استخدم عدد من مكتبات Boost حيلًا مماثلة لتكون رأسًا فقط على الرغم من أن رمزها لم يكن قالبًا تمامًا. فمثلا Asio يفعل بوعي شديد ويقترح البديل باستخدام الأعلام (انظر ملاحظات الإصدار لـ ASIO 1.4.6):

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

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

ملحوظة: أنا أتساءل عما إذا كان static يمكن أن تكون الوظائف محدودة ، فأنا أفضل استخدام مساحات أسماء مجهولة بنفسي ، لذا لم أبحث عنها أبدًا ...

Answer 3

الفئة الواحدة لكل قاعدة لا معنى لها. إذا كان هذا لا يعمل:

#include <header1>
#include <header2>

ثم بعض التباين في هذا:

#include <header1a>
#include <header2>
#include <header1b>

قد يؤدي ذلك إلى أقل من فئة واحدة لكل رأس ، ولكن يمكنك دائمًا استخدام (باطل*) والوظائف المضمنة (وفي هذه الحالة ، من المحتمل أن يتم تجاهل "المترجم". لذلك يبدو لي السؤال ، يمكن تخفيضه إلى:

class A
{
// ...
void *pimpl;
}

هل من الممكن أن يكون التنفيذ الخاص ، PIMPL ، يعتمد على إعلان A؟ إذا كان الأمر كذلك ، فيجب أن تسبق Pimpl.CPP (كرئيس) ومتابعة AH ، ولكن بما أنه يمكنك دائمًا ، مرة أخرى ، استخدام (void*) والوظائف المضمنة في الرؤوس السابقة ، يمكن القيام بذلك.

بالطبع ، يمكن أن أكون مخطئا. في كلتا الحالتين: إيك.

Answer 4

في حياتي المهنية الطويلة ، لم أجد نمط التبعية من شأنه أن يمنع تنفيذ الرأس فقط.

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

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