Boost :: Multi_array تغيير حجم الاستثناء؟

Question

أحاول معرفة ما إذا كان Boost :: Multi_array Constructor أو تغيير الحجم يمكن أن يرمي استثناء Bad_alloc (أو بعض الاستثناءات الأخرى التي تشير إلى التخصيص أو فشل تغيير الحجم). لا يمكنني العثور على هذه المعلومات في الوثائق في أي مكان.

التوضيح (إضافة من التعليق):

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

Answer 1

1: (الإجابة على السؤال الحقيقي): لأنه يستخدم الذاكرة المخصصة ديناميكيًا ، نعم ، يمكن أن يرمي std::bad_alloc (لم أر قط ترجمة تعزيز std::bad_alloc استثناءات سيكون من الجنون القيام بذلك).

الثاني: (تعليق على التوضيح الخاص بك): تحتاج إلى معلومات عن الذاكرة الفعلية المتاحة لتحسين أداء الخوارزمية في وقت التشغيل. ومع ذلك ، لا يمكنك الاعتماد عليها std::bad_alloc لتحديد مقدار الذاكرة المتوفرة ، حيث تستخدم أنظمة التشغيل الحديثة مثل هذا الشيء تجاوز, ، بمعنى: إنهم (تقريبًا) لا يعيدون أبدًا محاولة تخصيص فاشلة ، ولكن بدلاً من ذلك يمنحك بعض "الذاكرة" ، والتي ستفشل فقط في القفز إلى الوجود عندما تحاول بالفعل الوصول إليها.

في Java ، قد يعمل هذا لأن VM يقوم بالعديد من الأشياء بالنسبة لك: إنه يحاول تخصيص بعض أجزاء الذاكرة المستمرة ، ويفعل ذلك فيما يتعلق بالذاكرة الفعلية المتاحة ، والمتاحة غير مستعمل الذاكرة المادية لتقرير ما إذا كان ينبغي أن يؤكد GC أكثر أو فقط تخصيص خردة أكبر. أيضًا ، لسبب الأداء ، تحتاج إلى مراعاة أن الذاكرة الافتراضية والذاكرة الفعلية هي مفاهيم مختلفة تمامًا.

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

Answer 2

عدم وجود استثناء صريح أمر مقصود. نرى هذه القسم الفرعي لتفسير. علاوة على ذلك ، لاحظ أن عدم وجود مواصفات صريحة يعني أنه لا يوجد تقييد على نوع الاستثناء الذي يمكن أن ترميه الدالة. لذلك ، على الأقل ، يمكن لـ CTOR ودالة تغيير الحجم أن ترمي استثناءات في حالة الذاكرة مرهقة أو في حالة فشل نسخة عنصر العناصر.

بعض المراجع العامة التي ألهمت التعزيز الذي قد تهتم به هي:

• سلامة الاستثناء في المكونات العامة
• الخطأ والاستثناء معالجة

Answer 3

لماذا لا تختبرها؟ من السهل تمرير قيمة عالية سخيفة لإنشاء الاستثناء.

من ناحية أخرى ، ما الذي تخطط للقيام به إذا قام بإنشاء هذا الاستثناء؟ std::bad_alloc هو نوع الاستثناء الذي لا يمكنك التعامل معه عادة على المستوى الصغير ...

على سبيل المثال ، على خادم الويب ، يمكنك عادةً إجراء بعض التنظيف (التراجع على معاملة DB؟) ثم إرجاع أ 500 خطأ للمستخدم.

ولكن عندما يتم استنفاد الذاكرة ، لا يوجد الكثير مما يمكنك فعله بأمان ، حيث يجب عليك السير بعناية إذا كنت لا تريد مرة أخرى ضرب جدار الذاكرة الذي تعرفه إنه قريب :)