جستجو در تالارهای گفتگو
در حال نمایش نتایج برای برچسب های 'کامپایلر'.
11 نتیجه پیدا شد
-
با سلام این خطا رو چطور میشه رفع کرد؟ ifndef _CXX0X_WARNING_H# 1 define _CXX0X_WARNING_H # if __cplusplus < 201103L# #error This file requires compiler and library support for the \# ISO C++ 2011 standard. This support is currently experimental, and must be \# enabled with the -std=c++11 or -std=gnu++11 compiler options endif# endif#
-
با سلام من تازه برنامه نویسی ++c رو شروع کردم که از visual sudio و کامپایلر mingw استفاده میکنم. ولی در اولین کاری که شروع کردم با ارور زیر برخورد کردم undefined reference to `WinMain@16' collect2.exe: error: ld returned 1 exit status لطفاً من رو راهنمایی کنید که مشکل کجاست خیلی ممنون
-
کامبیز اسدزاده یک موضوع را ارسال کرد در <span class="ipsBadge ipsBadge_pill" style="background-color: #e62f3d; color: #ffffff;" >برنامه نویسی در C و ++C</span>
همانطور که میدانید در زبانهای برنامهنویسی از نوع کامپایلری، گزینهها و تنظیماتی وجود دارند که به شما امکان این را میدهد تا رفتار کامپایلر (همگردان) را تا حدی سفارشی سازی کنید. این امکان به کمک تنظیمات پرچمها (فلگها) و برخی از گزینهها قابل انجام است و انتخاب پرچمهای مناسب برای کامپایلر میتواند مورد توجه قرار بگیرد. با توجه به دو مقالهای که با عناوین زیر ارائه شده است، در این مقاله به جزئیات بیشتری نسبت به تنظیمات کامپایلر (همگردان یا مترجم) میپردازیم که البته توصیه میکنم در صورت عدم آشنایی با تعاریف مربوطه و به خصوص روند ترجمهٔ کدها و ساختار برنامههای نوشته شده توسط سیپلاسپلاس، بهتر است آنها را بررسی کنید. در مثال زیر، نسخهٔ کامپایلر همراه با اطلاعات مربوط به آن، توسط گزینهٔ option در خط فرمان قابل دریافت است: gcc --version خروجی مربوطه میتواند نسبت به نسخهٔ کامپایلر به صورت زیر باشد: gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. در حالت پیشفرض تنظیمات کامپایلر به صورت خودکار انجام میشود. اما در صورتی که نیاز باشد برخی از درخواستها توسط کامپایلر مورد توجه قرار بگیرد و یا برای دیگران آن را گوشزد کند، از این ویژگیها استفاده میشود. در چنین شرایطی میتواند به کامپایلر بگوید که کاربر میخواهد کد را برای اشکالزدائی بهینه کند یا اینکه کاربر نمیخواهد هیچ بهینهسازی خاصی برای آن فعال شود. این عمل معمولاً در سراسر خط فرمان قابل استفاده است و به عنوان مکانیزمی برای دستورالعمل برنامه برای انجام عملیاتی یا رفتاری به روش خاص عمل میکند. به طورکلی، گزینهٔ کامپایلر به عنوان یک عبارت بسیار حساس، برای خط فرمان است که برای تغییر عملکرد پیشفرض کامپایلر استفاده میشود. در اصل این گزینهها برای کامپایل برنامهٔ شما اجبار نیستند، اما برای کمک به کنترل نبههای مختلف برنامه بسیار مفید خواهند بود. از جمله: تولید کد بهینهسازی فایل خروجی (نوع، نام، مکان) خواص پیوند-دهنده اندازه فایل اجرائی سرعت اجرایی اینکه نیاز باشد کدی را بهینهسازی کنید، و یا مسائلی را برای دیگران گوشزد کنید کاملاً سلیقهای است و شما در روند توسعهٔ حرفهای خود میتوانید از این تکنیک استفاده کنید. سادهترین کاربرد این تکنیک میتواند وادار کردن استفادهٔ کامپایلر از یک استاندارد مشخص شده باشد که در صورت پشتیبانی از آن چه به صورت عقبگرد و چه به صورت سوئیچ به استانداردهای اخیر کاربرد خواهد داشت. برای مثال، پرچم std نسخه یا استاندارد ایزو از سیپلاسپلاس را کامپایلرهای رایجی مانند Clang و GCC مشخص میکند که به صورت زیر تعریف میشوند: -std=c++11 (ISO C++11) -std=c++14 (ISO C++14) -std=c++1z (ISO C++17) -std=c++20 (C++20 experimental) -std=gnu++ (ISO C++ with GNU extensions) معادل پرچم استاندارد در کامپایلر MSVC به صورت زیر است: /std:c++14 /std:c++17 /std:c++latest /std:c11 /std:c17 نکته، گزینهٔ /std از نسخهٔ ۲۰۱۷ به بعد از کامپایلر مایکروسافت در دسترس است. به صورت پیشفرض در این نسخه از کامپایلر این گزینه بر روی استاندارد ۱۴ تنظیم شده است. در صورت نیاز به ارتقاء آن به نسخهٔ ۱۷ طبق نمونه عمل کنید. همچنین طبق قوائد مایکروسافت استاندارد نهایی شده از آخرین ویژگیها در کامپایلر تحت /std:c++latest قابل دسترس میباشد که در این لحظه شامل استاندارد ۲۰ میشود. گزینهٔ Verbosity به عنوان اِسم یا Verbose از نوعِ صِفَت به معنای درازنویسی (بهتر است به معنای ارائهکنندهٔ اطلاعات بیشتر به آن توجه شود)، با کاراکتر W که به عنوان مخففی از Warning محسوب میشود قابل تنظیم است. بنابراین، پرچمهای زیر برای اهداف مشخصی در نظر گرفته میشوند که توضیحات هر یک را در مقابل آن آوردهایم: پرچم -Wall با فعال شدن، تعداد زیادی از پرچمهای هشدار دهندهٔ کامپایلر را به طور خاص و باهم روشن میکند که لیست آن به صورت زیر است: -Waddress -Warray-bounds=1 (only with -O2) -Warray-parameter=2 (C and Objective-C only) -Wbool-compare -Wbool-operation -Wc++11-compat -Wc++14-compat -Wcatch-value (C++ and Objective-C++ only) -Wchar-subscripts -Wcomment -Wduplicate-decl-specifier (C and Objective-C only) -Wenum-compare (in C/ObjC; this is on by default in C++) -Wenum-conversion in C/ObjC; -Wformat -Wformat-overflow -Wformat-truncation -Wint-in-bool-context -Wimplicit (C and Objective-C only) -Wimplicit-int (C and Objective-C only) -Wimplicit-function-declaration (C and Objective-C only) -Winit-self (only for C++) -Wlogical-not-parentheses -Wmain (only for C/ObjC and unless -ffreestanding) -Wmaybe-uninitialized -Wmemset-elt-size -Wmemset-transposed-args -Wmisleading-indentation (only for C/C++) -Wmissing-attributes -Wmissing-braces (only for C/ObjC) -Wmultistatement-macros -Wnarrowing (only for C++) -Wnonnull -Wnonnull-compare -Wopenmp-simd -Wparentheses -Wpessimizing-move (only for C++) -Wpointer-sign -Wrange-loop-construct (only for C++) -Wreorder -Wrestrict -Wreturn-type -Wsequence-point -Wsign-compare (only in C++) -Wsizeof-pointer-div -Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-overflow=1 -Wswitch -Wtautological-compare -Wtrigraphs -Wuninitialized -Wunknown-pragmas -Wunused-function -Wunused-label -Wunused-value -Wunused-variable -Wvla-parameter (C and Objective-C only) -Wvolatile-register-var -Wzero-length-bounds برای مثال، با فعالسازی پرچم -Werror، هرگونه هشدار را به خطای تلفیقی تبدیل میکند. این کار باعث میشود خطاهای مربوط به کدهای خطرناک را به گونهای جلوه دهید که از کامپایل آنها جلوگیری شود. کارهای مشابه این مورد، به صورت پیشفرض در زبانهای مانند Rust انجام میشود که از کدهای دارای خطا و خطرناک برای کامپایل جلوگیری میکند. به کار گیری چنین پرچمهایی در کامپایلر سی++ میتواند خطاهای شامل هشدار رو به خطاهای غیر قابل کامپایل تبدیل کند. جهت تنظیم این پرچم در پروژهٔ خود کافی است در ابزار ساخت مورد نظر آن را اعمال کنید، به عنوان مثال در سیمیک (CMake) به صورت زیر عمل کنید: SET (CMAKE_CXX_FLAGS "-Werror") و یا در QMake به شیوهٔ زیر میتوانید این ویژگی را فعال کنید: QMAKE_CXXFLAGS += -Werror برای مثال، کد زیر در صورت فعال بودن این پرچم، کامپایل نخواهد شد. int myFunction() { //no return! } auto main() -> int { return 0; } خروجی این پیام به صورت زیر خواهد بود: error: no return statement in function returning non-void [-Werror=return-type] به معنای این که هیچ بیانیهای به عنوان عبارت بازگشتی در تابع مربوطه که از نوع غیر-باطل (non-void) است، وجود ندارد. بسیاری از این گزینهها برای هدف خاصی در نظر گرفته میشوند که میتوانید جزئیات بیشتر آن را در این لینک پیدا کنید. برخی از پرچمهای رایج برای کتابخانهها گزینهٔ پرچم -lm امکان کامپایل کتابخانههای libm نوع سوم را به همراه کتابخانههای ریاضیاتی که عموماً به زبان سی هستند را میدهد. گزینهٔ پرچم -lpthread امکان کامپایل کتابخانههای مشترک از استاندارد پازیکس (Posix) را ارائه میکند. گزینهٔ پرچم -lstdc++fs امکان کامپایل و لینک شدن به کتابخانهٔ فایلسیستم را در استاندارد ۱۷ به بعد میدهد. پرچمهای بهینهسازی تحت کامپایلر با فعالسازی و اعمال پرچم-O0 هیچ گونه بهینهسازی بر روی کدها انجام نمیشود، در اصل امکان بهینهسازی کاملاً غیرفعال میشود. زمان کامپایل و همگردانی کدها سریعتر میشود و برای ابزارهای اشکالزدائی بهترین عملکرد را دارد. با فعالسازی و اعمال پرچم-O2 سطح بالاتری از بهینهسازی صورت میگیرد، ترکیبی از حالت بهینهسازی و سطح قبلی را اعمال میکند و طبیعتاً زمان بیشتری صرف کامپایل میشود و گزینهٔ بهتری برای ساخت یک محصول بهتر است. با فعالسازی و اعمال پرچم-O3 سطح بالاتری نسبت به سطح دوم از بهینهسازی صورت میگیرد، طبیعتاً زمان بیشتری صرف کامپایل میشود و گزینهٔ بهتری برای ساخت یک محصول بهتر است. از طرفی حجم باینری بیشتری را تولید کرده و زمان کامپایل طولانیتری را تحمیل میکند. با فعالسازی و اعمال پرچم-OFast سطح بالاتری نسبت به سطح سوم از بهینهسازی صورت میگیرد، طبیعتاً زمان بیشتری صرف کامپایل میشود و گزینهٔ بسیار بیشتری مانند -ffloat-store, -ffsast-math, -ffinite-math-only, -O3 را فعال میکند و برای ساخت یک محصول بهتر است. با فعالسازی و اعمال پرچم -OS امکان سطح دوم از بهینهسازی فعال میشود، با تفاوت اینکه برخی از پرچمها با هدف کاهش اندازهٔ فایل کدِ شیء (object-code) غیرفعال میشوند. با فعالسازی و اعمال پرچم-Oz سطح بالاتری نسبت به سطح -OS برای کاهش اندازهٔ فایل صورت میگیرد. این گزینه مختصِ Clang است. توضیحات و مراجع دقیق و بیشتر در رابطه با عملیات مربوط به پرچمهای بهینه سازی در کامپایلرهای مختلف به صورت زیر است: کامپایلر GCC کامپایلر Clang کامپایلر MSVC دقت کنید که نوع پرچمها نسبت به کامپایلرها متفاوت است، برای مثال پرچم -Od به معنای غیرفعالسازی تمامی بهینهسازیها و جمعآوری و کامپایل سریع کدها و در نهایت اشکالزدائی بهتر است که در Clang و MSVC پشتیبانی میشود و یا پرچمِ -OS صرفاً بر روی کامپایلر کلنگ قابل استفاده است. -
نگارش 10.2.0
60 دریافت
مجموعه کدمترجمهای گنو یا «کلکسیون کامپایلرهای گنو» (GNU Compiler Collection) که به اختصار GCC نیز خوانده میشود، مجموعهای از کامپایلرها برای زبانهای برنامهنویسی مختلف است که بوسیله پروژه گنو بوجود آمده است. جیسیسی یکی از کلیدیترین اعضای سلسلهبرنامههای گنو (به انگلیسی: Gnu ToolChain) است. جی سی سی در ابتدا فقط کامپایلری استاندارد برای سیستم گنو بود ولی امروزه در بسیاری از سیستمعاملهای مشابه یونیکس از آن استفاده میشود؛ مانند گنو/لینوکس، خانواده بیاسدی، اواس ایکس. همچنین جیسیسی برای معماریهای سختافزاری مختلف نیز پورت شده است. جیسیسی در اوایل سرنام کلمات GNU C Compiler بود. زیرا فقط توانایی کامپایل برنامههای نوشته شده به زبان C را داشت؛ که با مرور زمان قادر به ترجمه زبانهای بیشتری مانند سیپلاسپلاس، فورترن، پاسکال، جاوا، آبجکتیو سی و ایدا شد. پس از آن جی سی سی سرنام کلمات GNU Compiler Collection شد. بنیاد نرمافزارهای آزاد جیسیسی را تحت اجازهنامه آزاد گنو (جیپیال) نسخه ۳ به انضمام استثناهای منحصر به جیسیسی منتشر کردهاست.رایگان
-
سلام و درود خدمت دوستان عزیز، همانطور که میدانید مهمترین و شاید بزرگترین سوال در حوزهٔ برنامهنویسی این است که من باید کدام زبان برنامهنویسی را انتخاب کنم؟! واقعیت امر این است که این سوال همیشه از سمت علاقهمندان مطرح شده است اما هیچگاه یک پاسخ اساسی در مورد آن ارائه نشده است. البته اساتید و برنامهنویسان حرفهای به خوبی میدانند که زبانهای برنامهنویسی به عنوان ابزارهای کمک کار ما کاربرد دارند و به هیچ عنوان نمیتوان یک زبان را به عنوان اولین و آخرین انتخاب در نظر گرفت، اما شناخت در مورد آنها کمک بسیاری در انتخاب ابزارهای مناسب خواهد کرد. در این پُست من قصد دارم در رابطه با انتخاب یک زبان برنامهنویسی بر اساس نیاز و علایق صحبت کنم تا شما عزیزان بتوانید به یک نتیجهٔ مطلوب برسید. بنابراین، قبل از هر چیز این بسیار مهم است که بدانیم یک زبان برنامهنویسی چیست! و چرا باید از آن استفاده کنیم؟! اجازه دهید نگاهی به دلیل استفاده از زبان برنامهنویسی داشته باشیم، چرا از زبان برنامهنویسی استفاده میکنیم؟ به برقراری ارتباط با یکدیگر فکر کنید، انسان برای برقراری ارتباط با همنوعان نیاز به ابزاری به نام زبان دارد که عناصر اساسی آن حروف است. برای مثال حروف خ-ا-ن-ه با ترکیب شدن به خانه تبدیل شده و شما میتوانید آن را درک کنید و این کدی است که شما توسط آن با جهان بیرون خود ارتباط برقرار میکنید. ممکن است کدهای شما توسط یک زبان دیگر مانند زبان انگلیسی ساخته شود، برای مثال h-o-m-e حرفی است که که نتیجهٔ آن Home خواهد بود. در کشور ما معمولاً زبان مادری هریک از ما فارسی، ترکی (آذربایجانی)، عربی، کردی، لُری و دیگر موارد هستند که به صورت بومی آن را فرا میگیریم و با تسلط بسیاری از آن استفاده کرده و منظور همنوعان خود را درک میکنیم. در بحث کامپیوتر، استفاده از زبان انسانی تا حدی کاربرد دارد که فقط خود انسان آن را درک خواهد کرد نه ماشین! چرا که زبان بومی و اصلی کامپیوتر (ماشین) ۰ و ۱ است نه کاراکتر و حرف! ماشینها برای برقراری ارتباط و درک منظور انسان از واحد ۰ و ۱ استفاده میکنند که مجموعهای از آنها به عنوان دستورالعملهای مشخصی برای کامپیوتر قابل درک است. مغز کامپیوتر یعنی واحد پردازشگر مرکزی (CPU) به عنوان پردازندهٔ مرکزی تمامی دادههای شما را در قالب ۰ و ۱ شناسایی میکند و آنها را درک خواهد کرد. بنابراین زبان بومی ماشین بر خلاف انتظار برای انسان بسیار دشوار است و اگر به فکر این باشید که بخواهید از طریق آن با کامپیوتر ارتباط برقرار کنید شما یک دیوانهٔ تمام عیار بشمار خواهید آمد! اجازه دهید منظورم را سادهتر کنم، کامپیوتر منظور شما را از home درک نخواهد کرد! اما اگر به آن بگویید 01101000 01101111 01101101 01100101 مسلماً خواهد فهمید که منظور شما از آن یعنی home است! حالا اگر منظور شما سلام دنیا باشد باید به کامپیوتر بگویید 01101000 01100101 01101100 01101100 01101111 00100000 01110111 01101111 01110010 01101100 01100100 و همینطور برای برقراری ارتباط بیشتر باید هزاران، میلیونها و میلیاردها ۰ و ۱ را با اصول زبان ماشین در کنار هم قرار دهید تا شاید بتوانید یک دستورالعمل ساده برای انجام یک کار را به آن انتقال دهید! احمقانست نه؟! وقت و زمان برای ما انسانها بسیار با ارزش است و مسلماً به هدر دادن آن به این روش هرچند دانش بسیار بالایی از مهندسی کامپیوتر میطلبد اما حتی اگر شما یک دانشمند هم باشید بکار گیری این روش دیوانگی محض است! ما که کامپیوتر نیستیم! ما انسانیم! ساختار کامپیوتر بسیار شبیه به ساختار انسان است، همانطور که خالق انسان، خداوند یکتا او را آفرید به آن نیز هوش و قدرتِ تفکر داد تا بتواند بر اساس آن رشد کرده و در مسیر پیشرفت قدم بردارد، انسان نیز از دانستههای خود برای ساختههایش استفاده میکند. کامپیوترها به عنوان ابزارهای ساخت دست بشر دارای ساختار بسیار ساده ولی در عین حال بسیار پیچیده هستند که انسان برای برنامهریزی آن نیاز به ابزارهایی دارد (ابزارهایی برای ایجاد دستورات قابل درک برای ماشین). ابزارهای برنامهریزی برای کامپیوتر همانطور که اشاره شد، کامپیوترها هیچ درکی از کدهایی که انسان مینویسد ندارند! بنابراین ما نیاز به ابزاری داریم تا منظور خود را برای درک کامپیوتر ارائه دهیم. حال آن ابزار میتواند یک مفسر (Interpreter) باشد یا یک کامپایلر (Compiler) ! هر دوی این ابزارها وظیفهٔ دریافت زبان سطح بالا (نزدیک به زبان انسان) و تبدیل (ترجمهٔ آن) به زبان ماشین است. با تفاوت اینکه مفسرها کدهای نوشته شده را خط به خط تفسیر کرده و آنها را برای پردازنده اجرا میکند، در حالی که کامپایلر تمامی کدها را به شیء و هر شیء را به کد باینری یکجا ترجمه کرده و هرجا که نیاز بود آنها توسط پردازنده اجرا میشوند. به بیان سادهتر فرض کنید قرار است به زبان روسی صحبت کنید، شما دو روش خواهید داشت: صحبت کردن به زبان روسی به صورت مستقیم استخدام یک مترجم، صحبت با مترجم و ترج گفتههای شما توسط مترجم به طرف مقابل برخی از مزایا و معایب کامپایلر و مفسر نسبت به یکدیگر نکته ۱: مفسرها کدهای نوشته شده را به صورت خط به خط تفسیر و ترجمه میکند اما کامپایلرها آنها را یکجا ترجمه میکند که دارای یک خروجی مانند یک فایل اجرایی است. نکته ۲: برنامهٔ تولید شده تحت کامپایلر توسط سخت افزار (ماشین واقعی) اجرا میشود در صورتی که برنامهٔ تولید شده با مفسر توسط نرمافزار (ماشین مجازی) اجرا میشود. نکته ۳: کامپایلرها عملیات بهینهسازی یا همان (Optimization) را در آخرین مرحله از کامپایل (ترجمه) انجام میدهند، در صورتی که مفسرها عملیات بهینه سازی را در زمان تبدیل انجام میدهند. نکته ۴: سرعت اجرای کدهای کامپایل شده بسیار بیشتر از کدهای تفسیر شده است. برای مثال اگر حلقهای را در نظر داشته باشید که قرار است ۱۰ بار اجرا شود، آن حلقه در حالت مفسر ۱۰ بار تفسیر شده و ۱۰ بار توسط پردازنده اجرا خواهد شد! در حالی که در حال کامپایل شده حلقه یک بار ترجمه میشود و نتیجهٔ آن یک بار توسط پردازنده در زمان نیاز اجرا میشود! این بسیار مهم است و در پردازشهای بسیار بزرگ سرعت برنامههای کامپایل شده به شدت بالاتر از تفسیر شدهها است. نکته ۵: کدهای تولید شده توسط مفسر سطح بالاتری نسبت به کدهای تولید شده توسط کامپایلر دارند در واقع آنها تقریباً قابل خواندن هستند اما کدهای تولید شده توسط کامپایلر غیر قابل خواندن است. نکته ۶: امنیت برنامههای کامپایل شده و همچنین دسترسی به منابع کد آنها از امنیت بیشتری نسبت به برنامههای تحت مفسر دارند. نکته ۷: برنامههای تفسیر شده وابستگی خاصی به سیستمعامل ندارند و در هر جایی که برنامهٔ تفسیر کننده موجود باشد اجرا خواهند شد، در صورتی که برنامههای کامپایل شده برای هر نوع سیستمعامل متفاوت باید مجدداً کامپایل شود که البته برای اجرای آن نیازی به نصب بودن کامپایلر بر روی سیستمعامل نیست. نکته ۸: کامپایلر کد برنامه را به صورت کامل به کُد ماشین ترجمه میکند، بنابراین زمان اجرای آن بسیار کم تر است و انتخاب بسیار خوبی برای دوستداران سرعت است. نکته ۹: استفاده از زبانهای مفسری برای توسعهدهندگان مبتدی آسانتر از نوع کامپایلری میباشد بنابراین یادگیری و استفاده از این نوع زبانها نسبتاً سریعتر و راحتتر از نوع کامپایلری است. فرایند توسعهٔ نرمافزار در این فرایند کامپایلر برنامه را میسازد سپس همه دستورات زبان را از نظر صحت تجزیه و تحلیل میکند و اگر دستوری غلط باشد، اخطار میدهد. در صورتی که خطایی وجود نداشته باشد همهٔ کدها را به کد ماشین تبدیل میکند که در نهایت فایلهای مختلفی را به برنامه اجرایی اضافه میکند و در نهایت برنامه را اجرا میکند. در حالی که مفسر برنامه را میسازد اما، فرایند افزودن فایل اجرایی به برنامه یا تولید کدهای ماشین وجود ندارد بلکه دستورات کد منبع خط به خط در حین زمان اجرا یا به اصطلاح Run-time اجرا میکند. کدام زبان در چه حوزهای کاربرد دارد؟ با توجه به تعاریف بالا نوبت آن رسیده است تا زبان برنامهنویسی مورد نظر خود را بر اساس نیاز و قابلیتهایی که آن در اختیار توسعهدهنده قرار میدهد انتخاب کرد. حوزههای کاربردی زبانهای برنامهنویسی متناسب با کاربرد و رسالت آنها مشخص میشود، به طور کلی زبانهای برنامهنویسی را بهتر است به دو دستهٔ اصلی و فرعی جدا کنیم. در دستهٔ اصلی زبانهایی که پایه و اساس کتابخانهها، نرمافزارهای عظیم، انجینها و همچنین خود زبانهای برنامهنویسی میباشند را زبان مادر و اصلی و تمامی زبانهایی که به عنوانی جهتِ مکمل سازی و یا محصول نوع سوم برای اهداف تجاری ساخته شدهاند را فرعی میگوییم. زبانهای اصلی و مادر: C و ++C زبانهای اصلی و فرعی: Python, Java, Delphi, C#, Swift, Objective-C, Php, Rust, JavaScript زبانهای مکمل رابط کاربری: JavaScript, CSS, Xaml, Xhtml, Html, QML زبانهای مکمل بسترهای بلاکچین: C++, Rust و Solidity درنظر داشته باشید کتابخانهها و برنامههای اساسی و پایه که بخش اعظمی از آنها توسط زبانهای سی++ و سی نوشته میشوند در صورت نیاز برای زبانهای دیگر نیز قابل استفاده هستند. به عنوان مثال سیستمعاملها، نرمافزارهای عظیم، انجینهای بازیسازی، کتابخانههای پرکاربرد و مهم همهٔ آنها توسط زبانهای اصلی توسعه یافتهاند اما در صورت نیاز میتواند از کتابخانههای نوشته شده توسط زبانهای اصلی در زبانهای فرعی نیز استفاده کرد. شاید اینطور به نظر برسد که اگر با زبانهای اصلی هر کاری میتوان انجام داد، پس چرا زبانهای دیگر را مورد استفاده قرار میدهیم؟! جواب سوال این است که زبانهای اصلی و مهم نیاز به دانش بسیار از لحاظ معماری سیستمعامل، کامپایلر و دیگر شاخههای علوم کامپیوتر هستند و نحوِ کُدنویسی در آنها نسبت به زبانهای دیگر مانند جاوا، پایتون، سیشارپ و غیره دشوارتر است. بنابراین ممکن است انتخاب اول برنامهنویسان مبتدی نباشند اما کاربرد آنها جنریک (عمومی) است. اشاره به کاربرد زبانهای محبوب در حوزههای مختلف: توسعهٔ زیرساختها: C, C++, Rust, Go توسعهٔ وبسایت: C++, Java, Php, JavaScript, C#, Ruby, Python توسعهٔ نرمافزارهای موبایل: , C++, Java, C#, Objective-C, Swift, JavaScript, Kotlin توسعهٔ نرمافزارهای دسکتاپ: C/C++, Java, Delphi, VB.Net, C#, JavaScript, Objective-C توسعهٔ نرمافزارهای اِمبِد: C/C++, Python توسعهی بازیهای کامپیوتری: ++C و #C توسعهٔ هوش مصنوعی: C++, Python, R, Prolog, Java, Haskell, AIML توسعهٔ رابطکاربری: JavaScript, QML, XAML نکتهٔ قابل توجهی از کاربرد زبانهای اصلی در این است که خود آنها وابستهٔ زبان برنامهنویسی و محدود بر یک حوزه نیستند و به اصطلاح زبان مادر بشمار میآیند که و در تمامی حوزهها کاربرد دارند. کاربرد در صنایع و حوزههای مختلف بر اساس ویژگیهایی که یک زبان برنامهنویسی ارائه میدهد بسیار مهم است. برای مثال Python, R, Prolog و غیره در حوزهٔ هوش مصنوعی و بیگ دیتا بسیار سادهتر به کمک توسعه دهندگان میآید. در توسعهٔ وبسایت زبانهای برنامهنویسی Node.JS, Php, C#, Asp.Net محبوبیت بیشتری دارند. اما میتوان با توجه به این پست وبسایتهای بسیار سریع و بهینهای را توسعه داد که بی شک نیاز به دانش بسیار بالایی دارد و بهتر است در اهداف خاص از آن استفاده شود. در حوزهٔ موبایل در پلتفرم iOS دو زبان Swift و Objective-C به عنوان زبان اصلی پلتفرمهای iOS, tvOS و watchOS به شمار میآیند. در حوزهٔ اندروید (Android) زبانهای Java و Kotlin به عنوان انتخابهای اول توسعهدهندگان مطرح میشند در صورتی که بسیاری از کتابخانههای اندروید تحت C و ++C توسعه یافته و حتی میتواند با استفاده از ++C اپلیکیشن و بازیهای بسیار سریعتری را تولید کرد. در حوزههای صنایع بازیسازی زبانهایی مانند #C نیز کاربرد دارند، اما ترجیح اول و اصلی در این حوزه بکارگیری ++C است چرا که هیچ زبانی به جز آن نهایت سرعت را ارائه نخواهد داد. آمارها و محبوبیتها سالانه طبق گزارش بسیاری از مراجع نمودارها و آمارهایی در رابطه با ایندکس شدن زبانهای برنامهنویسی ارائه میشود که نمونهای از آنها TIOBE است. متاسفانه باید گفت مقایسهٔ چنین مراجع بر اساس ویژگیهایی که در بالا توضیح دادیم صورت نمیگیرد و صرفاً بر اساس محبوبیت بین کاربران گزارش داده میشوند. برتری زبان نسب به زبان دیگر بر اساس چنین آمارهایی اشتباه بوده و توسط آن نمیتوان یک زبان را به عنوان انتخاب اول در نظر گرفت. همچنین اگر دقت کنید مقایسهٔ زبانهای برنامهنویسی اسکریپتی با کامپایلری و همچنین زبانهایی مانند SQL در بین آنها وجود دارد که از لحاظ منطقی درست نیست چرا که کاربرد زبانها با یکدیگر متفاوت بوده و ملاک آماری این مراجع فقط استقبال کاربران است. تعاریف و هِدایتهای اشتباه به سمت یک زبان برنامهنویسی متاسفانه مشاهده میشود که در بسیاری از گروهها و سایتهای برنامهنویسی چندین زبان برنامهنویسی را به عنوان بهترین انتخاب معرفی میکنند و دلیل انتخاب آنها را مشاهدهٔ رتبههای آن بر اساس ایندکسهای برخی از مراجع و یا طرفداری بعضی از شرکتها و تعصبات بی هدف است! باید در نظر داشته باشید قدرت و ویژگیهای یک زبان ربطی به محبوبیت آن ندارد. اگر احساس میکنید شرکتها تقاضای متخصص زبان برنامهنویسی خاصی را دارد که تکرار میشود به آن معنی نیست که زبانهای برنامهنویسی دیگر در حال منسوخ شدن یا کنار گذاشتن هستند. ارزش زبان ملاک برتری آن است نه محبوبیتش! به عنوان مثال اگر JavaScript رتبهٔ اول از نظر محبوبیت را دارد به آن معنا نیست که Php در حال منسوخ شدن است! هر زبانی کاربرد خودش را نسبت به اهداف و ویژگیهای خود دارد. آیا زبان ماشین منسوخ شده است؟! خیر! این چه سوالیه!!؟ چنین افکار بیهوده را از ذهن خود بیرون بریزید! تمامی زبانهای کامپایلری به جز نوعهای مفسری در نهایت کدهایشان توسط کامپایلر به زبان ماشین یعنی assembly تبدیل میکنند. مثال زیر کد ++C است: int main() { } خروجی آن به زبان ماشین (Assembly) در کامپایلر GCC به صورت زیر خواهد بود: main: push rbp mov rbp, rsp mov eax, 0 pop rbp ret انتخاب چند-سکویی پیشنهاد میشود یا خیر؟ لازم بذکر است که بدانید، ابزارهای چند-سکوی بسیاری وجود دارند که به شما اجازه میدهند بدون داشتن دانش آنچنانی در رابطه با زبانهای برنامهنویسی متعددِ مخصوص سکوهای هدف محصول خود را توسعه دهید. برخی از آنها عبارتند از Xamarin و یا React Native که متاسفانه به دلیل ساختار نامطلوب تبدیل کدهای نوشته شده نتیجهٔ نهایی آنها آنچنان خوب مانند محصولات واقعی زبان بومی نیستند چرا که کدهای آن مستقم به زبان ماشین ترجمه نمیشوند. اما این بسیار مهم است که بدانید ابزارهای بومی چند-سکویی واقعی انتخاب بهتری برای این امر بشمار میآیند که معروفترین آنها Qt است که به صورت بومی بدون اُفت کیفیت محصول نهایی به شما اجازهٔ توسعه محصول در سکوهای مختلف را میدهد که مسلماً دانش بسیار بالایی از سی++ را میطلبد. در نتیجه اگر به دنبال محصول با کیفیت در حوزهٔ چند-سکویی هستید باید دانش بالایی از ++C داشته باشید. نکته: در نظر داشته باشید زبانهای کامپایلری خود به دو دسته نیز تقسیم میشوند که برخی از آنها به صورت مستقیم کدهای نوشته شده را به کد ماشین ترجمه میکنند و برخی از آنها کد نوشته شده را به یک زبان میانی تبدیل و سپس آن را توسط برنامهٔ مجازی برای ماشین برنامهریزی مینمایند. بهتر است توجه داشته آنها مزایا و معایبی نیز خواهند داشت. زبانهای کامپایلری در دو دستهی بومی (Native) و مجازی (Virtual) کامپایل از نوع بومی روشی است که کدهای نوشته شده را به صورت مستقیم به کُد ماشین ترجمه میکند. کامپایل از نوع مجازی روشی است که کدهای نوشته شده را ابتدا به کُدمیانی (کدمشترک یا همان بایت کُد - Byte Code) در جاوا و زبان میانی (CIL) در Net. تبدیل میکند که خودِ آن شبیه به کُد ماشین است. در این فرایند کد مربوطه توسط کامپایلر مخصوص یعنی JIT (کامپایلری از نوع Just-In-Time) در زمان اجرا توسط سیستمعامل، به دستورالعملهای قابل فهم برای پردازنده تفسیر و اجرا میشود (که این فرایند شبیه به فرایند عملکرد اجرایی مفسرها است). زبانهای بومی (زبانهایی که کد آنها به کد ماشین به صورت مستقیم توسط کامپایلر قبل از اجرای آنها توسط سیستمعامل، ترجمه میشوند که به اصطلاح ahead-of-time (جلوتر از زمان) یا همان AOT نام دارد) مانند: C, C++, Rust, Haskell, Clean, Swift, Go, Fortran, D زبانهای مجازی (زبانهایی که کد آنها توسط یک رابط میانی به زبان مشترک ترجمه میشود) : Java و #C مزایا و معایب زبانهای کامپایلری از نوع کلاس بومی (Native) از سرعت بسیار بالایی برخوردار هستند (دلیل آن ترجمهٔ مستقیم کدها به کد ماشین است) در مقابل بزرگترین مزیتی که زبانهای نوع کلاس مجازی (Byte Code) دارند به خاطر وجود یک برنامهٔ واسط جهت شبیهسازی کدهای ترجمه شده به کد قابل فهم برای پردازنده، اجرا شدن آنها در هر پلتفرم بدون کامپایل مجدد امکان پذیر است که البته این ویژگی خود نیازمند نصب بودن JVM بر روی پلتفرم مربوطه میباشد. در نوع بومی برای اجرا در هر پلتفرم لازم است سورس کدها را برای پلتفرم مقصد کامپایل کنید که نیازی به وجود ماشین مجازی مانند JVM یا برنامهٔ خاصی ندارد. سریعترین زبان برنامهنویسی کدام است؟ شاید پاسخ به این سوال به گونهای تعصبی به نظر برسد، اما واقعیت این است که باید حقیقت را پذیرفت! با توجه به دلایلی که به نوع زبانهای کامپایلری آورده شده است مشخص است که سریعترین نوع زبانهای برنامهنویسی باید در دستهٔ شاخهٔ کامپایلری و کلاس Native قرار گرفته باشند چرا که در این مبحث زبانها کامپایلری (مجازی) و مفسری حرفی برای گفتن ندارند. جهت تثبیت آن مستنداتی از بنچمارکها در این بخش آورده شدهاست. حقیقت این است ++C در بدترین حالت ممکن بدون بهینهسازی کدها و فلگهای خاص حداقل ۲ تا ۴ برابر سریعتر از زبانهای کامپایلری دیگر است! تلخترین حقیقت نیز این خواهد بود که ++C حداقل ۱۰۰ تا ۲۰۰ برابر سریعتر از زبانهای مفسری است! با توجه به تجربیات شخصی در صورتی که نوع کامپایلر Clang باشد سرعت کدها به چند برابر از این نیز خواهد رسید! همچنین باید در نظر بگیرید اگر کدهای شما خارج از اصول استاندارد زبان باشد ممکن است نتایج آن به تساوی و حتی پایینترین حالت ممکن برسد. سخن آخر، برای انتخاب زبان برنامهنویسی و به دست آوردن مهارت در آن و در نهایت تبدیل دانش به یک محصول نرمافزاری، بهتر است بر اساس نوع (کامپایلری یا مفسری بودن)، اهمیت سرعت، ویژگیهای آن و کاربردش در حوزههای مختلف تصمیم بگیرید نه بر اساس تعصب و علاقه. دقت کنید که زبانهای برنامهنویسی ابزارهای برنامهنویسی بوده و هرچقدر جعبه ابزار شما کامل باشد توانایی و مهارت شما در توسعهٔ حوزههای مختلف بیشتر خواهد بود. در صورتی که میخواهید در رابطه با انواع روشهای کامپایل و تفاوتهای کامپایل Native، Cross Compile و JIT آشنا شوید، پیشنها میشود مقاله زیر را مطالعه فرمایید.
-
نگارش 8.1.0
255 دریافت
کامپایلر مینیمال گنو برای ویندوز یکی از مهمترین ابزارهایی است که معمولاً برنامهنویسان جهت کامپایلر کدهای خود در محیط ویندوز استفاده میکنند. قبلاً کامپایلر MinGW32 به عنوان یک محیط توسعهی متن باز نرمافزار برای ساخت اپلیکیشنهای ویندوز مورد استفاده قرار میگرفت. توسعهی پروژهی اصلی MinGW در سال ۲۰۱۳ متوقف شد، اما یک جایگزین خوب با نام MinGW-w64 توسط یک توسعهدهندهی متفاوت برای ایجاد رابطهای جدید و پشتیبانی از معماری ۶۴ بیتی ارائه گردید. معمولاً دوستداران GCC (گنو) به دنبال این هستند که در محیط ویندوز کدهای خود را تحت آن کامپایل کنند. جدیداً آخرین نسخههای این کامپایلر ۸ و ۹ میباشند که در صورت نیاز برای پشتیبانی از استانداردهای ۱۷ و ۲۰ سیپلاسپلاس با نصب نسخهی ۸.۱.۰ این کامپایلر میتوانید از آن بهرهمند شوید. نکته: توجه داشته باشید که برای استفاده از این کامپایلر در ویندوز دو گزینه متفاوت موجود است، Posix و Win32. در صورتی که بخوهاید از ویژگیهای چند-نخی C++11/C11 استفاده کنید گزینهی Posix مناسب است. در غیر این صورت بدون پشتیبانی از این ویژگی نسخهی win32 با استفاده از Apiهای خود ویندوز قابل استفاده میباشد.رایگان
-
نگارش 11.0.1
32 دریافت
کامپایلر کلَنگ (Clang) یک مترجم روبه جلو برای زبانهای برنامه نویسی C و ++C و Objective-C و ++Objective-C میباشد که از LLVM بعنوان زیر ساخت روبه عقب استفاده میکند. آرمان کلنگ این است که جایگزین کامپایلر جیسیسی شود. کلنگ بصورت کاملاً متن باز توسعه میابد و توسط کمپانیهای بزرگی مانند گوگل و اپل پشتیبانی میشود.رایگان
-
با سلام، یا توجه به مقالهٔ ذکر شده زیر در ارتباط با انتخاب زبان برنامهنویسی و تفاوت عمدهٔ زبانهای کامپایلری و مفسری لازم است تعاریفی در رابطه با جزئیات زبانهای کامپایلری که خود تفاوتهایی را شامل میشوند بپردازیم. در صورتی که مقالهٔ زیر را مطالعه نکردهاید پیشنهاد میکنیم قبل از خواندن این مقاله آن را مرور کنید. در این مقاله شما تفاوت عمدهٔ آنها را خواهید آموخت که شامل توضیحات کامپایلر و روشهای کامپایل میباشد. کامپایلر چیست؟ کامپایلر به ابزار (برنامه یا مجموعهای از برنامهها) گفته میشود، که متنِ نوشته شدهٔ برنامهنویسان (در قالب کُد) را که از سطح بالاتر (زبان مبدأ) برخوردار است و درک آن برای انسان مُیسر میباشد، دریافت کرده و آن را به زبان سطح پایینتر (زبان مقصد) مانند اسمبلی یا کُد ماشین ترجمه میکند. زبانهای کامپایلری در دو دستهی بومی (Native) و مجازی (Virtual) کامپایل از نوع بومی روشی است که کدهای نوشته شده را به صورت مستقیم به کُد ماشین ترجمه میکند. کامپایل از نوع مجازی روشی است که کدهای نوشته شده را ابتدا به کُدمیانی (کدمشترک یا همان بایت کُد - Byte Code) در جاوا و زبان میانی (CIL) در Net. تبدیل میکند که خودِ آن شبیه به کُد ماشین است. در این فرایند کد مربوطه توسط کامپایلر مخصوص یعنی JIT (کامپایلری از نوع Just-In-Time) در زمان اجرا توسط سیستمعامل، به دستورالعملهای قابل فهم برای پردازنده تفسیر و اجرا میشود (که این فرایند شبیه به فرایند عملکرد اجرایی مفسرها است). زبانهای بومی (زبانهایی که کد آنها به کد ماشین به صورت مستقیم توسط کامپایلر قبل از اجرای آنها توسط سیستمعامل، ترجمه میشوند که به اصطلاح ahead-of-time (جلوتر از زمان) یا همان AOT نام دارد) مانند: C, C++, Rust, Haskell, Clean, Swift, Go, Fortran, D زبانهای مجازی (زبانهایی که کد آنها توسط یک رابط میانی به زبان مشترک ترجمه میشود) : Java و خانوادهٔ داتنت مانند C#, Visual Basic.Net و C++/CLR نکته قابل توجه در مورد C++/CLR آن است که این نوع استاندارد در مورد سیپلاسپلاس بر پایهٔ چهارچوب داتنت است. در این نسخه از زبان شما با محدودیتهای بسیاری مواجه بوده و به ویژگیها و کیفیت نهایی برنامههای تولید شدهٔ واقعی در قالب Native محروم خواهید بود. روش کامپایل و و انواع آنها کامپایلرها به صورت بومی (Native) و کراس (Cross) تقسیم بندی میشوند. به طور کلی آن دسته از کامپایلرها که کدهای باینری را تولید میکنند از نوع محلی یا همان Native نام دارند؛ در واقع به هر کامپایلی که بر روی سیستمهای معماری x86 نوع x86، بر روی سیستمهای x86-64 نوع x86-64 و بر روی سیستمهای PowerPC نوع powerpc و بر روی arm نوع arm را تولید کند کامپایل بومی میگویند. چرا که تنها برای یک پلتفرمِ هدف کدهای ماشین رو تولید خواهد کرد (در صورت نیاز برای اجرا بر روی پلتفرمهای دیگر باید آن را بر روی پلتفرم متناسب با آن پیکربندی کنید) در واقع یک وابستگی به سختافزار وجود خواهد داشت که کدهای شما بر اساس آن تولید میشود. اما در رابطه با کامپایلرها از نوع Cross یا به اصطلاح عبوری وابستگی خاصی به سختافزار ندارند، در این روش کافی است سختافزار، پلتفرم (معماری و سیستمعامل) مورد نظر را یک بار برای آن معرفی کرده و اقدام به کامپایل کنید. کامپایل به صورت کراس کدها را به برنامهٔ قابل اجرا برای بیشتر از یک پلتفرم فراهم میکند. برای مثال در صورتی که بر روی پلتفرم ویندوز هستید میتوانید برنامهٔ نوشته شدهٔ خود را برای پلتفرم اندروید یا آیاواس که برای arm هستند ارائه دهید. اولین کامپایلری که این ویژگی را پشتیبانی میکند GCC است. این امکان وجود دارد که شما کدهای نوشته شدهٔ خود را بر روی پلتفرم میزبان برای پلتفرمهای هدف (مقصد) کامپایل کنید. البته جدیداً کامپالر کلَنگ (Clang) به عنوان یکی از بهترین انتخاب بین برنامهنویسان ++C جهت کراسکامپایل مطرح میشود. کامپایلرهای پیشنهادی: GCC Clang MSVC مزایا و معایب زبانهای کامپایلری از نوع کلاس بومی (Native) از سرعت بسیار بالایی برخوردار هستند (دلیل آن ترجمهٔ مستقیم کدها به کد ماشین است) در مقابل بزرگترین مزیتی که زبانهای نوع کلاس مجازی (Byte Code) دارند به خاطر وجود یک برنامهٔ واسط جهت شبیهسازی کدهای ترجمه شده به کد قابل فهم برای پردازنده، اجرا شدن آنها در هر پلتفرم بدون کامپایل مجدد امکان پذیر است که البته این ویژگی خود نیازمند نصب بودن JVM بر روی پلتفرم مربوطه میباشد. در نوع بومی برای اجرا در هر پلتفرم لازم است سورس کدها را برای پلتفرم مقصد کامپایل کنید که نیازی به وجود ماشین مجازی مانند JVM یا برنامهٔ خاصی ندارد. کدهای میانی تحت کامپایلِ درجا JIT : Just In Time همانطور اشاره شد زبانهای برنامهنویسی Java و خانوادهٔ Net. به ترتیب توسط Java Byte Code بر روی ماشین مجازی جاوا JVM و CIL : Common Intermediate Language بر روی زیر ساخت CLI : Common Language Infrastructure از هم جدا میشوند. در نظر داشته باشید CIL نام تغییر یافتهٔ MSIL میباشد. معنای ماشین مجازی CLR و JVM جیویام یا همان JVM : Java virtual machine نوعی ماشین مجازی (واسطی) است که وظیفه اجرای کد جاوا را برعهده دارد. زمانی که در مورد برنامههای نوشته شده توسط جاوا صحبت میکنیم، حتما باید JVM بر روی سیستم شما نصب باشد تا قابلیت اجرا شدن برنامههای تحت جاوا را داشته باشد. سیاِلآر یا همان CLR : Common Language Runtime نوعی ماشین مجازی (واسطی) است که کدهای مربوط به CIL را برای سیستم تفسیر و اجرا میکند. البته تفاوتهایی در خروجی این کد با کدهای جاوا وجود دارد که در آن زبان IL به عنوان یک زبان شبیه به زبان ماشین مانند اسمبلی (assembly) میباشد. در CLR کدهای تولید شدهٔ بایتکد، کمتر از دستورالعملها و ابردادههای JVM است. تفاوت اصلی CLR و JVM تفاوت اصلی JVM و CLR در این است که JVM جهت اجرای کدهای جاوا استفاده میشود و CLR مدیریت برنامههای اجرایی داتنت را مدیریت میکند. به طور کلی، JVM امکان اجرای کدهای کامپایل شدهی جاوا را فراهم میکند که در بسیاری از سیستمعاملها و سختافزارها موجود است. از سوی دیگر، CLR یک بستر (محیطی) را برای اجرای برنامههای نوشته شده در چهارچوب داتنت همراه با امکان مدیریت حافظه، مدیریت خطاها، امنیت و غیره را فراهم میکند. نسل جدید JIT برای داتنت (نام کد RyuJIT) به لُطف Net. و نسخهٔ Net Core. نام RyuJIT کُد شناسه از کامپایلر Net. است که وظیفهٔ آن ترجمهٔ کدهای #C به بایتکُد IL است که RyuJIT کدهای بایتکُد از نوع IL را به کُد ماشین ترجمه میکند. همانطور که مشخص است، جهان به سمت محاسبات ۶۴ بیتی حرکت میکند، اما باید در نظر داشته باشید سرعت برنامههای ۶۴ بیتی همیشه بیشتر از ۳۲ بیتیها نمیباشد! برای مثال نمونهای از آن را میتوان به کامپایلر JIT برای داتنت مثال زد؛ تغییرات و بهبودهایی که در نسل بعدی کامپایلر JIT بر روی Net Core. صورت گرفته است نسخهٔ ۶۴ بیتی آن است که اجازه میدهد برنامهها دو برابر سریعتر از نسخهٔ قبلی خود در داتنِت اجرا شود. این امر باعث میشود که نظرات شما را در مورد این نسخه از کامپایلر داتنت تغییر دهد. همانطور که به نظر میرسد، معماری ۳۲ بیتی x86 کامپیوترها که از زمانهای ایجاد تا به کنون در نوع خود بسیار عالی بودهاند، اما مشکل بزرگی که دارند متاسفانه پشتیبانی تا حداکثر ۴ گیگابایت حافظهٔ اصلی (Ram) است. با توجه به رُشد روز افزون معماری ۶۴ بیتی x64 نیاز به حافظههای بیش از ۴ گیگابایت جدی شد و امروزه ما میبینیم که اکثر سختافزارها و حتی دستگاههای موبایل نیز مجهز به حافظههای بیش از ۴ گیگابایت هستند. برای بهرهمندی از قابلیتهای معماری جدید Net Core. کامپایلر خود را با بهینهسازیهای چشمگیری ارائه داده است که میتواند تا دو برابر سریعتر از نسل قبلی خود عمل کند. در نظر داشته باشید که، معماری RyuJIT تقریبا نه سال پیش طراحی شده است و کارهای اجرایی از هفت سال پیش آغاز شده است. RyuJIT به عنوان یک کامپایلر تکامل یافته از JIT32 موجود (که از x86 و ARM32 پشتیبانی میکند) اجرا شد و به تدریج جایگزین بسیاری از بخشهای "بَکاِند" آن کامپایلر با یک تخصیص دهندهٔ رجیستر جدید و تولید کنندهٔ کد همراه با برخی از ویژگیهای جدید و بهبود یافته در "فرانتاِند" برای بهینه سازی در اجرا معرفی شده است. در طول این انتقال به کدهای نسل جدید معماری، سعی بر این بوده است که کدهای نسل قبل را در کنار نسل جدید نگه داشته شود. انجام این کارها مزایایی داشته است مانند حفظ هزینهها و باز نویسیهای بسیار! اما مسلماً هزینههایی هم دربر داشته است که کمترین آنها سردرگم بودن توسعهدهندگان در بارهٔ آیندهٔ Jit بوده است. در حال حاضر عملکرد RyuJIT برای کدهای قدیمی بسیار خوب بوده است و سرانجام وقت آن رسیده است که کدهای نسل قبل در JIT در آیندهای نزدیک تمرکز شود. نسل جدید از JIT با تمرکز بر پشتیبانی از معماری ۶۴ بیتی با نام RyuJIT سریعتر از JIT64 است. زبانهایی که از JIT/CLR پشتیبانی میکنند زبانهای اصلی این کامپایلر C#, VB.Net و C++ Managed یا همان C++/CLR میباشند. نکته: سی++ در این نسخه تغییراتی از جانب مایکروسافت داشته است و از نسخهٔ استاندارد آن کمی متفاوت است. برای مثال مدیریت حافظه به صورت خودکار و همچنین تغییرات جزئی از قبیل سینتکس را دارا میباشد. ساختار برنامههای زبان کامپایلری از نوع بومی (Native) در زبانهای مادر C و ++C در صورتی که تمایل دارید در رابطه با جزئیات ساختار برنامههای سریعترین زبانهای برنامهنویسی یعنی C و ++C مطلع شوید توصیه میشود مقالهٔ مرتبط با آن را که در زیر آمده است مطلعه کنید.
-
- مترجم
- machine code
-
(و 14 مورد دیگر)
برچسب زده شده با :
-
سلام، آیا ممکن هست در مورد منطق، ساختار و اساس کاریِ کامپایلر و همچنین تعامل آن با سیستم عامل (پلتفرمهای) مختلف توضیحاتی ارائه دهید؟ با سپاس.
-
شرکت Ceemple کامپایلر Zapcc خود را تحت مجوز منبع باز منتشر کرد
کامبیز اسدزاده نوشته وبلاگ را ارسال کرد در برنامه نویسی
دربارهی کامپایلر Zapcc کامپایلر Zapcc یک کامپایلر بر پایه Clang است که با هدف کامپایلهای سریعتر طراحی شده است. این کامپایلر با استفاده از حافظه نهان (Cache) و استفاده از معماری سرویسگیرنده-سرویسدهنده پیاده سازی شده است که یک کامپایلر مدرن و جدیدی به شما میآید که برای اهداف زیر ساخته شده است: ساخت سریع: تسریع در جمع آوریهای قابل توجه برای هدرهایی که دارای قالبهای سنگین در سی پلاس پلاس میباشند مانند LLVM، WebKit، ScyllaDB بر پایه Clang/LLVM: این کامپایلر بر پایخ Clang و اغلب بر ساس آخرین SVN به روز رسانی شده است. پشتیبانی کامل از لینوکس: در حال حاضر این کامپایلر از لینوکس x64 و ویندوز x64 با MinGW-w64 به صورت آزمایشی پشتیبانی میکند. جایگزینی: جایگزینی برای Clang و GCC و پشتیبانی از تمامی سیستمهای ساخت (Build Systems) . مجوزها این پروژه منبع باز تحت مجوز LLVM از (University of Illinois/NCSA) میباشد. ساخت (Building) پیش نیازها و فرآیند ساخت همانند LLVM میباشد. git clone https://github.com/yrnkrn/zapcc.git llvm mkdir build cd build cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_WARNINGS=OFF ../llvm ninja اجرا و آزمایش ninja check-all استفاده نحو دستورات Zapcc همانند دستورات Clang میباشد. از بین بردن سرور Zapcc pkill zapcc این دستور جهت از بین بردن سرور Zapcc برای آزاد سازی حافظه یا جایگزینی با سیستم تازه ساخته شده Zappc استفاده شود. جهت اطلاعات بیشتر به این بخش مراجعه کنید. لینک منبع بر روی گیتهاب -
فرق بین کامپایل استاتیک و داینامیک قبل از اینکه فرق بین ایستا (استاتیک) - Static و پویا (داینامیک) - Dynamic را بدانیم لازم است در رابطه با چرخهٔ زندگی نوشتن یک برنامه و اجرای آن آشنا شویم. هر برنامه برای اولین بار توسط یک محیط توسعه (Editor) یا IDE توسط برنامهنویسان انتخاب و به صورت فایل متنی قابل ویرایش میباشد. سپس فایل متنی که شامل کدهای نوشته شده توسط برنامهنویس تحت زبان برنامهنویسی مانند C، C++ و غیره... میباشد توسط کامپایلر به کد شیء ای تبدیل میشود که ماشین بتواند آن را درک کرده و اجرا کند. برنامه ای که ما مینویسیم ممکن است به عنوان یک مورد توسط دیگر برنامه ها یا کتابخانههایی از برنامه ها مورد استفاده قرار بگیرد برقراری ارتباط (پیوندکردن - لینکر) یا همان لینک کردن پروسهای است که برای اجرای موفقیت آمیز برنامههای نوشته شده ما بکار میرود؛ برقراری ارتباط بین ایستا و پویا دو پروسهای از جمعآوری و ترکیب فایلهای شیءهای مختلفی است که به منظور ایجاد یک فایل اجرایی میباشند. در این بخش ما تصمیم بر این داریم تا تفاوت بین آن ها را با جزئیات مورد بررسی قرار دهیم. عمل پیوند یا ترکیب در زمان کامپایل انجام شود، در واقع زمانی که کد منبع به زبان ماشین ترجمه میشود، در زمان بارگذاری، زمانی که برنامه در داخله حافظه بارگذاری میشود، و حتی زمان اجرای آن توسط برنامه صورت میگیرد این عمل زمان پیوند و یا ترکیب (اتصال) است. در نهایت این فرآیند توسط برنامه ای اجرا می شود که به آن لینکر - پیوند دهنده (ترکیب کننده) میگویند. اتصال دهنده ها به عنوان ویرایستار لینک نیز معرفی میشوند. لینک شدن (پیوند شدن) به آخرین مرحله از کامپایل میگویند. در زبان علمی اصطلاح لینکر یا Linker معروف است اما در زبان فارسی بهترین گزینه مربوطه را میتوان با عنوان اتصال دهنده، پیوند دهنده، ترکیب کننده نام برد. همه آن ها نشانگر یک هدف به منظور ترکیب اشیاء با یکدیگر هستند که در مرحله کامپایل صورت میگیرد. پس از ایجاد پیوند در برنامه، برای اجرای آن برنامه باید داخل حافظه منتقل شود. در انجام این کار باید آدرس هایی برای اجرای داده ها و دستور العمل ها اختصاص یابد. به طور خلاصه روند زیر میتواند به عنوان چرخه زندگی یک برنامه خلاصه شود (نوشتن - لینک کردن - بارگذاری - اجرا) فرق بین کامپایل استاتیک و داینامیک در زیر تفاوت های عمده ارتباط بین استاتیک و داینامیک آورده شده است : استاتیک ارتباط به روش استاتیک فرآیندی است که تمامی ماژولها و کتابخانههای برنامه در فایل اجرایی نهایی کپی میشوند. این روش توسط لینکر در مرحله آخر کامپایل انجام میشود. اتصال دهنده - لینکر طبق روال ترکیبی کتابخانه ها را با کد برنامه و همراه مراجع - منابع خارجی ترکیب کرده و برای تولید یک بارگذاری مناسب در حافظه آماده سازی میکند. زمانی که برنامه بارگذاری میشود، سیستم عامل محلی را در حافظه به صورت یک فایل اجرایی که شامل کدهای اجرایی و داده ها میباشد مشخص میکند. ارتباط به شیوهٔ استاتیک توسط برنامهای با نام لینکر انجام میشود که در آخرین مرحله فرآیند کامپایل یک برنامه صورت میگیرد. لینکرها نیز به عنوان ویرایشگر پیوند نیز عنوان میشوند. فایل های استاتیک به طور قابل توجهی دارای اندازه بسیار بزرگی هستند زیرا برنامه های خارجی و کتابخانه های لینک شده همه در یکجا و در فایل نهایی اجرایی جمع آوری شدهاند. در اتصال استاتیک اگر هر یک از برنامه های خارجی تغییر کرده باشد باید آن ها دوباره کامپایل شوند و مجددا عمل اتصال صورت گیرد در غیر اینصورت هیچ تغییری در به روز رسانی های مرتبط با فایل اجرایی مشاهده نخواهد شد. برنامههای استاتیکی زمان بارگذاری ثابتی در هر بار اجرای برنامه در حافظه را در نظر میگیرند. و زمانی که برای بارگذاری طول می کشد ثابت است. برنامههایی که از کتابخانههای استاتیکی استفاده میکنند معمولاً سریعتر از برنامههایی هستند که کتابخانهی آنها به صورت پویا میباشد. در برنامه های استاتیکی، تمامی کد ها شامل یک فایل اجرایی میباشند. بنابراین، آنها هرگز در برنامه هایی که دارای مشکلاتی هستند اجرا نخواهند شد. داینامیک در ارتباط پویا نام کتابخانه های خارجی (کتابخانههای به اشتراک گذاری شده) در فایل اجرایی نهایی قرار داده شدهاند نه خود کتابخانه. در حالی که ارتباط واقعی در زمان اجرا در هر دو فایل در حافظه قرار میگیرند. اتصال پویا این اجازه را میدهند تا برنامه های متعددی به صورت یک ماژول کپی شده و قابل اجرا مورد استفاده قرار بگیرد. اتصال پویا بر خلاف اتصال استاتیک در زمان اجرا توسط سیستم عامل انجام میشود. در اتصال پویا فقط یک نسخه از کتابخانه به اشتراک گذاری شده در حافظه نگهداری میشود. این به طور قابل توجهی اندازه برنامه های اجرایی را کاهش میدهد، در نتیجه صرفحه جویی در حافظه و فضای دیسک صورت خواهد گرفت. در اتصال پویا بر خلاف اتصال استاتیک نیازی به کامپایل کامل پروژه نمیباشد در صورتی که لازم باشد تغییراتی در هر یک از فایلها صورت بگیرد تنها کافی است آن را کامپایل و در کنار برنامه قرار دهید. این یکی از بزرگترین مزیتهای کامپایل داینامیکی میباشد. در اتصال پویا زمان بارگذاری برنامه در حافظه ممکن است کاهش یابد. این در صورتی است که کتابخانه های مشترک در حافظه بارگذاری شدهاند. برنامههایی که از کتابخانه های مشترک استفاده میکنند معمولا کندتر از برنامه هایی هستند که از کتابخانه های استاتیکی استفاده میکنند. برنامههای پویا وابسته به داشتن کتابخانههای سازگار هستند. اگر کتابخانه تغییر یابد (برای مثال، یک کامپایلر جدید منتشر شود ممکن است کتابخانه را تغییر دهد)، در این صورت ممکن است برنامه مجدداً تحت کتابخانه جدید باز نویسی و بهروز رسانی شوند. اگر کتابخانه از روی سیستم حذف شود، برنامهای که وابسته آن کتابخانه میباشد دیگر کار نخواهد کرد. در ادامه شما میتوانید در مورد مراحل کامپایل یک برنامه مراجعه کنید: