VC ++ مكتبة مشكلة اشتباك

Question

أنا أعمل على مشروع C ++ يستخدم QT (GUI LIB)، VTK (Graphics Lib) ومكتبة أخرى غامضة للغاية، ولن أذكر اسمها وسوف نسميها بدلا من ذلك lib_x. يستخدم المشروع كيو تي مكونات واجهة المستخدم الرسومية و VTK (تمديد QVTKWidget تم توفيره بواسطة VTK يدعم QT) لتقديم هندسة .. ويستخدم LIB_X لجمع ومعالجة الهندسة.

المشكلة هي أنه اتضح أن LIB_X يستخدم فعلا VTK (حيث وكيف، لا أعرف، مصدر مغلقة). في البداية لم يكن هناك أي مشكلة، حيث كانت تجميع كلا من Libs المرتبطة بخير، ولكن في مرحلة ما اتصلت بوظيفة LIB_X Lib_x (حاجة للغاية)، أدت تجميعها إلى مجموعة من "BLAH BLAH شيء عن VTK Lib / OBJ محدد بالفعل في أخطاء Lib_x DLL.

على سبيل المثال (ولاحظ هذا هو مع / القوة: متعددة لذلك، فهذا تحذير هنا، اسمحوا لي أن أعرف إذا كنت تريد الخطأ بدون / قوة: متعددة وسوف نشرها):

1>LIB_X.lib(LIB_X.dll) : warning LNK4006: "public: __thiscall std::vector<double,class std::allocator<double> >::~vector<double,class std::allocator<double> >(void)" (??1?$vector@NV?$allocator@N@std@@@std@@QAE@XZ) already defined in vtkCommon.lib(vtkInformationDoubleVectorKey.obj);

حاولت استخدام / القوة: متعددة ويبدو أنها معجزة في البداية، لكنني أحصل على أخطاء عشوائية في التعليمات البرمجية التي من شأنها أن أعطي أخطاء الكومة في الغالب. قررت إزالة جميع المراجع إلى lib_x من المشروع الرئيسي وأنشأت ليب ثابتة من شأنها أن تتعامل مع جميع الأشياء LIB_X. أنا لست خبيرا C ++، لذلك أنا لست متأكدا من كيفية معالجة اشتباكات Lib عند استخدام Lib مجمعة مسبقا، لكنني ما زلت أستلم أخطاء في اشتباكات LIB عند ربطي ببي ثابت في مشروعي الرئيسي، لذلك ما زلت يجب أن تستخدم / القوة: متعددة.

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

ملاحظة: يعطل ذلك إلى XCETIONS ON OFT LINE 151، الملوثات العضوية الثابتة للتأكيد: "ملف: dbgheap.c Line: 1279 Expression: _crtisvalideheappoiner (puserdata)"

يأتي الخطأ بعد إضافة متجه ناقلات مزدوج إلى متجه ناقلات متجه مزدوج، تحطمها على خط push_back:

std::vector<std::vector<double>> tmpVec;
for(srvl_iter = srvl.begin(); srvl_iter != srvl.end(); ++srvl_iter)
{
 tmpVec.push_back((*srvl_iter).getControlPoints());
}
this->_splines.push_back(tmpVec); //CRASH

بدأت تعطل فقط هنا عندما أضفت عضوا بيانات جديد إلى مشروعي الرئيسي (منفصل عن Lib Static!) تعليقا على عضو البيانات الجديد يأخذ الخطأ بعيدا.

std::vector<std::vector<std::vector<double>>> _geometry; 

لذلك، / القوة: متعددة تبدو سيئة، أحصل على أخطاء عشوائية لا معنى لها. هل هناك حلول أخرى؟ هل أنا ثمل؟ هل هناك شيء يمكنني القيام به مع ربط Lib_x من VTK؟

Answer 1

واجهت حفنة من LNK4006 الأخطاء عند ربط تطبيقي إلى مكتبة (مكتبة الطلب Lib_y) التي جعلت الاستخدامات الثقيلة std::vector<std::string>, ، التي فعلت أيضا في التطبيق الخاص بي. بعد قليل من التجربة وجدت حل واحد يعمل - لف

لتجربة اقتراحي، ستحتاج إلى:

1. قم بتغيير "Lib Static Tib الذي يتعامل مع جميع الأشياء LIB_X" من مشروع ثابت ليب في مشروع DLL (الذي سأتصل بي LIB_X_WRAPPER).
2. تأكد من أن ملفات الرأس من lib_x_wrapper لا تتضمن أي من ملفات رأس Lib_x. هذا هو مهم للغاية لأن الغلاف يحتاج إلى عزل التطبيق الخاص بك تماما من أنواع البيانات المعلنة في ملفات رأس Lib_x (مثل std::vector<double>). يرجى الرجوع فقط إلى ملفات رأس Lib_x من داخل الملفات المصدر من LIB_X_WRAPPER.
3. قم بتغيير إعلان جميع الطبقات والوظائف في Lib الثابت لضمان تصديرها من DLL (انظر هذه الإجابة إذا كنت بحاجة إلى تفاصيل حول التصدير من DLL).

عمل هذا الحل بالنسبة لي لأنه حافظ على إنشاء مثيل (محول البرمجيات التي تم إنشاؤها) من std::vector<std::string> الفئة المستخدمة من قبل ليبي منفصلة تماما عن مثيل std::vector<std::string> في التطبيق الخاص بي.

جانبا، أظن أن سبب الحادث الذي تراه (أنت تعلق أنه في المدمر std::vector<double>) لأن مثيل std::vector<double> في التطبيق الخاص بك يختلف عن ذلك في lib_x.

Answer 2

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

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

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