هل من الممارسات الجيدة جعل getters و etters مضمرين؟

https://stackoverflow.com/questions/3017264

26-09-2019
|

سؤال

public:
     inline int GetValue() const {
          return m_nValue;
     }
     inline void SetValue(int nNewValue) {
          this -> m_nValue = nNewValue;
     }

تشغيل تعلم C ++, ، قالوا إنها ستستمر بشكل أسرع. لذلك ، اعتقدت أنه سيكون من الرائع استخدامه على getters و setters. ولكن ربما ، هناك بعض العيوب؟

المحلول

أنا لا أضمن أي شيء حتى أخبرني البروفيلر على وجه التحديد أنه لا يؤدي عدم التحضير إلى مشكلة في الأداء.

يعد برنامج التحويل البرمجي C ++ ذكيًا للغاية ، ومن شبه المؤكد أنه سيضفي تلقائيًا مثل هذه الوظيفة البسيطة مثل هذه بالنسبة لك. وعادة ما يكون الأمر أكثر ذكاءً منك وسوف تقوم بعمل أفضل بكثير في تحديد ما ينبغي أو لا ينبغي أن يكون محصورًا.

أود أن أتجنب التفكير في ما يجب أو عدمه في التضمين والتركيز على الحل. إضافة inline الكلمة الرئيسية لاحقًا (وهي ليست ضمانًا لـ INLINE BTW) من السهل جدًا القيام بها ، ويمكن العثور على أماكن محتملة بسهولة مع Profiler.

نصائح أخرى

إذا كتبتها داخل التعريف ، فهي تعتبر inline بشكل افتراضي.

هذا يعني أنه سيتم السماح بها في وحدات تجميع متعددة (نظرًا لأن تعريفات الفئة نفسها تظهر عادةً في وحدات تجميع متعددة) ، ليس أنهم سيفعلون في الواقع يكون مضمون.

هذه ممارسة سيئة في API العامة أي تغيير في هذه الوظائف يتطلب إعادة توحيد جميع العملاء.

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

نقاط سلبية:

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

أود أيضًا أن أضيف أنه ما لم تقم بأداء ملايين Gets/Sets لكل إطار ، فهذا أمر غير ذي صلة إلى حد كبير سواء كانت مضطربة أم لا. إنه بصراحة لا يستحق فقدان النوم.

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

حاول وضع جميع تعريفات الوظائف في ملف التنفيذ ، وترك الإعلانات الخالصة للرؤوس (ما لم تكن بالطبع أنت قالب metaprogramming (STL/BOOST/etc) ، وفي هذه الحالة ، كل شيء في الرؤوس ؛)))

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

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

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

حظا طيبا وفقك الله.

شين

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

راجع للشغل ، يمكنك تخطي inline إذا كنت تنفذ مباشرة في تعريف الفصل.

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

أود أن أقول أنك لست بحاجة إلى أن تهتم بذلك. إقرأ ال قسم الأسئلة الشائعة حول الإطار.

لا حاجة ، ابدأ في الوثوق بالمترجمين ، على الأقل لمثل هذه التحسينات!
"لكن ليس دائما"

الكلمة الرئيسية المضمنة لا معنى لها في حالتك

سيقوم برنامج التحويل البرمجي بتضمين وظيفتك إذا كان بإمكانه ذلك ، بغض النظر عن الكلمة الرئيسية.

يؤثر الكلمة الرئيسية المضمنة على الارتباط وليس مضمون. إنه مربك بعض الشيء ، ولكن اقرأ عليه.

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

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

نعم ، يمكنك إسقاط inline, ، كما هو ضمني من خلال وضع التنفيذ.

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

خذ ذلك يا أصويين. :-)

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow