بناء شفرة المصدر C ++ كمكتبة - من أين تبدأ؟

Question

خلال الأشهر التي كتبتها بعض الوظائف العامة الكافية التي أرغب في بناءها ككتبة وربط ديناميكيا مقابل بدلا من استيراد ملفات رأس / مصدر 50 غريبة.

يتم الحفاظ على المشروع في Xcode و Dev-C ++ (أفهم أنني قد أضطر إلى الذهاب إلى سطر الأوامر للقيام بما أريد) ويرتبط بالربط ضد OpenGL و SDL (ديناميكيا في حالة SDL). المنصات المستهدفة هي Windows و OS X.

ما الذي أنظر إليه على الإطلاق؟

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

Answer 1

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

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

Answer 2

يمكن أن تكون مشكلة في تصدير مكتبة C ++ فئة من مكتبة ديناميكية، ولكن من الممكن.
تحتاج إلى وضع علامة على كل وظيفة يتم تصديرها من DLL (يعتمد بناء الجملة على المحول البرمجي). أنا بديل في جميع أنحاء لمعرفة ما إذا كان يمكنني العثور على كيفية القيام بذلك من Xcode. في VC It's __declspec (DLLEXPORT) وفي Codewarrior IT's Intragma Export On / # Pragma Export Off.

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

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

تشرح هذه المقالة مشكلة التسمية:http://en.wikipedia.org/wiki/name_decoration.

Answer 3

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

يمتد هذا ما يتجاوز فقط اتفاقيات الاتصال المختلفة - C ++ Code يمكن تجميعها لدعم أو عدم دعم RTTI والمعالجة الاستثناء، ومع التحسينات المختلفة التي يمكن أن تؤثر على تخطيط الذاكرة من مثيلات الطبقة، والتي تعتمد رمز C ++ عليه.

ذلك ما يمكن أن تفعله؟ سأبني مكتبات C ++ داخل شجرة المصدر الخاصة بي، وتأكد من أنهم بنوا كجزء من بناء مشروعي، وأن جميع المكتبات والرمز الذي يرتبط به استخدام نفس إشارات المحول البرمجي.

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

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