طلبي غير مُدار. من أين أبدأ في تقديم الرمز المدارة؟

Question

طلبي بأكمله (وهو كبير إلى حد ما ، مع تنفيذ 20 ميجابايت) مكتوبة في C ++ غير المدير. لأنني أستطيع أن أرى بوضوح المزايا في استخدام التعليمات البرمجية المدارة ، أريد أن أبدأ في تقديم التعليمات البرمجية المدارة في طلبي ، ولكن من أين أبدأ؟

هل يمكنني البدء بسهولة في استخدام C ++/CLI وربطه مع بقية طلبي؟ (على الرغم من أن بناء جملة C ++/CLI يبدو "غريبًا").

أم أنه من الأفضل الانتقال إلى C#، ولكن ما هي أفضل طريقة "لربط" هذا مع رمز C ++ غير المدير الخاص بي؟

هل من المنطقي تجميع كل رمز C ++ الخاص بي مع خيار /CLR؟ هل سيعمل هذا؟

هل يجب أن تقلق بشأن التنظيم؟ هل هذا يعطي النفقات العامة أو هل يمكنني التبديل بين المدارة وغير المُدار دون عقوبة أداء (تمامًا كما فعلت قبل 20 عامًا عند خلط Fortran و C). الأداء مهم حقًا في طلبي لأنه تطبيق علمي يعالج أحيانًا عدة جيجابت من الذاكرة.

أم أنه من المنطقي فقط إعادة تصميم واجهة المستخدم ، واكتب هذا فقط في C#، والحفاظ على بقية طلبي (منطق الحساب ، منطق العمل ، واجهة قاعدة البيانات ، ...) في C ++ غير المُدار؟

نظرًا لأن طلبي يحتاج أحيانًا إلى التعامل مع عدة جيجابت من الذاكرة ، لدي متغير 64 بت. هل من السهل الحصول على رمز مُدار 64 بت؟ woudl لا يزال جامع القمامة فعالا إذا تم استخدام هذا الذاكرة الكثيرة؟

ببساطة الدولة: من أين أبدأ؟

باتريك

Answer 1

في الوقت الحالي ، فكر في هذا السؤال مغلق.

أدركت أن الإجابة لا تخلط C ++ و C#، ولكن الحصول على الهندسة المعمارية في المقام الأول.

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

فيما يتعلق بمشاكل الأداء أثناء التنقل ، سيتعين علينا الانتظار حتى ينضج .NET.

Answer 2

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

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

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

أيضًا قم ببنية عملك بشكل مثالي حتى تتمكن من تراجع الواجهة للعودة إلى 100 ٪ C ++ عند انخفاض القبعة إذا ضربت عقبة.

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

Answer 3

نحن نفعل بالضبط ما وصفته في تطبيق مهمة يستخدمه الآلاف من المستخدمين. في الأساس ، احتفظنا بالتطبيق الحالي كما هو ، لذلك لا يزال القابل للتنفيذ قابل للتنفيذ بنسبة 100 ٪ (وليس C ++/CLI). ثم نضع كل رمز C# الجديد في .NET DLLS والذي يتكون من كائنات الأعمال وعناصر التحكم في المستخدم ورمز واجهة المستخدم الرسومية ، إلخ ...

في الأساس ، يتم كتابة جميع الكود الجديد في C#. لدينا 1 DLL التي هي C ++/CLI التي هي مجرد الغراء. هذا يتيح لنا بسهولة بين الكود المدار وغير المُدار ، دون الحاجة إلى جعل رمز C ++ الحالي CLR. هذا يحد من كمية C ++/CLI التي يتعين علينا الكتابة. يتحدث الرمز الأصلي إلى رمز الوضع المختلط ، والذي يمكنه التحدث إلى الكود المدار. يمكن لـ DLL Moded Mode DLL ربط الأحداث على فئات C# بحيث يمكن لرمز C# إطلاق النار على الحدث للتواصل مع C ++/CLI (والذي يمكنه التحدث إلى الكود الأصلي).

يمكننا أيضًا استضافة .NET USERCONTROLS في تطبيق C ++ الحالي (WinForms هو مجرد غلاف حول Winapi على أي حال ، لذلك يعمل بشكل جيد).

هذا يعمل بشكل جيد للغاية ويتيح لك الاحتفاظ برمزك الحالي دون الحاجة إلى إعادة كتابة واجهة المستخدم الرسومية بأكملها في C#.