مؤشرات أو مراجع للأعضاء المخصصة ديناميكيا الموجودين دائما؟

Question

عندي حصة دراسية CContainer هذا لديه بعض الأعضاء CMemberX, CMemberY, ، وهي مستقلة عن بعضها البعض وغيرها CClientA, CClientB الفصول التي تستخدم CContainer.

#include "MemberX.h"
#include "MemberY.h"

class CContainer
{
public:
    CMemberX & GetX() const { return m_x; }
    CMemberY & GetY() const { return m_y; }

private:
    CMemberX m_x;
    CMemberY m_y;
};

أريد أن أتجنب الاضطرار إلى إعادة ترجمة الجميع CClient الفصول عند تعديل أحد CMember الفصول باستخدام الإعلانات إلى الأمام والتخصيص الديناميكي لـ m_x و m_y.

في البداية ، جعلت مؤشرات الأعضاء:

// Container.h
class CMemberX;
class CMemberY;

class CContainer
{
public:
    CContainer();
    ~CContainer();

    CMemberX & GetX() const { ASSERT(m_pX != NULL); return *m_pX; }
    CMemberY & GetY() const { ASSERT(m_pY != NULL); return *m_pY; }

private:
    CMemberX* m_pX;
    CMemberY* m_pY;
};

// Container.cpp
#include "Container.h"
#include "MemberX.h"
#include "MemberY.h"

// Allocate members on heap
CContainer::CContainer() : m_pX(new CMemberX()), m_pY(new CMemberY()) {}
CContainer::~CContainer() { delete m_pX; delete m_pY; }

ثم اعتقدت أنه يمكنني استخدام المراجع بدلاً من المؤشرات ، لذلك يبدو أشبه بالرمز الأصلي:

// Container.h
class CMemberX;
class CMemberY;

class CContainer
{
public:
    CContainer();
    ~CContainer();

    CMemberX & GetX() const { return m_x; }
    CMemberY & GetY() const { return m_y; }

private:
    CMemberX & m_x;
    CMemberY & m_y;
};

// Container.cpp
#include "Container.h"
#include "MemberX.h"
#include "MemberY.h"

// Allocate members on heap
CContainer::CContainer() : m_x(*new CMemberX()), m_y(*new CMemberY()) {}
CContainer::~CContainer() { delete &m_x; delete &m_y; }

ما لا يعجبني في أعضاء المؤشر هو ذلك تبدو مثل المؤشرات يمكن أن تكون NULL أو يتم استبدال الكائنات في وقت التشغيل ، وهذا ليس هو الحال.

ما لا يعجبني في الإشارات هو أن الكود في CTOR و DTOR يبدو مخترقًا بعض الشيء.

ما هو النهج الأفضل؟ هل هناك حل أفضل؟

ملاحظة بخصوص النسخ/التخصيص: حالات CContainer لن يتم نسخ أو تعيين فئة تحت أي ظرف من الظروف.

Answer 1

أعتقد أن هذا هو ما هي متغيرات Const لـ:

CMember * const m_x;

لا يمكن تغيير m_x بعد التهيئة ...

Answer 2

أعتقد أنه من المدهش بعض الشيء استخدام مرجع عندما يكون هناك دلالات الملكية. لا بالضرورة اجعلها فكرة سيئة ، كل الأشياء التي تم النظر فيها ، لكنها تزن.

أعتقد أنني لم أستخدم المراجع إلا كأعضاء في الحالات التي: كلاهما:

• يتم توفير كائن إلى المُنشئ ، وهو أمر مطلوب لتفوق هذا الكائن.
• المهمة ممنوع على أي حال.

على سبيل المثال ، يمكن أن تكون التبعيات المحقونة مثل كائنات المصنع أو الخدمة مناسبة. مقابل ذلك ، في C ++ غالبًا ما تفضل حقن التبعيات باستخدام معلمات القالب بدلاً من الكائنات ، وبالتالي قد لا تنشأ المشكلة.

أجد أيضًا أنه كلما طالت مدة استخدام C ++ ، كلما أريد أن تكون الأنواع قابلة للتخصيص ما لم يكن هناك سبب وجيه حقًا لعدم وجوده. الخدعة المعتادة لتقليل التبعيات وقت التجميع بالطريقة التي تريدها هي "pimpl" ، وليس "rimpl" ، لسبب ما. من خلال التحول من عضو كائن إلى عضو مرجعي ، فأنت تقوم بتصنيع فئة غير قابلة للتطبيق ، حيث ربما كان قابلاً للنسخ في السابق. يجب ألا تقيد تفاصيل التنفيذ هذه واجهة الفصل. مع PIMPL ، يمكنك تنفيذ المهمة والمبادلة بشكل نظيف. مع هذه المراجع ، يتعين عليك تعيين أو تبادل كلا الأعضاء. إذا فشل المبادلة الثانية ، فقد فقدت ضمان الاستثناء القوي: على الرغم من أن فصول CMEMBERX و CMEMBERY الخاصة بك لديها مهمة عدم الفشل ومبادلة ، فإن هذا لا يهم.

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

Answer 3

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

Answer 4

طريقة سريعة فائقة التكنولوجيا الفائقة التي اعتدت عليها التحقق من أن موازنة التحميل يعمل كما هو متوقع هو مقارنة النشاط في سجلات IIS بين الخوادم المختلفة لتطبيق SharePoint Web.في حالتك، يبدو أنك تقوم بمزيد من الفشل أكثر من موازنة التحميل مما يعني أن معظم (إن لم يكن جميعا) من حركة مرور الويب يجب أن تكون في WFE، لذلك يجب أن يكون ملف سجل IIS كبيرا ونشطا في حين سجل IISيجب أن يكون خادم التطبيق الخمول أو الخمول تقريبا.

هناك أشياء يمكن أن تخفف سجل خادم التطبيقات IIS، مثل المجنزرة، ولكن أولئك الذين عادة ما يكون لديهم سلسلة UserAgent مميزة ويمكن استبعادها.

سأكون فضوليا إذا كان لدى شخص ما وسيلة أكثر دقة للتحقق منه، إلا أن

Answer 5

لقد ذكر ستيف جيسوب بالفعل المصطلح PIMPL في النجاح ، لكنني أعتقد أنه يجب عليك التحقق من ذلك إذا لم تكن قد صادفته بالفعل: تجميع جدران الحماية

Answer 6

ربما هناك واحد من شيئين يحدث هنا:

1. حدث تحميل صفحتك يتم استدعاء قبل حدث الصفحة الرئيسية.
2. تحكمك في حاوية تسمية مدفونة في شجرة التحكم الخاصة بك.

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

   إذا كنت تعرف مدى عمق التحكم، فيمكنك القيام به .FindControl (). findcontrol.findcontrol () إلخ. ولكن هذا هش.

   رأيت مؤخرا شخص ما (POPA D. Stelian) استخدم قائمة مرتبطة بهذا.اعتقدت أن هذا كان نهجا مثيرا للاهتمام: giveacodicetagpre.

   التحيات، مايك شارب

Answer 7

أنت لا تشتري لنفسك أي شيء حقًا.
(وقت ترجمة أقصر قليلاً في المواقف المحدودة).

لكنك تتكمل مجموعة كبيرة من التعليمات البرمجية الأخرى التي يجب الحفاظ عليها على صحنك.

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

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

نظرًا لأنه يقف الإصدارات 2 و 3 (من الكود في السؤال) معيب بشكل خطير والنسخة الوحيدة التي تعمل بالفعل هي 1.

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

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