هل تخصيص كائن تطهير / صفيف ضروري حقا في VB6 / VBA (إيجابيات / سلبيات؟)

Question

الكثير مما تعلمته عن VB الذي تعلمته من استخدام تحليل الكود الثابت (خاصة محلل مشروع AIVOSTO). وواحد من الأشياء التي يتحقق منها هو ما إذا كنت تقوم بمسح جميع الكائنات والمصفوفات أم لا. اعتدت أن أفعل هذا عمياء لأن السلطة الفلسطينية قالت ذلك. ولكن الآن أعرف أكثر قليلا عن الطريقة التي يطلقها VB الموارد، يبدو لي أن هذه الأشياء يجب أن تحدث تلقائيا. هل هذه ميزة إرث من Pre VB6، أو هل هناك سبب لعدم تعيين الكائنات بشكل صريح إلى لا شيء واستخدام محو الصفائف؟

Answer 1

المشكلة، كما أفهمها، يجب أن أفعل مع حقيقة أن VB6 (ولفئها) لها جذورها في COM، ونظام جمع القمامة المرجعي المرجعي.

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

الآن، لم تتم كتابة جميع مكونات COM في Visual Basic. كتب البعض في C أو C ++. تعامل الاستثناء المنظم لم يكن موجودا في جميع اللغات. لذلك إذا حدث خطأ، فإن العد المرجعي على الكائن غير مضمون ليتم تقليله بشكل صحيح، وكان من المعروف أن كائنات COM كانت تعرف على أطول مما كان يهدف إليه. لم تكن هذه مشكلة في Visual Basic، في حد ذاتها. كانت مشكلة كوم. (وهذا، قد تلاحظ، لماذا لا يستخدم .NET حساب المرجع.)

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

بالتأكيد، قد يكون Visual Basic أفضل أو أسرع في متغيرات dereferencing التي أعلنتها على المكدس. لكن اللعنة، أريد أن يكون من الواضح أن هذه الأشياء قد تم إصدارها. القليل من الضمان يقطع شوطا طويلا عندما تحاول تعقب تسرب الذاكرة.

Answer 2

مات كورلاند، مؤلف متقدم Visual Basic 6, من يعرف المزيد عن Visual Basic من معظمنا، يعتقد أنه جهد مضيعا. فكر في هذا الاقتباس (P110) حول DAO، ومكتبة الوصول إلى بيانات COM التي تستهدف في المقام الأول مشغل قاعدة بيانات Access:

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

Answer 3

هل قرأت هذا AIVOSTO صفحة الويب (من منشئو محلل المشروع)؟

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

بمعنى آخر، لا داعي للقلق بشأن تطهير المتغيرات العادية وغير الثابتة والمحلية.

Answer 4

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

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

Answer 5

نعم، تعيين جميع الكائنات إلى لا شيء وتنظيف قدر الإمكان. VB6 سيئة السمعة لعقد تسرب الذاكرة عند عدم تنظيف الأشياء الخاصة بك. تم جمع القمامة الفرعية الاسمية في VB6 / VBA.