المراجع والمؤشرات: REF_TO و POINTER TO ولماذا تتجنبها

العنوان بدل القيمة

كل ما تعلمته حتى الآن يتعامل مع قيم: تنسخ رقماً إلى متغير. المؤشر والمرجع يتعاملان مع عنوان: متغير يحمل مكان متغير آخر في الذاكرة.

REF_TO

الإصدار الثالث من المعيار أضاف المرجع، وهو مؤشر مُحكم النوع:

VAR
  pTank : REF_TO T_Analog;
  LT101 : T_Analog;
END_VAR

pTank := REF(LT101);

IF pTank <> NULL THEN
  pTank^.Value := 42.0;
END_IF;

• REF(x) يأخذ مرجعاً إلى x.
• ^ يفك المرجع، أي «المتغير الذي يشير إليه هذا».
• المقارنة بـ NULL قبل أي استخدام ليست اختيارية.

POINTER TO و ADR

الشكل الأقدم، وهو موجود في أدوات مثل CODESYS و TwinCAT، وأخطر لأنه بلا تحقق من النوع:

VAR
  p : POINTER TO REAL;
  x : REAL;
END_VAR

p  := ADR(x);
p^ := 3.14;

ADR تعطي العنوان الخام. لا شيء يمنعك من إسناد عنوان INT إلى مؤشر REAL وقراءة بايتات لا معنى لها، أو من الكتابة بعد نهاية مصفوفة وتخريب متغير مجاور.

التسمية المزدوجة Aliasing

هذه هي المشكلة الحقيقية: أن يكون لنفس موضع الذاكرة اسمان.

p := ADR(Setpoint);
p^ := 80.0;        (* Setpoint صار 80، ولا يوجد سطر فيه كلمة Setpoint *)

تبحث في البرنامج كله عن Setpoint := فلا تجد شيئاً، والقيمة تتغير. أدوات البحث لا تنفع، ومراجعة الكود لا تنفع، وجدول المراقبة يخبرك أن القيمة تغيّرت ولا يخبرك من غيّرها. ساعات من التشخيص في مصنع متوقف.

ثلاثة أسباب لتجنبها في كود المصنع

1. تُلغي القراءة. قوة ST أن السطر يقول ما يفعله. المؤشر يكسر هذا: لا تعرف ما سيتغير إلا بمتابعة العنوان في وقت التشغيل.
2. تُعطّل الفحص. المترجم يحميك من إسناد INT إلى BOOL ومن فهرس خارج المدى. المؤشر الخام يطلب منك التنازل عن هذه الحماية طوعاً.
3. تُعطّل المتحكم. مؤشر غير مهيأ، أو مرجع لمتغير محلي انتهت حياته، أو عنوان خارج المنطقة المسموحة: النتيجة إما توقف المتحكم بخطأ Access Violation، أو فساد صامت في بيانات أخرى. والثاني أسوأ.

وأضف أن المؤشرات لا تنتقل بين الشركات: الصياغة والدلالات تختلف، فالكود المليء بالمؤشرات يصبح محبوساً في منصة واحدة.

متى يكون لها مكان

• داخل مكتبة تكتبها مرة، تُختبر جيداً، ويستخدمها الناس من واجهة نظيفة.
• في معالجة كتلة بيانات كبيرة من اتصال، حيث النسخ مكلف فعلاً، وبعد أن تقيس أن النسخ هو المشكلة.
• للتعامل مع أجهزة أو بروتوكولات تفرض تخطيطاً للذاكرة.

في منطق المحطة، في برنامج المحرك، في التسلسل، في معالجة الإنذارات: لا.

البدائل التي تحل نفس المشكلة

• VAR_IN_OUT عندما تحتاج كتلة أن تحدّث بياناً كبيراً يملكه البرنامج. النية واضحة، والمترجم يبقى معك.
• كتلة وظيفية بنسخ عندما تريد «نفس المنطق على بيانات مختلفة».
• مصفوفة وفهرس عندما تريد اختيار عنصر من مجموعة في وقت التشغيل. الفهرس يُحصر ويُفحص، والعنوان لا.

القاعدة

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