هل من المقبول استخدام Boost :: PTR المشترك في واجهة DLL؟

Question

هل من المفيد تطوير DLL في C ++ التي تُرجع مؤشرات Boost المشتركة وتستخدمها كمعلمات؟

إذن ، هل من المقبول تصدير وظائف مثل هذه؟

1.) boost::shared_ptr<Connection> startConnection();
2.) void sendToConnection(boost::shared_ptr<Connection> conn, byte* data, int len);

بشكل خاص: هل يعمل عدد المرجعية عبر حدود DLL أم أن الشرط هو أن EXE و DLL يستخدمان نفس وقت التشغيل؟

القصد من ذلك هو التغلب على مشاكل ملكية الكائن. لذلك يتم حذف الكائن عندما لا يشير كل من DLL و EXE إلى أي وقت مضى.

Answer 1

وفقًا لـ Scott Meyers في C ++ الفعالة (الإصدار الثالث) ، فإن Servent_ptrs آمنة عبر حدود DLL. يحتفظ كائن shared_ptr بمؤشر إلى المدمر من DLL الذي أنشأه.

في كتابه في البند 18 ، يقول ، "ميزة لطيفة بشكل خاص لـ TR1 :: shared_ptr هي أنها تستخدم تلقائيًا Deleter لكل خطأ في القضاء يتم إنشاء الكائن باستخدام جديد في مكتبة واحدة مرتبطة ديناميكيًا (DLL) ولكن يتم حذفها في DLL مختلفة. على العديد من المنصات ، يؤدي هذه الأزواج الجديدة/الحذف إلى أخطاء وقت التشغيل. يستخدم الحذف من نفس DLL حيث يتم إنشاء TR1 :: shared_ptr. "

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

الجانب السلبي المحتمل الآخر هو التأكد من إنشاء كلا الجانبين مع إصدارات متوافقة من مكتبة Boost. لقد كان Boost's Servent_ptr مستقرًا لفترة طويلة. على الأقل منذ ذلك الحين 1.34 لقد تم توافق TR1.

Answer 2

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

Answer 3

لا تملك DLLs عادة الموارد - الموارد مملوكة للعمليات التي تستخدم DLL. من المحتمل أن تكون أفضل حالًا لإعادة مؤشر عادي ، ثم تقوم بتخزينه في مؤشر مشترك على جانب الاتصال. ولكن بدون مزيد من المعلومات ، من الصعب أن تكون متأكدًا بنسبة 100 ٪ حول هذا الموضوع.

Answer 4

شيء للبحث عنه إذا قمت بفضح المؤشرات الأولية من واجهة DLL. إنه يجبرك على استخدام DLL CRT المشترك ، لا يمكن تخصيص الذاكرة المخصصة في CRT في CRT مختلفة. إذا كنت تستخدم DLL CRT المشتركة في جميع وحداتك (DLL's & Exe's) ، فأنت بخير ، فكلهم يشاركون نفس الكومة ، إذا لم تكن تعبر CRT وسوف ينهي العالم.

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

Answer 5

لا ليست كذلك.

تخطيط boost::shared_ptr<T> قد لا يكون هو نفسه على جانبي حدود DLL. (يتأثر التصميم بإصدار برنامج التحويل البرمجي ، و pragmas التعبئة ، وخيارات التحويل البرمجي الأخرى ، وكذلك الإصدار الفعلي من رمز مصدر Boost.)

فقط "التخطيط القياسي" (مفهوم جديد في C ++ 11 ، المتعلق بمفهوم "POD = Data Old Data" القديم) يمكن تمريره بأمان بين الوحدات النمطية المصممة بشكل منفصل.