از نرم افزار تا سخت افزار – قسمت سوم – هدر فایل (Header file)

در قسمت دوم با انواع کامپایلر آشنا شدیم و نکات تکمیلی را بیان کردیم. حال در این قسمت می‌خواهیم ببینیم چطور میشه یه هدر فایل برای پروژمون ایجاد کنیم و اینکه اصولاً تو نوشتن یه هدر فایل رعایت چه نکاتی اهمیت پیدا میکنه. خب اولین موضوعی که لازمه بهش بپردازیم اینه که هدفمون از این کار چیه؟
تو برنامه نویسی اصولی معمولاً رسم بر این هستش که تا جایی که ممکنه کدهایی رو که می‌نویسیم به نحوی باشه که بتونیم تو پروژه‌های دیگه و یا برای پلتفرم‌های دیگه هم استفاده شون کنیم یا به عبارت بهتر Portable باشن به همین خاطر هم مهندسای نرم افزار به سمت برنامه نویسی ماژولار حرکت کردند. یکی از ارکان اصلی برنامه نویسی ماژولار هم هدر فایل ها هستند که در شامل اطلاعاتی هستند که در فایل اصلی پروژه آورده نمیشن و تنها به include کردن همین هدر فایل بسنده میکنن.

ساختار هدر فایل

ساختار یک هدر فایل رو به صورت زیر معمولاً می‌نویسند:

اولین خط این کد مربوط به موضوعی هست به اسم “include guard” که باعث میشه اگه به اشتباه این هدر فایل رو در بیش از یک جا تعریف کنیم خطای کامپایل آزمون نگیره و تنها یک مورد رو به عنوان بدنه هدر فایل انتخاب کنه و بقیه رو نادیده بگیره. البته برای این موضوع روش دیگه ای هم هست به این صورت که کافیه در ابتدای این هدر فایل عبارت #pragma once رو قرار بدیم. البته این روش مشکلی که داره عدم پشتیبانی برخی از کامپایلرها از Pragma هستش که خب باعث میشه کدمون قابلیت حمل پذیری (Portable) رو از دست بده.
برای نام گذاری هم تو ساختاری که معرفی شد معمولاً به این صورت عمل میکنن که اسم فایل رو با حروف بزرگ قرار میدن.مثلاً تو همین مثال احتمالاً اسم هدر فایل که این کد رو داخلش داره test.h بوده!

باید ها و نباید ها!

برای تعریف متغیرها از هدرفایل استفاده نمی‌کنیم چون به ازای هربار Include شدنش این متغیرها هم تعریف میشن که ممکنه باعث از دست رفتن بخشی از حافظه بشه که خب تو سیستم‌های امبدد برامون اهمیت زیادی داره!
لازمه تو هدر فایل برای افزایش خوانایی کامنت هایی رو برای توابع قرار بدیم که توضیحاتی راجع به عملکرد اون تابع، ورودی هاش و خروجی‌های تولیدیش رو داشته باشه. تو تصویر زیر میتونید نمونه از این نوع کامنت رو ببینید:

نکته آخر

به عنوان آخرین نکته هم اینکه ما چون تو سیستم‌های امبدد به علت محدودیت‌های حافظه‌ای موجود نیاز داریم تا بهینه‌ترین و کم حجم‌ترین کدها رو بنویسیم لازمه با انواع کتابخونه های از پیش کامپایل شده که میتونن به پروژه مون اضافه بشن هم اطلاعاتی کسب کنیم. اولین نوع از کتابخونه ها اونایی هستن که بهشون میگن static و به صورت مستقیم به فایل اجرایی ما لینک میشن و بر روی پلتفرم قرار میگیرن. نوع دوم که بیشتر برای پردازنده‌هایی با قابلیت اجرای سیستم عامل استفاده میشن Shared library ها هستند که به صورت دینامیک و در run time برنامه اضافه میشن. این کتابخونه ها به صورت پیشفرض روی سخت افزار برخی از پلتفرم‌ها پیاده سازی شدند. خب طبیعیه نوع دوم کتابخونه ها باعث میشه حجم فایل اجرایی کاهش چشمگیری پیدا کنه که البته یه مزیت محسوب میشه اگرچه نیاز به یه سیستم عامل داریم که خب خودش دردسرهای خاص خودشو داره.

در قسمت چهارم، به آخرین مراحل آماده‌سازی کد برای پیاده‌سازی روی سخت‌افزار می‌رسیم.