جستجو در تالارهای گفتگو
در حال نمایش نتایج برای برچسب های 'سی'.
4 نتیجه پیدا شد
-
هر آنچه که باید در مورد تفاوت‌‌‌های ناگفتهٔ سی‌پلاس‌پلاس و راست بدانیم
کامبیز اسدزاده نوشته وبلاگ را ارسال کرد در ابزار‌ها
توضیحاتی که در این پست ارائه میکنم، به منظور این نیست که بگم چیزی بد هست یا چیزی خوب! یکی بهتر است و دیگری بدتر! اما دوست دارم بیشتر با جو تبلیغاتی غالب روی چیزی نظر ندیم و در برنامه‌نویسی هم شخصاً تمایل دارم به بالاترین سطح ممکن از آزادی عمل در یک ابزار برسم که همه چیز رو برای یک برنامه‌نویس فراهم می‌کنه. مثالی که قبلاً زده بودم همون بحث باغ‌وحش و حیاط وحش بهترین مثال ممکن هست که می‌تونستم بزنم ولی خب اهل تفکر باید باشی تا بفهمی چی گفتم. بذار یه چیز‌هایی در مورد Rust و C و ++C بهتون بگم تا دیگه نیازی برای ادامهٔ بحث‌های پیش پا افتاده نباشه (این بحث‌ها مسخرست و صرفاً وقت شما رو می‌گیره، اما آگاهی داشتن در موردش می‌تونه دیدگاه بهتری برای پیشروی بهتون بده) اما موضوعاتی که بهش اشاره میکنم رو اگه کمی عمیق‌تر بهش دقت کنی، خواهی دید که چرا چیزی مثل سی‌پلاس‌پلاس واقعاً بی‌رقیبه. قبل از هر چیز بهتره مروری از به وجود اومدن این زبان‌ها رو داشته باشیم: وقتی در دههٔ ۷۰ میلادی زبان C به وجود اومد، به عنوان یک ابزار به شدت قابل تحسین با ۱۰۰٪ آزادگی عمل معرفی شد، شما هر سیستم و هر ساختاری رو که می‌خواستی می‌تونستی باهاش بسازی! به هر حال کامپیوتر یک جهان جدیدی بود و هر چیزی در اون می‌تونست یک فرصت باشه؛ همین الآن بعد از گذشت ۵۲ سال خیلی‌ها فکر می‌کنن این زبان منسوخ شده! در حالی که طبق آخرین مستندات N3096 استاندارد C23 در ۲ آوریل ۲۰۲۳ به صورت پیش‌نمایش منتشر شده و هنوز هم در حال توسعه و پیشرفته! یادتونه گفتم هیچ ابزار و فناوری‌ای تا زمانی که در حال توسعه باشه، غلطه که بهش بگیم منسوخ شد! تقریباً ۳۹ سال پیش، وقتی سی‌پلاس‌پلاس به وجود اومد کاملاً ویژگی‌های C رو به ارث برد، در واقع هر چیزی که C داره، هم مشکلات و هم مزایا در ++C هم وجود داره اما خیلی فراتر از مباحثی که فکرش رو می‌کردند به یک باره توسعه‌پذیر شد. خیلی خب باید بپذیریم مشکلاتی که C داشته را هم در بعضی جاها ++C خواهد داشت، اما نه به صورت یک مانع! چون برای همشون راهکار وجود داره، هیچ چیز بی دلیل ساخته نمیشه، این رو مطمئن باش به‌روز رسانی‌ها بی دلیل نیستند. در مورد Rust، که ۸ سال پیش وقتی به وجود اومد که حتی به ۱۰ سال هم عمر و پختگیش نمیرسه صرفاً تمرکزش به ادامهٔ مسیر‌های مشابه زبان‌های مدیریت شده بود اما در حوزه‌ها و منظور‌های متنوع‌تر که این موضوع جذابش می‌کنه. راست یک زبان سیستمی هست اما با دارا بودن خاصیت Ownership که به همراه یک سری قوانین مثل Transfer Rules و Borrowing خیال شما رو از بحث ایمنی راحت می‌کنه. همین موضوع مسیر Rust رو با C و ++C جدا می‌کنه و قابل قیاس نیستند که در ادامه می‌گم چرا. موضوع مدیریت خودکار حافظه این بحث برتری حساب نمیشه چون توی سی++ مدرن ما راهکار‌های مشخصی برای مدیریت این مسائل داریم. خب یعنی چی یه ابزار داشته باشیم که بیاد امکان برنامه‌نویسی سیستمی رو بده اما مطمئن؟! قطعاً یه جای کار داره می‌لنگه! عین اینه که بگی من اینترنت دارم ولی فیلترینگ شدیدی روش هست، بله نمی‌ذاره من آزادانه و اونطور که می‌خوام پیش برم، هرجا ریسکی بود به عهدهٔ خودمه هرجا خیری بود باز به نفع خودمه. زور و فشار هیچ‌وقت موجب پیشرفت عمیق نمیشه حتی در فناوری! چون شما اختیار عمل ندارید و محبورید با محدودیت‌هایی که اعمال میشه پیشروی کنید. ساختار مهمی که راست داره بحث موضوع Ownership یا همون مالکیت هست، این یعنی چی؟ یعنی مالک خودش شیء‌ای هست که مسئولیت مدیریت حافظهٔ اختصاص داده شده به یک شیء رو به عهده می‌گیره. در کنار این موضوع قانون انتقال یا همون Transfer می‌گه که هر شیء‌ای فقط یک مالک داره و مالکیت اون‌ها تنها می‌تونه به یک شیء دیگر منتقل بشه! این یک قانون اصلی و مهم در راست هست که برای تضمین این موضوع قانون امانت یا همون Borrowing می‌گه که اگه می‌خوای از یک شیء به عنوان مالک نهایی استفاده کنی، می‌تونی مالکیت به شکل امانت رو به شیء دیگری انتقال بدی که در حالت قرضی یا موقتی ممکن هست اما اجازه نداری هرطور که دلت خواست ازش استفاده کنی. خب این قانون محدودیت‌های شدیدی رو ایجاد می‌کنه، اما در عوض بله تضمین می‌کنه که مدیریت حافظه مطمئن هست. این باعث میشه خطاهای حافظه به خاطر وجود مالکیت اختصاصی، که در زمان کامپایل، کامپایلر تعیین می‌کنه که چه زمانی باید حافظه آزاد بشه رو جلوگیری می‌کنه. شما نمی‌تونید به صورت آزاد روی مدیریت حافظه حرفی برای گفتن داشته باشید چون شما آزادی عمل ندارید. در مقابل در سی‌پلاس‌پلاس بدون هیچ محدودیتی از این موضوع بهره می‌برید. دسترسی به لایه‌های سخت‌افزاری عمیق و پشتیبانی از abiهای سیستم‌عامل‌ها به صورت کامل تحت راست ممکن نیست مگر اینکه به صورت اختصاصی نسبت به هر abi در اختیار شما خارج از استاندارد‌ها قرار بگیره، چیزی که در سی‌پلاس‌پلاس همه چیز به صورت استاندارد در اختیار توسعه‌دهنده قرار می‌گیره. کتابخانه‌های استاندارد Rust قابلیت کنترل مستقیم روی ترد (نخ)ها رو ارائه نمی‌کنه هرچند مدعی هستن که از روش‌های crate در کامپایلر راست در زمان اجرا با استفاده از thread_priorityها قابل پیاده‌سازی هست اما با این حال، هیچ‌وقت در سطح فوریتی به اندازهٔ APIهای استاندارد ++C قابل استفاده نیست، حتی C هم در این حد و اندازه امکان مدیریت سخت‌افزار رو برای شما نمیده. در صورتی که در Rust لایهٔ امنیتی رو فعال هست (چیزی که به صورت پیشفرض در راست فعال هست) دیگه امکان دسترسی به لایه‌های سخت‌افزاری رو از دست خواهید داد. در حالی که سی++ این امکان رو به صورت کاملاً آزاد در اختیار شما قرار میده و شما با پذیرش خطر اون اگر تسلط خوبی داشته باشید می‌تونید به بهترین شکل ممکن دسترسی نامحدود به این موضوع رو در اختیار بگیرید. شما در راست فقط حق انتخاب بر مبنای قوائد از پیش تعریف شده رو دارید، یا ایمن باش و محدود باش، یا ایمن نباش و باز هم محدود باش! این در سی++ برعکسه! شما یا باید کد ایمن بنویسی و در عین حال به بالاترین کارآیی دسترسی داشته باشی، یا باید به خاطر عدم داشتن تسلط بالا خطر‌هاش رو بپذیری که صد البته برای کاهش مسائل راهکار‌های استاندارد‌های جدید بهترین گزینست. تمام چیزی که راست ادعا کرده کلاً بر مبنای محدودیت‌های اعمال شده هست، برای مثال شما هیچ راه استاندارد و بومی شده‌ای برای دسترسی APIهای سیستمی به شیوهٔ مستقل از سکو رو ندارید مگر مواردی چون windows-rs و مشابهش که کاملاً خارج از بحث استاندارد و به نوع سوم در دسترس توسعه‌دهنده‌ها قرار می‌گیرند و مناسب چند-سکویی واقعی نیست. جامعهٔ پخته و اکو‌سیستم راست هیچ‌وقت به اندازهٔ زبان‌های C و ++C گسترده نیست و کتابخانه‌های استانداردِ بی‌شماری از این بابت در اختیار توسعه‌دهنده‌ها قرار نگرفته و این قابلیت مقایسه با عمق مستنداتی که طی چندین دهه برای زبان‌های دیگه موجود هست رو نداره. راست به معنای واقعی کلمه یک زبان ایمن هست اما با فعال بودن لایهٔ ایمنی، قدرتمند نیست و زیرساخت‌های سنگین که قدرت مانور کامل روی سخت‌افزار رو به شما بده. راست به هیچ عنوان بهینگی لازم رو به خاطر قوائد ایمنی در زمان اجرا (Run-Time) رو نداره در حالی که در ++C شما بهینگی به شدت بالایی رو برای زمان اجرا می‌تونید اعمال کنید. در راست که مدعیه یک زبان سطح‌پایین هست، ما مفهومی به عنوان Placement new نداریم، حتی معنا هم براش نداره چون دیگه محدودیت مالکیت (Onwership) با این موضوع هم خونی نداره و چنین ادعاهایی رو راحت رد می‌کنه. در سطوح پیشرفته، توسعه‌دهنده در ++C با استفاده از Placement new، می‌تونه یک شیء رو در یک مکان خاص از حافظه ایجاد کنه، بدون اینکه حافظه جدیدی بهش اختصاص بده! این امکان به شما اجازه میده که به طور دقیق مشخص کنید کجا باید یک شیء ایجاد بشه! چیزی که حتی در C هم به اندازهٔ ++C در مورد کنترل، سازگاری و انعطاف‌پذیری در مدیریت حافظه رو به ارائه نمی‌کنه. و اما در مورد بحث مسائل زمان اجرا و کامپایل، بله راست به دلیل ویژگی‌هایی که داره در زمان کامپایل مشکلات قابل بروز در زمان اجرا رو کنترل می‌کنه، در مقابل استاندارد‌های جدید از سی‌پلاس‌پلاس نیز ویژگی‌هایی مثل Contractsها و Conceptsها رو برای این منظور در نظر گرفته که اگه با استاندارد جدید آشنا نباشید طبیعتاً کد‌های شما در زمان اجرا ممکنه ایمن نباشه. خلاصهٔ کلام اینه که هر زبانی در جای خودش مزایا و معایب خودش رو داره که معمولاً برای تبلیغات و حمایت شدن توسط جامعه، طبیعیه که باید بعضی از مسائل رو نادیده بگیره و بعضی از مزایا رو بیشتر مطرح کنه. در مورد راست هم همینطور، در مورد سی‌پلاس‌پلاس هم همینطور! نا نمی‌تونیم بگیم همه چیز بده یا همه چیز خوبه! قطعاً در مقابل امنیت شک نکنید باید یک سری چیز‌ها رو در نظر بگیرید و در مورد آزادی توسعه توسط یک زبان هم همچنین. به‌روز رسانی‌های اخیر سی‌پلاس‌پلاس طوری پیش رفته که وقتی بخوای به عنوان یک زبان مدرن ازش استفاده کنی، اصولاً دیگه جای بحثی از نظر ترس و وحشت یا مشکلات حافظه یا چنین مسائلی باقی نمی‌مونه. این بر می‌گرده به توسعه‌دهنده که واقعاً از چه نسل و استانداردی تبعیت می‌کنه. -
همانطور که می‌دانید پلی‌استیشن ۵ به عنوان یک نسل جدیدی از کنسول بازی سونی معرفی شده است که رابط‌کاربری آن به شدت تغییر و بهبود یافته است. هر چیزی که در این محیط از پلی‌استیشن ۵ دیده می‌شود خط به خط و ریز به ریز آن، به لُطفِ کامپایلر Clang که اتفاقاً امروز هم نسخهٔ ۱۱ اون منتشر شد، و استاندارد ۱۷ از سی++ و به خصوص بحث نرم‌افزاری آن بر پایهٔ سیستم‌عامل FreeBSD ارائه شده است که متخصص‌ها در این باره خوب می‌دانند فری‌بی‌اِس‌دی به عنوان سریع‌ترین و پایدارترین نوع سیستم‌عامل‌های یونیکسی مطرح هستند. اگه شما کاربر عادی هستید، مثالی بزنیم تا بیشتر در جریان باشید: - سیستم‌عامل macOS و iOS بر پایهٔ سیستم‌عامل یونیکس (داروین) ساخته شده‌اند. - سیستم‌عامل اندروید بر پایهٔ لینوکس ساخته شده‌اند. از طرفی سیستم‌عامل کنسول مایکروسافت اِکس‌باکس بر پایهٔ هستهٔ ویندوز ۱۰ طراحی شده و در مقابل سیستم‌عامل پلی‌استیشن ۴ و همچنین ۵ از هستهٔ یونیکس فری‌بی‌اِس‌دی استفاده کرده که حرفهای زیادی برای گفتن دارند. در بحث طراحی نسبت به نسخه‌های پیشین یک بهبود اساسی داشته چون تغییرات رابط‌کاربری در زمان PS4 نسبت به PS3 چنان چشم‌گیر نبوده است! اما الآن دیگر سونی واقعاً بر روی آن کار کرده است و دیگر خبری از آن ظاهر تکراری و حوصله بر وجود ندارد! پلی‌استیشن ۵ رابط کاربری کاملاً بازسازی شده‌ای نسبت به پلی‌استیشن ۴ دارد که با هدف دسترسی آسان به اطلاعات طراحی شده. یکی از ویژگی‌های این رابط کاربری گرفتن آپدیت‌های زنده است که کاربران مجبور به جستجو و صبر کردن برای مشاهده فعالیت‌های دوستان خود و مشاهده فعالیت‌های در دسترس در بازی‌ها نباشند. مارک سرنی دربارهٔ این موضوع گفته‌است «ما نمی‌خواهیم یک کاربر بازی را باز کند، ببیند که چه‌خبراست، و دوباره بازی را باز کند که ببیند چه خبر است!»! این ویژگی در همان داشبورد رابط کاربری اصلی پلی‌استیشن فراهم شده است و نیازی به ورود به داخل بازی جهت بررسی خبر‌های اخیر از آن ندارد! همچنین دیگر مواردی مانند پشتیبانی از ویژگی عقب‌گرد (یعنی پشتیبانی از اجرای بازی‌های پی‌اس ۴) در این سیستم ارائه شده است. رابط کاربری پلی استیشن 5 همواره با وضوح تصویر 4K واقعی و پشتیبانی کامل از HDR به نمایش درمی‌آید. سونی تلاش زیادی کرده است که بازیکنان در کمترین زمان ممکن بتوانند برنامه یا بازی مورد نظر خود را در رابط کاربری بیابند و اجرا کنند. همه‌ی برنامه‌ها نیز حالا بخشی از UI هستند و دیگر مثلا موقع وارد شدن به پلی استیشن استور احساس نمی‌کنید که تازه یک برنامه‌ی جدید باید از ابتدا اجرا شود. از طرفی SSD بسیار سریع و پردازندهٔ مرکزی دستگاه کاری می‌کنند که رابط کاربری همواره با سرعت قابل توجه و به شکل روان مقابل بازیکن قرار بگیرد.
-
کامبیز اسدزاده یک موضوع را ارسال کرد در <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 صرفاً بر روی کامپایلر کلنگ قابل استفاده است. -
سلام من یک پروژه open source دانلود کردم، شبیه سازی یک مقاله هست باید اجرا کنم و خروجی هاش رو ببینم به زبان C نوشته شده اما با Cmake ساخته شده که تقریبا فهمیدم Cmake چیه اما نتونستم برنامه رو توی Visual Studio اجرا کنم. Cmake رو نصب و خروجی رو برای Visual studio 2017 ساختم اما وقتی اجرا میکنم پیام out of date میده، در جواب build میزنم yes اما faild میشه، No میزنم اجرا نمیشه از داخل خود Visual Studio هم که توی سرچ هام فهمیدم میشه مستقیما پوشه ای که cmakeList.txt داره رو open کرد، این کارو کردم اما اون بالا کنار فلش سبز رنگ نوشته select startup item و روی current document هست و گزینه دیگه ای نداره و قابلیت اجرا نداره تصویر فایل های این پروژه رو ضمیمه کردم نمیدونم باید چیکار کنم، ممنون میشم راهنمایی کنید.
