صوت ارتطام

على الرغم من أن صناعة البرمجيات اعتمدت إلى حد كبير على التقييم بالقيمة والتقييم بالمرجع ، ^{[ 5 ]} إلا أن دراسة التقييم بالاسم استمرت في مجتمع البرمجة الوظيفية . وقد أسفر هذا البحث عن سلسلة من لغات البرمجة ذات التقييم الكسول ، حيث يُعدّ أحد أشكال التقييم بالاسم استراتيجية التقييم القياسية. وقد اعتمدت مُجمِّعات هذه اللغات، مثل مُجمِّع غلاسكو هاسكل ، بشكل كبير على الدوال المؤقتة (thunks)، مع ميزة إضافية تتمثل في حفظ هذه الدوال لنتائجها الأولية لتجنب إعادة حسابها؛ ^{[ 6 ]} ويُعرف هذا باسم التخزين المؤقت أو التقييم عند الحاجة .

أتاحت لغات البرمجة الوظيفية للمبرمجين إمكانية إنشاء دوال وسيطة (thunks) بشكل صريح. ويتم ذلك في الشيفرة المصدرية عن طريق تغليف تعبير وسيط بدالة مجهولة لا تحتوي على أي معلمات خاصة بها. يمنع هذا التعبير من التقييم حتى تستدعي دالة أخرى الدالة المجهولة، محققًا بذلك نفس تأثير الاستدعاء بالاسم. ^{[ 7 ]} وقد ساهم اعتماد الدوال المجهولة في لغات برمجة أخرى في إتاحة هذه الإمكانية على نطاق واسع.

تُعدّ الدوال المساعدة (Thunks) مفيدة في منصات البرمجة كائنية التوجه ، حيث تسمح للفئة بتوريث واجهات متعددة ، مما يؤدي إلى حالات يمكن فيها استدعاء نفس الدالة عبر أي من هذه الواجهات. يوضح الكود التالي مثل هذه الحالة في لغة C++ .

class A { public : virtual int Access () const { return value_ ; }خاص : قيمة عددية _ ؛ };class B { public : virtual int Access () const { return value_ ; }خاص : قيمة عددية _ ؛ };class C : public A , public B { public : int Access () const override { return better_value_ ; }خاص : عدد صحيح better_value_ ؛ };int use ( B * b ) { return b -> Access (); }int main () { // ... B some_b ; use ( & some_b ); C some_c ; use ( & some_c ); }

في هذا المثال، سيحتوي الكود المُولّد لكل من الفئات A وB وC على جدول توجيه يُمكن استخدامه لاستدعاء Accessكائن من ذلك النوع، عبر مرجع من نفس النوع. تحتوي الفئة C على جدول توجيه إضافي، يُستخدم لاستدعاء Accessكائن من النوع C عبر مرجع من النوع B. سيستخدم التعبير جدول b->Access()التوجيه الخاص بالفئة B أو جدول C الإضافي، اعتمادًا على نوع الكائن الذي يُشير إليه b. إذا كان يُشير إلى كائن من النوع C، فيجب على المُصرّف التأكد من أن Accessتنفيذ الفئة C يتلقى عنوان مثيل للكائن C بأكمله، بدلاً من الجزء B الموروث من ذلك الكائن. ^{[ 8 ]}

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

يُعاني الحل الموصوف آنفًا من مشاكل مشابهة للتنفيذ البسيط لتقنية الاستدعاء بالاسم المذكورة سابقًا: إذ يُنشئ المُصرّف نسخًا متعددة من التعليمات البرمجية لحساب وسيط (عنوان الكائن)، مع زيادة أحجام جداول التوزيع لاستيعاب الإزاحات. وكبديل، يُمكن للمُصرّف إنشاء دالة وسيطة (thunk) مع تنفيذ لغة C، Accessتُعدّل عنوان الكائن بالمقدار المطلوب ثم تستدعي الدالة. يُمكن أن تظهر هذه الدالة الوسيطة في جدول توزيع C للدالة B، مما يُغني المُستدعين عن تعديل العنوان بأنفسهم. ^{[ 9 ]}

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

تتعلق معظم الدراسات المنشورة حول تقنيات التوافق التشغيلي (Thunks) بمنصات ويندوز المختلفة ^، بما في ذلك MS -DOS و OS/2 [ ^{10 ]} وويندوز ^{[ 11 ] [ 12 ] [ 13 ] [ 14 ]} و .NET ، وبالانتقال من عنونة الذاكرة 16 بت إلى 32 بت . ومع انتقال المستخدمين من منصة إلى أخرى، أصبحت تقنيات التوافق التشغيلي ضرورية لدعم البرامج القديمة المصممة للمنصات الأقدم. ويُعد UEFI CSM مثالًا آخر على استخدام تقنيات التوافق التشغيلي مع برامج الإقلاع القديمة .

يستخدم الانتقال من التعليمات البرمجية 32 بت إلى 64 بت على معالجات x86 أيضًا نوعًا من تقنية الربط ( WoW64 ). مع ذلك، ولأن مساحة عناوين x86-64 أكبر من تلك المتاحة للتعليمات البرمجية 32 بت، لم يكن بالإمكان استخدام آلية "الربط العام" القديمة لاستدعاء التعليمات البرمجية 64 بت من التعليمات البرمجية 32 بت. ^{[ 15 ]} الحالة الوحيدة لاستدعاء التعليمات البرمجية 32 بت للتعليمات البرمجية 64 بت هي في تقنية الربط التي تستخدمها WoW64 لواجهات برمجة تطبيقات Windows إلى 32 بت.

في الأنظمة التي تفتقر إلى أجهزة ذاكرة افتراضية تلقائية ، يمكن لـ thunks تنفيذ شكل محدود من الذاكرة الافتراضية يُعرف باسم overlays . باستخدام overlays، يقسم المطور كود البرنامج إلى أجزاء يمكن تحميلها وتفريغها بشكل مستقل، ويحدد نقاط الدخول إلى كل جزء. يجب على أي جزء يستدعي جزءًا آخر أن يفعل ذلك بشكل غير مباشر عبر جدول التفرع . عندما يكون جزء ما في الذاكرة، تنتقل إدخالات جدول التفرع الخاصة به إلى ذلك الجزء. عند تفريغ جزء ما، تُستبدل إدخالاته بـ "وحدات إعادة تحميل thunks" التي يمكنها إعادة تحميله عند الطلب. ^{[ 16 ]}

وبالمثل، يمكن للأنظمة التي تربط وحدات البرنامج ديناميكيًا أثناء التشغيل استخدام الدوال الوسيطة (thunks) لربط هذه الوحدات. إذ يمكن لكل وحدة استدعاء الوحدات الأخرى من خلال جدول الدوال الوسيطة الذي يملأه الرابط عند تحميل الوحدة. وبهذه الطريقة، يمكن للوحدات التفاعل دون معرفة مسبقة بمواقعها في الذاكرة. ^{[ 17 ]}

• واجهة الوضع المحمي لنظام التشغيل DOS (DPMI)
• خدمات الوضع المحمي لنظام DOS (DPMS)
• J/Direct
• طبقة مايكروسوفت لليونيكود
• خدمات استدعاء المنصة
• Win32s
• ويندوز على ويندوز
• وحدة دعم التوافق
• WoW64
• libffi
• Wine (منذ الإصدار 9.0) ^{[ 18 ]}

• وظيفة مجهولة المصدر
• المستقبل والوعود
• إجراء مكالمة عن بعد
• شيم (الحوسبة)
• الترامبولين (الحوسبة)
• التعبير القابل للاختزال