توصیه شده, مقاله

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

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

 

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

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

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

 

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

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

C comment

 

نکته آخر

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

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

سعید حقیقی پور

درباره سعید حقیقی پور

تا حالا به این فکر کردین که تو یه سیستم کامپیوتری GPU چقدر کارآمد و مهمه ولی به اندازه CPU شناخته شده نیست.یه جورایی همون "مجهولون فی الارض معروفون فی السماء" که میگن! یه حسی بهم میگه کاش بتونم مثه GPU باشم :)

انتشار مطالب با ذکر نام و آدرس وب سایت سیسوگ، بلامانع است.

شما نیز میتوانید یکی از نویسندگان سیسوگ باشید.   همکاری با سیسوگ

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

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

  1. حسین سیدی حسین گفت:

    سلام
    ممنون خیلی ساده و روان بود مرسی
    اگه میشه این سبک اموزش رو بیشتر کنید دستتون درد نکنه

  2. اصغر فرهادی گفت:

    ممنون بابت مطلب.
    لطفا بازم آموزش های مرتبط با هک و نفوذ هاتون رو بیشتر کنید یکی از بهترین مقاله هایی که خوندم هک ماینر عملیات غیر ممکن شما بود .

    1. Sisoog Os Sisoog Os گفت:

      سلام انشاله سعی خواهیم کرد

  3. حسین گفت:

    سلام .
    سپاس خسته نباشید.
    مطلب جالبی بود .
    در مورد تعریف متغیر در هدر فایلها :
    مگر اون گارد از تعریف مجدد جلوگیری نمیکنه ؟!!!
    تا اونجایی که میدونم اون دستورهای داخل include guard در صورت تکراری بودن اصلا کمپایل نمیشه .
    میشه بیشتر توضیح بدید؟

    1. سلام
      ممنون از لطفتون
      بله وظیفه اصلی این گاردها همین هستش.در واقع همونطور که تو مقاله هم اشاره کردم در صورتی که براثر اشتباه برنامه نویس یا به هر دلیلی یک هدرفایل تو یه پروژه بیش از یکبار تعریف بشه برنامه یکی از این دو تعریف رو انتخاب میکنه و بقیه رو نادیده میگیره.در واقع اون دستور ifndef# یعنی اگر “تعریف نشده بود…”

      1. حسین گفت:

        پس چه مشکلی برای تعریف متغیر های عمومی داخل فایل هدر هست ؟