رفتن به مطلب
مرجع رسمی سی‌پلاس‌پلاس ایران

پرچمداران

  1. کامبیز اسدزاده

    کامبیز اسدزاده

    بنیـــان گذار


    • امتیاز

      1

    • تعداد ارسال ها

      505


  2. سید معین حسینی

    سید معین حسینی

    میانجی گر‌ها


    • امتیاز

      1

    • تعداد ارسال ها

      19



مطالب محبوب

در حال نمایش مطالب دارای بیشترین امتیاز در چهارشنبه, 19 دی 1397 در همه بخش ها

  1. 1 امتیاز
    نام فایل‌های تست واحد فایل‌های تست را هم‌نام با کامپوننتی که تست می‌کند نام‌گذاری کنید. فایل‌های تست را با پسوند .spec. نام‌گذاری کنید. چرا؟ راهی ثابت را برای شناسایی تست‌ها فراهم می‌کند. چرا؟ الگوی هم‌گام با karma یا راه‌انداز‌های تست دیگر فراهم می‌کند. نام فایل‌های تست end to end فایل‌های تست e2e را به دنبال نام امکاناتی که تست می‌کند، با پسوند .e2e-spec. نام‌گذاری کنید. چرا؟ راهی ثابت برای شناسایی سریع فایل‌های تست e2e فراهم می‌کند. چرا؟ الگویی را مطابق راه‌اندازهای تست و سیستم‌های build خودکار فراهم می‌کند. نام ماژول (Module) های انگولار به نام نشانه‌ی ماژول پسوند Module را متصل کنید. به نام فایل پسوند .module.ts را بدهید. ماژول‌ها را با توجه به نام امکاناتی که ارائه می‌دهد و پوشه‌ای که در آن قرار دارد نام‌گذاری کنید. چرا؟ راهی ثابت را برای شناسایی و اشاره به ماژول‌ها فراهم می‌کند. چرا؟ نامگذاری شتری بزرگ ( Upper camel case) برای شناسایی اشیائی که می‌توانند توسط سازنده (constructor) نمونه سازی شوند عمومی است. ‌‌چرا؟‌ به راحتی ماژول را به عنوان ریشه‌ی امکاناتی که به همان شکل نامگذاری شده‌اند مشخص می‌کند. ماژول‌های روتینگ (routing) را با پسوند RoutingModule نام‌گذاری کنید. نام یک فایل حاوی ماژول روتینگ را با routing.module.ts تمام کنید. چرا؟ یک ماژول روتینگ (RoutingModule) ماژولی است که به صورت اختصاصی برای تنظیم کردن روتر (router) انگولار استفاده‌ می‌شود. یک قرارداد ثابت برای نام‌گذاری کلاس‌ها و نام فایل‌ها باعث می‌شوند این ماژول‌ها به راحتی پیدا شده و شناسایی شوند.
  2. 1 امتیاز
    با سلام، یا توجه به مقالهٔ ذکر شده زیر در ارتباط با انتخاب زبان برنامه‌نویسی و تفاوت عمدهٔ زبان‌های کامپایلری و مفسری لازم است تعاریفی در رابطه با جزئیات زبان‌های کامپایلری که خود تفاوت‌هایی را شامل می‌شوند بپردازیم. در صورتی که مقالهٔ زیر را مطالعه نکرده‌اید پیشنهاد می‌کنیم قبل از خواندن این مقاله آن را مرور کنید. در این مقاله شما تفاوت عمدهٔ آن‌ها را خواهید آموخت که شامل توضیحات کامپایلر و روش‌های کامپایل می‌باشد. کامپایلر چیست؟ کامپایلر به ابزار (برنامه یا مجموعه‌ای از برنامه‌ها) گفته می‌شود، که متنِ نوشته شدهٔ برنامه‌نویسان (در قالب کُد) را که از سطح بالاتر (زبان مبدأ) برخوردار است و درک آن برای انسان مُیسر می‌باشد، دریافت کرده و آن را به زبان سطح پایین‌تر (زبان مقصد) مانند اسمبلی یا کُد ماشین ترجمه می‌کند. زبان‌های کامپایلری در دو دسته‌‌ی بومی (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 مطلع شوید توصیه می‌شود مقالهٔ مرتبط با آن را که در زیر آمده است مطلعه کنید.
این صفحه از پرچمداران بر اساس منطقه زمانی تهران/GMT+03:30 می باشد
×
×
  • جدید...