.TH "icmodmap" "1" "1992\-2025" "icmake\&.13\&.00\&.03" "initializes C++ projects using modules" .PP .SH "نام (NAME)" icmodmap \- مقداردهی اولیه نگهداری پروژه‌های ++C مبتنی بر ماژول‌ها .PP .SH "خلاصه دستور (SYNOPSIS)" \fBicmodmap\fP \fI[گزینه‌ها]\fP start\-directory .PP .SH "توضیحات (DESCRIPTION)" .PP اگرچه ماژول‌ها مدت قابل‌توجهی است که در دسترس هستند، اما کامپایلر \fIg++\fP گنو همچنان تعدادی باگ مربوط به ماژول‌های ++C نشان می‌دهد (ر.ک. \fIhttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524\fP). بنابراین این احتمال وجود دارد که هنگام استفاده از ماژول‌ها با برخی از این باگ‌ها (یا باگ‌های جدید) مواجه شوید. این اشکالات احتمالاً در نگارش‌های آینده کامپایلر رفع خواهند شد و وضعیت کنونی حداقل به شما اجازه می‌دهد تا در استفاده از ماژول‌ها تجربه کسب کنید. .PP ماژول‌ها نمی‌توانند متقابلاً یکدیگر را وارد (import) کنند. در نتیجه، همواره یک سلسله‌مراتب خطی و غیرحلقوی میان ماژول‌ها وجود دارد که باید هنگام کامپایل فایل‌های تعریف‌کننده و استفاده‌کننده از ماژول‌ها رعایت شود. برنامه \fBicmodmap\fP این ترتیب را تعیین کرده و زمینه ساخت ماژول‌های مورد استفاده برنامه‌ها را آماده می‌سازد. .PP برنامه \fBIcmodmap\fP فرض می‌کند که ماژول‌ها در زیردایرکتوری‌های مجزا تعریف شده‌اند و رابط‌های ماژول (به‌طور پیش‌فرض) در فایل‌هایی با نام \fImodule\&.cc\fP قرار دارند. اگر برنامه‌ای دو ماژول با نام‌های \fIFirst\fP و \fISecond\fP تعریف کند (برای مثال در زیردایرکتوری‌های \fIfirst\fP و \fIsecond\fP) و فایل \fIsecond/module\&.cc\fP ماژول \fIFirst\fP را وارد نماید، آن‌گاه فایل \fIfirst/module\&.cc\fP باید پیش از کامپایل \fIsecond/module\&.cc\fP کامپایل شود. این فرایند توسط \fBicmodmap\fP مدیریت می‌شود. پس از کامپایل فایل‌های \fImodule\&.cc\fP، مابقی فایل‌های منبع برنامه می‌توانند طبق روال همیشگی کامپایل شوند. .PP برنامه \fBIcmodmap\fP انتظار دارد پروژه‌های مبتنی بر ماژول به شکل زیر سازماندهی شده باشند: .IP o دایرکتوری ریشه پروژه حاوی فایلی به نام \fICLASSES\fP است که در آن هر خط (با نادیده گرفتن توضیحات \fBC++\fP) نام زیردایرکتوری پیاده‌سازی‌کننده یکی از مؤلفه‌های پروژه را مشخص می‌کند. همچنین می‌توان (زیرمجموعه‌ای از) زیردایرکتوری‌های پروژه را مشخص کرد. هر زیردایرکتوری می‌تواند یک ماژول، یک افراز ماژول (partition)، یک کلاس (که عضوی از ماژول نیست اما شاید از ماژول‌ها استفاده کند)، یا توابعی در سطح سراسری (که آن‌ها هم شاید از ماژول‌ها استفاده کنند) تعریف نماید؛ .IP o اگر پروژه یک برنامه اجرایی تعریف کند، دایرکتوری ریشه پروژه شامل فایل‌های منبع (مانند \fImain\&.cc\fP) تعریف‌کننده تابع \fImain\fP خواهد بود. دایرکتوری ریشه ماژولی تعریف نمی‌کند، اما سورس‌های آن می‌توانند از ماژول‌ها استفاده کنند؛ .IP o زیردایرکتوری‌های تعریف‌کننده ماژول‌ها یا افرازها به‌طور پیش‌فرض حاوی یک فایل \fImodule\&.cc\fP هستند که نام ماژول و رابط آن را تعریف می‌کند (به‌جای \fImodule\&.cc\fP می‌توان نام فایل دیگری را مشخص کرد)؛ .IP o ماژول‌ها و افرازها می‌توانند کلاس‌هایی تعریف کنند (یک کلاس به ازای هر ماژول، یک کلاس به ازای هر افراز). در این صورت توابع عضو آن کلاس‌ها در زیردایرکتوری همان ماژول یا افراز تعریف می‌شوند. .PP برنامه \fBIcmodmap\fP(1) هر یک از زیردایرکتوری‌های مشخص‌شده را بررسی می‌کند. اگر حاوی فایل \fImodule\&.cc\fP (یا نام جایگزین آن) باشد، آن فایل (که ساختار زیر را دارد) مورد بازبینی قرار می‌گیرد: .IP o اولین خط غیرخالی آن: نام ماژول یا افراز را تعیین می‌کند؛ .IP o خطوط \fIimport\fP می‌توانند هدرهای سیستمی، ماژول‌ها و/یا افرازها را مشخص کنند. .PP .SH "گزینه‌ها (OPTIONS)" .PP برنامه \fIIcmodmap\fP از گزینه‌های زیر پشتیبانی می‌کند: .IP o \fB\-\-colors\fP (\fB\-c\fP) .br به‌طور پیش‌فرض کامپایلر با استفاده از گزینه \fI\-fdiagnostics\-color=never\fP فراخوانی می‌شود. از این گزینه برای غیرفعال کردن این حالت و فعال‌سازی رنگ‌ها استفاده کنید؛ .IP o \fB\-\-dependencies\fP (\fB\-d\fP) .br با این گزینه وابستگی‌های میان ماژول‌ها نمایش داده می‌شود. فایل‌های منبع تعریف‌کننده ماژول کامپایل نمی‌شوند. خروجی \fBIcmodmap\fP ممکن است شبیه به این باشد: .nf Square:l DepSquare: Square .fi در اینجا، پسوند \fI:l\fP نشان می‌دهد که \fISquare\fP ماژولی است که توسط پروژه تعریف شده و به ماژول‌های دیگر وابسته نیست. هنگامی که تعاریف ماژول به ماژول‌های دیگر وابسته باشند، در ادامه فهرست می‌شوند: \fIDepSquare\fP ماژول دیگری است که توسط پروژه تعریف شده و به ماژول \fISquare\fP وابسته است. .IP همچنین این امکان وجود دارد که ماژول‌ها به ماژول‌های تعریف‌شده توسط پروژه‌های دیگر وابسته باشند. در این حالت ممکن است خروجی بدین صورت باشد: .nf Square:e Mod1: Square:e Mod2: Square:e Mod1 Mod3: Square:e Mod1 Mod2 .fi در این مثال، ماژول \fISquare\fP یک ماژول خارجی است که با پسوند \fI:e\fP مشخص شده است. تمام ماژول‌های دیگر به \fISquare\fP وابسته هستند و (برای مثال) \fIMod3\fP علاوه بر آن به ماژول‌های محلی \fIMod1\fP و \fIMod2\fP نیز وابسته است. در این مثال اخیر، فایل \fISquare\&.gcm\fP باید در دایرکتوری \fIgcm\&.cache\fP پروژه در دسترس باشد (می‌تواند یک پیوند نمادین به فایل اصلی باشد)؛ .IP .IP o \fB\-\-help\fP (\fB\-h\fP) .br اطلاعات نحوه استفاده را ارائه کرده و مقدار 0 را به سیستم‌عامل بازمی‌گرداند؛ .IP .IP o \fB\-\-module\fP=\fIfile\fP (\fB\-m\fP) .br به‌طور پیش‌فرض ماژول‌ها در فایل‌های منبع \fImodule\&.cc\fP تعریف می‌شوند. اگر ماژول‌ها در فایل‌های منبعی با نام‌های دیگر تعریف شده باشند، می‌توان آن نام‌ها را با استفاده از این گزینه مشخص کرد. برای مثال، هنگامی که ماژول‌ها در فایل‌های \fIinterface\&.cc\fP تعریف شده‌اند، گزینه \fI\-\-module interface\&.cc\fP را مشخص کنید. استفاده از نام‌های متفاوت برای فایل‌های تعریف ماژول در یک پروژه پشتیبانی نمی‌شود؛ .IP .IP o \fB\-\-subdir\fP (\fB\-s\fP) .br به‌طور پیش‌فرض فایل‌های کامپایل‌شده تعریف ماژول در زیردایرکتوری \fItmp/o\fP پروژه قرار می‌گیرند که در آن هر فایل کامپایل‌شده پیشوند شماره ترتیب کامپایل را دریافت کرده است (مانند \fItmp/o/1module\&.o\fP، \fItmp/o/2module\&.o\fP و غیره). با تعیین گزینه \fI\-\-subdir\fP، فایل‌های کامپایل‌شده در همان زیردایرکتوری فایل‌های تعریف ماژول قرار می‌گیرند (بدون پیشوند شماره ترتیب)؛ .IP .IP o \fB\-\-version\fP (\fB\-v\fP) .br نسخه \fBicmodmap\fP را نمایش می‌دهد. .IP .IP o \fB\-\-verbose\fP (\fB\-V\fP) .br هنگام تعیین ترتیب کامپایل ماژول‌ها و کامپایل فایل‌های تعریف ماژول، خروجی‌های بیشتری را نمایش می‌دهد. .PP .SH "مثال‌ها (EXAMPLES)" .PP برنامه زیر ماژول \fISquare\fP را در زیردایرکتوری \fIsquare\fP خود تعریف می‌کند که حاوی فایل \fImodule\&.cc\fP زیر است: .PP .nf export module Square; export { double square(double value); class Square { double d_amount; public: Square(double amount = 0); // initialize void amount(double value); // change d_amount double amount() const; // return d_amount double lastSquared() const; // returns g_squared double square() const; // returns sqr(d_amount) }; } double g_squared; .fi .PP تابع \fImain\fP ماژول \fISquare\fP را وارد کرده و از امکانات آن استفاده می‌کند. همچنین هدر سیستمی کامپایل‌شده ماژول \fIiostream\fP را نیز وارد می‌کند. آن هدر توسط \fBicmodmap\fP بررسی نمی‌شود و باید پیش از امکان کامپایل فایل \fImain\&.cc\fP در دسترس باشد. در اینجا فایل منبع \fImain\&.cc\fP آمده است: .PP .nf import Square; import ; int main(int argc, char **argv) { std::cout << \(dq\&the square of \(dq\& << argc << \(dq\& is \(dq\& << square(argc) << \(cq\&\en\(cq\&; Square obj{12}; std::cout << \(dq\&the square of 12 is \(dq\& << obj\&.square() << \(dq\&\en\(dq\& \(dq\&the last computed square is \(dq\& << obj\&.lastSquared() << \(cq\&\en\(cq\&; } .fi .PP اجرای دستور \fIicmodmap \-d \&.\fP ماژول \fISquare\fP را به عنوان یک ماژول محلی نشان می‌دهد: .PP .nf Square:l .fi .PP اجرای دستور \fIicmodmap \-V \&.\fP کامپایل فایل \fIsquare/module\&.cc\fP را نشان می‌دهد: .PP .nf Module: Square square: /bin/g++ \-\-std=c++26 \-fdiagnostics\-color=never \-c \-fmodules\-ts \-Wall \-o \&.\&./tmp/o/1module\&.o module\&.cc .fi .PP همچنین زیردایرکتوری \fIgcm\&.cache\fP را تعریف می‌کند که حاوی \fISquare\&.gcm\fP و پیوند نمادین \fIusr \-> /usr\fP است، و به دلیل این پیوند نمادین، کامپایلر فایل‌های هدر سیستمی کامپایل‌شده ماژول را پیدا می‌کند. همچنین پیوند نمادین \fIsquare/gcm\&.cache \-> \&.\&./gcm\&.cache\fP را ایجاد می‌کند: این پیوندهای نمادین در تمام زیردایرکتوری‌های مورد استفاده برنامه تعریف می‌شوند و به تمام فایل‌های منبع در همه زیردایرکتوری‌های برنامه اجازه می‌دهند تا تمام ماژول‌های تعریف‌شده در دایرکتوری \fIgcm\&.cache\fP دایرکتوری اصلی را وارد کنند. .PP .SH "همچنین ببینید (SEE ALSO)" \fBicmake\fP(1)\&. .PP .SH "گزارش باگ‌ها (BUGS)" گزارش نشده است\&. .PP .SH "حق نشر (COPYRIGHT)" این نرم‌افزار آزاد است که تحت شرایط مجوز عمومی همگانی گنو (GPL) توزیع شده است\&. .PP .SH "نویسندگان (AUTHORS)" Frank B\&. Brokken (\fBf\&.b\&.brokken@rug\&.nl\fP)\&. .PP