پرچمداران

اضافه کردن فایل‌های هدر هیچ تأثیری در حجم برنامهٔ نهایی نداره. فقط توابعی که کامپایل شدن (کد باینری برای اون‌ها تولید شده) در باینری نهایی جا می‌گیرن.

با سلام، طبق بررسی‌های لازم تغییراتی در گروه‌های کاربری اعمال شده است که از این پس کاربرانی که به عنوان کاربران فعال در حوزهٔ یادگیری و مشارکت در بحث‌ها فعال می‌کنند از گروه پیش‌فرض کاربران عادی به کاربران رسمی تغییر دسترسی خواهند داشت. طبق آخرین اصلاحیه در سند‌( شرایط کسب مجوز فعالیتی و ارتقا حساب‌کاربری) ، کاربران عضو در این گروه دسترسی لازم برای ارسال تصویر، افزودن امضاء و همچنین عدم نیاز به تایید مطالب توسط مدیریت را خواهند داشت.

هدر فایل کامپایل نمیشه. بخشی از هدر که در کد وارد شده کامپایل میشه. داخل ممکنه تعریف‌هایی وجود داشته باشه. مثلا: header.hpp: static const SomeComplexStruct; در این صورت خوب مسلماً فایلی که این هدر رو اینکلود کرده باشه حافظهٔ بزرگتری اشغال می‌کنه (هم توی ایمیج هم توی رانتایم). ولی در حالت کلی همهٔ چیزهایی که توی هدر هستند کامپایل نمیشن. مثلا اگر هدرها تماماً از اعلان‌های کلاس‌ها و توابع تشکیل شده باشند چیزی کامپایل نمیشه. (معمولاً داخل هدر فقط اعلان قرار داده میشه) مثال: // header.hpp struct bar { int x; int y; double z; }; class foo { public: bar x; bar y; bar z; }; #include <iostream> #include "header.hpp" // does not matter int main() { std::cout << "Hello World!\n"; return 0; } خروجی هر دو حالت: .file "main.cpp" .text .section .rodata .type _ZStL19piecewise_construct, @object .size _ZStL19piecewise_construct, 1 _ZStL19piecewise_construct: .zero 1 .local _ZStL8__ioinit .comm _ZStL8__ioinit,1,1 .LC0: .string "Hello World!\n" .text .globl main .type main, @function main: .LFB1493: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 leaq .LC0(%rip), %rsi leaq _ZSt4cout(%rip), %rdi call _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@PLT movl $0, %eax popq %rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE1493: .size main, .-main .type _Z41__static_initialization_and_destruction_0ii, @function _Z41__static_initialization_and_destruction_0ii: .LFB1977: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 subq $16, %rsp movl %edi, -4(%rbp) movl %esi, -8(%rbp) cmpl $1, -4(%rbp) jne .L5 cmpl $65535, -8(%rbp) jne .L5 leaq _ZStL8__ioinit(%rip), %rdi call _ZNSt8ios_base4InitC1Ev@PLT leaq __dso_handle(%rip), %rdx leaq _ZStL8__ioinit(%rip), %rsi movq _ZNSt8ios_base4InitD1Ev@GOTPCREL(%rip), %rax movq %rax, %rdi call __cxa_atexit@PLT .L5: nop leave .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE1977: .size _Z41__static_initialization_and_destruction_0ii, .-_Z41__static_initialization_and_destruction_0ii .type _GLOBAL__sub_I_main, @function _GLOBAL__sub_I_main: .LFB1978: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 movl $65535, %esi movl $1, %edi call _Z41__static_initialization_and_destruction_0ii popq %rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE1978: .size _GLOBAL__sub_I_main, .-_GLOBAL__sub_I_main .section .init_array,"aw" .align 8 .quad _GLOBAL__sub_I_main .hidden __dso_handle .ident "GCC: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0" .section .note.GNU-stack,"",@progbits

سلام، آیا ممکن هست در مورد منطق، ساختار و اساس کاریِ کامپایلر و همچنین تعامل آن با سیستم عامل‌ (پلتفرم‌های) مختلف توضیحاتی ارائه دهید؟ با سپاس.

با این تکه کد حل شد QByteArray ba; ba.resize(100); ba.fill(0x00); ba[0] = 0x01; port->write(ba); port->flush();

فرق بین کامپایل استاتیک و داینامیک قبل از اینکه فرق بین ایستا (استاتیک) - Static و پویا (داینامیک) - Dynamic را بدانیم لازم است در رابطه با چرخهٔ زندگی نوشتن یک برنامه و اجرای آن آشنا شویم. هر برنامه برای اولین بار توسط یک محیط توسعه (Editor) یا IDE توسط برنامه‌نویسان انتخاب و به صورت فایل متنی قابل ویرایش می‌باشد. سپس فایل متنی که شامل کد‌های نوشته شده توسط برنامه‌نویس تحت زبان برنامه‌نویسی مانند C، C++ و غیره... می‌باشد توسط کامپایلر به کد شیء ای تبدیل می‌شود که ماشین بتواند آن را درک کرده و اجرا کند. برنامه ای که ما می‌نویسیم ممکن است به عنوان یک مورد توسط دیگر برنامه ها یا کتابخانه‌هایی از برنامه ها مورد استفاده قرار بگیرد برقراری ارتباط (پیوند‌کردن - لینکر) یا همان لینک کردن پروسه‌ای است که برای اجرای موفقیت آمیز برنامه‌های نوشته شده ما بکار می‌رود؛ برقراری ارتباط بین ایستا و پویا دو پروسه‌ای از جمع‌آوری و ترکیب فایل‌های شیء‌های مختلفی است که به منظور ایجاد یک فایل اجرایی می‌باشند. در این بخش ما تصمیم بر این داریم تا تفاوت بین آن ها را با جزئیات مورد بررسی قرار دهیم. عمل پیوند یا ترکیب در زمان کامپایل انجام شود، در واقع زمانی که کد منبع به زبان ماشین ترجمه می‌شود، در زمان بارگذاری، زمانی که برنامه در داخله حافظه بارگذاری می‌شود، و حتی زمان اجرای آن توسط برنامه صورت می‌گیرد این عمل زمان پیوند و یا ترکیب (اتصال) است. در نهایت این فرآیند توسط برنامه ای اجرا می شود که به آن لینکر - پیوند دهنده (ترکیب کننده) می‌گویند. اتصال دهنده ها به عنوان ویرایستار لینک نیز معرفی می‌شوند. لینک شدن (پیوند شدن) به آخرین مرحله از کامپایل می‌گویند. در زبان علمی اصطلاح لینکر یا Linker معروف است اما در زبان فارسی بهترین گزینه مربوطه را می‌توان با عنوان اتصال دهنده، پیوند دهنده، ترکیب کننده نام برد. همه آن ها نشانگر یک هدف به منظور ترکیب اشیاء با یکدیگر هستند که در مرحله کامپایل صورت می‌گیرد. پس از ایجاد پیوند در برنامه، برای اجرای آن برنامه باید داخل حافظه منتقل شود. در انجام این کار باید آدرس هایی برای اجرای داده ها و دستور العمل ها اختصاص یابد. به طور خلاصه روند زیر می‌تواند به عنوان چرخه زندگی یک برنامه خلاصه شود (نوشتن - لینک کردن - بارگذاری - اجرا) فرق بین کامپایل استاتیک و داینامیک در زیر تفاوت های عمده ارتباط بین استاتیک و داینامیک آورده شده است : استاتیک ارتباط به روش استاتیک فرآیندی است که تمامی ماژول‌ها و کتابخانه‌های برنامه در فایل اجرایی نهایی کپی می‌شوند. این روش توسط لینکر در مرحله آخر کامپایل انجام می‌شود. اتصال دهنده - لینکر طبق روال ترکیبی کتابخانه ها را با کد برنامه و همراه مراجع - منابع خارجی ترکیب کرده و برای تولید یک بارگذاری مناسب در حافظه آماده سازی می‌کند. زمانی که برنامه بار‌گذاری می‌شود، سیستم عامل محلی را در حافظه به صورت یک فایل اجرایی که شامل کد‌های اجرایی و داده ها می‌باشد مشخص می‌کند. ارتباط به شیوهٔ استاتیک توسط برنامه‌ای با نام لینکر انجام می‌شود که در آخرین مرحله فرآیند کامپایل یک برنامه صورت می‌گیرد. لینکر‌ها نیز به عنوان ویرایشگر پیوند نیز عنوان می‌شوند. فایل های استاتیک به طور قابل توجهی دارای اندازه بسیار بزرگی هستند زیرا برنامه های خارجی و کتابخانه های لینک شده همه در یکجا و در فایل نهایی اجرایی جمع آوری شده‌اند. در اتصال استاتیک اگر هر یک از برنامه های خارجی تغییر کرده باشد باید آن ها دوباره کامپایل شوند و مجددا عمل اتصال صورت گیرد در غیر اینصورت هیچ تغییری در به روز رسانی های مرتبط با فایل اجرایی مشاهده نخواهد شد. برنامه‌های استاتیکی زمان بارگذاری ثابتی در هر بار اجرای برنامه در حافظه را در نظر می‌گیرند. و زمانی که برای بارگذاری طول می کشد ثابت است. برنامه‌هایی که از کتابخانه‌های استاتیکی استفاده می‌کنند معمولاً سریعتر از برنامه‌هایی هستند که کتابخانه‌‌ی آن‌ها به صورت پویا می‌باشد. در برنامه های استاتیکی، تمامی کد ها شامل یک فایل اجرایی می‌باشند. بنابراین، آن‌ها هرگز در برنامه هایی که دارای مشکلاتی هستند اجرا نخواهند شد. داینامیک در ارتباط پویا نام کتابخانه های خارجی (کتابخانه‌های به اشتراک گذاری شده) در فایل اجرایی نهایی قرار داده شده‌اند نه خود کتابخانه. در حالی که ارتباط واقعی در زمان اجرا در هر دو فایل در حافظه قرار می‌گیرند. اتصال پویا این اجازه را می‌دهند تا برنامه های متعددی به صورت یک ماژول کپی شده و قابل اجرا مورد استفاده قرار بگیرد. اتصال پویا بر خلاف اتصال استاتیک در زمان اجرا توسط سیستم عامل انجام می‌شود. در اتصال پویا فقط یک نسخه از کتابخانه به اشتراک گذاری شده در حافظه نگه‌داری می‌شود. این به طور قابل توجهی اندازه برنامه های اجرایی را کاهش می‌دهد، در نتیجه صرفحه جویی در حافظه و فضای دیسک صورت خواهد گرفت. در اتصال پویا بر خلاف اتصال استاتیک نیازی به کامپایل کامل پروژه نمی‌باشد در صورتی که لازم باشد تغییراتی در هر یک از فایل‌ها صورت بگیرد تنها کافی است آن را کامپایل و در کنار برنامه قرار دهید. این یکی از بزرگترین مزیت‌های کامپایل داینامیکی می‌باشد. در اتصال پویا زمان بارگذاری برنامه در حافظه ممکن است کاهش یابد. این در صورتی است که کتابخانه های مشترک در حافظه بارگذاری شده‌اند. برنامه‌هایی که از کتابخانه های مشترک استفاده می‌کنند معمولا کندتر از برنامه هایی هستند که از کتابخانه های استاتیکی استفاده می‌کنند. برنامه‌های پویا وابسته به داشتن کتابخانه‌های سازگار هستند. اگر کتابخانه تغییر یابد (برای مثال، یک کامپایلر جدید منتشر شود ممکن است کتابخانه را تغییر دهد)، در این صورت ممکن است برنامه مجدداً تحت کتابخانه جدید باز نویسی و به‌روز رسانی شوند. اگر کتابخانه از روی سیستم حذف شود، برنامه‌ای که وابسته آن کتابخانه می‌باشد دیگر کار نخواهد کرد. در ادامه شما می‌توانید در مورد مراحل کامپایل یک برنامه مراجعه کنید: