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

راه ساده‌ترش این هست که از نسخه‌های GUI دار استفاده کنید. https://github.com/topics/qt-deploy https://github.com/probonopd/linuxdeployqt من از این‌ها استفاده نمی‌کنم و ممکنه به درستی کار نکنند، سعی کنید طبق مستندات اصولش رو یاد بگیرید.

سلام، شما باید برنامه رو به صورت خام خروجی گرفته و تمامی ملزوماتش رو در کنارش قرار بدین، این کار رو اگه حرفه‌ای باشید می‌تونید به صورت دستی انجام بدین و اگر نه می‌تونید از ابزار خود کیوت استفاده کنید که لینک‌هاش رو در ادامه بر اساس نوع سیستم‌عامل ذکر کردم: https://github.com/probonopd/linuxdeployqt https://doc.qt.io/qt-5/windows-deployment.html https://doc.qt.io/qt-6/macos-deployment.html برای مثال دستور زیر در ویندوز قابل استفاده است: windeployqt --qmldir <path-to-app-qml-files> --plugindir <path> --qmlimport <directory> --release <path-to-app-binary>

بله، قطعاً.

درود، خب نوع فونت شما آیکونیک نیست. ابتدا مسیری از یک فونت آیکونیک اعمال کنید، مثل FontAwesome و سپس امتحانش کنید. برای اندروید از نسخهٔ otf استفاده کنید.

خب ببینید شما متن پیامِ خطا رو تا ارسال نکنید نمی‌شه راهنمایی کرد ? روی ویندوز هم من مشکلی ندارم ربطی به سیستم‌عامل نداره. ولی خب باید سعی کنید جزئیات رو بررسی کنید.

ایرادی نداره، موارد زیر رو مجدداً بررسی کنید: نسخهٔ Qt Creator شما حداقل ۵.۰.۳ باشد. نسخهٔ NDK و SDK شما به ترتیب ۲۱.۴ و ۲۲.۱ باشد. مطمئن باشید که پوشهٔ android_openssl در مسیر پیش‌فرضی که کیوت کریتور برای شما پیشنهاد می‌کنه ایجاد و محتوای آن موجود باشد. سپس در تنظیمات پروژه فایل مربوط به CMake کدی که در پست قبلی گفتم نسبتاً به مسیر واقعی آن وارد کنید. پروژه را بسازید و سعی کنید دوباره امتحان کنید. اگر پاسخی دریافت نشد دقیقاً خطاهایی که می‌گیرید رو ارسال کنید تا بیشتر بررسی بشه.

طبق لینکی که دادم باید پیش برید و یا در قسمت تنظیمات Qt Creator و بخش Device / Android و کلیک برای دانلود OpenSSL را انجام دهید. موارد لازم دریافت و نصب خواهند شد، سپس در بخش تنظیمات پروژه طبق مستندات پیش برید. برای مثال در QMake و CMake به صورت زیر: android: include(<path/to/android_openssl/openssl.pri) if (ANDROID) include(<path/to/android_openssl/CMakeLists.txt) endif()

سلام، خب بهتر بود نسخهٔ کیوت و پلتفرم رو هم مشخص می‌کردید. به هر حال بدون شک این خطا مربوط به عدم وجود فایل‌های SSL در کتابخانهٔ مربوط به برنامهٔ شماست. باید فایل‌های libcrypto_1_1.so و libssl_1_1.so را به آن اضافه کنید. جهت پیشنهاد این دستورالعمل را پیگیری کنید: https://github.com/KDAB/android_openssl

در مورد اتصال به Api که خب مشخصه باید از کلاس‌های شبکه استفاده کنید و به ساختار مشخصی مثل Restful وصل بشید. در مورد ساختِ خود Api‌ها و وب‌سرویس‌ها هم باز می‌تونید سمت سرور با همین کلاس‌ها وب‌سرویس رو ارائه بدین، معماری و قالب جی‌سان یا امثالش رو تولید کنید. اگر هم به دنبال روش ساده‌تری هستید که با کیوت سمت سرور باشه، از Cutelyst هم می‌تونید استفاده کنید.

بله می‌شود. مستندات بخش شبکه را مطالعه کنید.

سلام، اگر منظور شما iostream.ir هست، این تحت سیستم IPS هستش، با Php نوشته شده.

سلام، کیوت با توجه به استاندارد‌های پیشنهادی گوگل پیش میره؛ بنابراین حداقل نسخه بر اساس آخرین تغییرات تا به این تاریخ نسخهٔ ۷.۰ اندروید است.

خب دوست عزیز بار‌ها در این باره صحبت کردیم! به دنبال Qt, Cutelyst و Drogon برید متوجه می‌شید، این‌ها کلی مستند دارند و شما ۲ ساله منتظری؟ ?

سلام، موقع تایپ و سوأل کد‌ها رو داخل تگ کد قرار بدین. و اما پاسخ سوأل، روشی که به کار گرفتین درست نیست، شما دارید هربار یک فرم رو از سمت سی++ به عنوان فرم اصلی صدا می‌زنید. برای این کار باید سمت QML فایل main.qml رو مدیریت کنید و فایل‌های مربوط به هر پنجره یا جزء رو بسازید. سعی کنید پروژهٔ خودتون رو بر اساس Qt Quick بسازید و منطقش رو سمت سی‌پلاس‌پلاس پیاده‌سازی کنید.

درود، برای این کار از وب‌سرویس استفاده کنید، از رابط‌ها و معماری‌هایی مثل Restful Api.

فایل صوتیِ مربوط به مشاوره و گفتگو با موضوع (نحوهٔ ارتقاء مهارت‌های شغلی) ۵ آبان ۱۴۰۰ زمان اختصاص یافته شده : ۲ ساعت. لینک تلگرامی

فایل صوتیِ ترس و استرس در مسیر یادگیری بازار کار زمان اختصاص یافته شده : ۱۱ دقیقه و ۱۷ ثانیه. Fear&Stress-Podcast.mp3

فایل صوتیِ عدم توانایی تصمیم گیری در مسیرِ یادگیری و رسیدن به موفقیت. زمان اختصاص یافته شده : ۷ دقیقه و ۳۱ ثانیه. Podcast-04.mp3

سلام و درود، این اواخر راجع به مشورت و راهنمایی‌ها خیلی ساده به قضیه نگاه می‌شه، همه فکر کردن کشکه و فقط با دونستن JS یا QML می‌شه محصول ساخت. البته این مثال JS و QML یک مثال هست و این مسئله در همهٔ ابزار‌ها و حول محور حوزهٔ کامپیوتر و نرم‌افزار به چشم می‌خوره، هرچند روی داستان ساده هست اما حتی پشت این کار‌های ساده کلی زمان باید صرف بشه. همین گرفتن یک دادهٔ ساده از سمت سرور و تجزیه کردنش سمت JS نیاز به یک دانش خوب در مورد معماری Api‌داره، نیاز به آگاهی از استاندارد‌های Http داره، نیاز به تخصص کافی در ریز به ریز مسائل داره، نیاز به آگاهی لازم در مورد شبکه و نحوهٔ مدیریتش داره، نیاز به درک خوب راجع به کلاس‌های شبکه و نحوهٔ مدیریت بسته‌ها داره و صد‌ها جور مسئلهٔ دیگه. یا راهنمایی نکنیم یا می‌کنیم همه چیز رو ساده نشون ندیم! به خصوص برای کسایی که سال‌ها یه چیز دیگه خوندن و الآن قراره وارد این حوزه بشن. قشنگ واقعیت رو باید به نمایش گذاشت، و اگرنه به اشتراک گذاری چهارتا UI خفن که بگین با QML هم میشه کاری نداره، سه سوته می‌شه این‌ها رو طراحی کرد. اگر کسی اطلاعات کافی و پایهٔ تخصصی نداشته باشه و همینطور متکی به یک ابزار یا زبان پیش بره چه اتفاق می‌افته؟ از نظر من قطعاً بهتون از نظر تجربی آسیب میزنه، ساخت یک محصول واقعاً به این سادگی‌ها نیست که تو گروه‌های تلگرامی داریم راجع بهش صحبت می‌کنیم! قضیه خیلی پیچیده‌تر از این‌هاست. فراموش نکن در این حوزه اگه یک کار ساده رو سریع انجام میدیم یا به نتیجه می‌رسونیم دلیلش به خاطر سال‌ها زمان و تلاشه، امکان نداره کسی حتی با ۲..۳ سال تجربه یک کار رو سریع بتونه صفر تا صد انجام بده و مشکلی نداشته باشه یا نتیجهٔ اون در سطح یک استاندارد معتبر باشه. ساخت محصول اصول داره که اولین مرحلش شفاف‌سازی و نقشهٔ توسعه و ایده‌پردازی درسته، نباید مثل بعضی از مشتری‌ها باشه که پشت تلفن زنگ می‌زنن می‌گن یه سایت می‌خوایم یا یه اپلیکیشن چند می‌گیری و بعدش شروع کنن به چک و چونه زدن و شما هم کیف کنی بگی که آره دیگه مشتری دارم! شما تا زمانی که جزء به جزء محصول رو آگاه نباشید، یعنی تا زمانی که دقیق متوجه نشید نیاز چی هست و روش حلش رو متوجه نباشید منطقی نیست که واردش بشید. چون همین مرحلهٔ نیاز‌سنجی به قدری مهمه که فرآیند مسیر و نقشهٔ توسعهٔ یک محصول رو نشونتون میده و اگه درست تشخیص ندین و ابزار‌ها و راه‌کار‌ها رو درست انتخاب نکنید بی برو برگرد با مشکل مواجه می‌شید. مشکلاتش می‌تونه به این صورت باشه: - سردرگمی - عدم توانایی کالبد‌شکافی مسئله - عدم توانایی حل مسئله - عدم توانایی انتخاب یک روش یا ابزار صحیح و مناسب - عدم تعامل شما با مشتری - عدم رضایت شما از حق‌الزحمه - عدم رضایت مشتری از نتیجهٔ کار - عدم توانایی در پاسخ‌دهی به اعضا و شرکای کلیدی دیگه در محصولات تجاری و بزرگ! - و هزاران مسئلهٔ دیگه که همشون نتیجهٔ تشخیص نا درسته. - در کنارش مهمترین خاصیتی که پیدا می‌کنه این خواهد بود در اوج نادانی احساس خواهد کرد که همه چیز دان هست! به قولی همه چیز گیگ! از نظر من حداقل مواردی که (به طور خیلی خیلی خلاصه و محدود) نیاز هست تا یک متخصص بتونه پاسخ‌گوی‌ تصمیم‌گیری نقشهٔ توسعهٔ یک محصول برای مشتری در ابعاد مختلف و سطوح متفاوت از حوزه‌های موجود در قالب اصولی باشه به صورت زیر هستند: ۱- آشنا مبانی کامپیوتر که امر طبیعیه (شامل درک و فهم مسائل و نحوهٔ حلشون متناسب با پلتفرم اجرایی محصول) ۲- آشنا به ساختار نوع محصول استاندارد در یک حوزه مثل: وب، آی‌او‌اس، اندروید یا دسکتاپ‌های مختلف مثل لینوکس، مک و ویندوز، اینترنت اشیاء و دیگر موارد. ۳- آشنا به فلسفهٔ بک‌اند و فرانت‌اند یا ترکیبی از این دو به همراه ابزار‌های مناسب. ۴- آشنا به اصول طراحی UI/UX به عنوان یک نیاز و یک فاکتور مهم در ساخت محصولی که وابسته به عملکرد کاربر داره و در حوزهٔ فرانت‌اند مهم و کاربردی هست. ۵- آشنا به اصول SOLID و امثالش مهم هستند. ۶- آشنا اصول برنامه‌ریزی ساخت بانک اطلاعاتی، اینکه از چه بانک اطلاعاتی‌ای استفاده کنی و چرا؟ ۷- آشنا به ارتباطات داده‌ای، جداول و ارتباط بین فیلد‌ها، جدوال و روش‌های درست تبادل اطلاعات مابینی داده‌ها. ۸- آشنا و تسلط کافی به یک محیط توسعه و ادغام ابزار‌ها و محیط طراحی برای هدف. ۹- آشنا به معماری ساختار و رابط‌های برنامه‌نویسی (Api) ۱۰- آشنا به استاندارد‌های Http، درک و مدیریت درخواست، پاسخ‌ها و ... ۱۱- آشنا به الگو‌های طراحی برنامه‌نویسی (DP) ۱۲- آشنا به روش‌های نگه‌داری و آزمایش نرم‌افزار و کد‌ها به خصوص درک مبحث Fault tolerance. ۱۳- آشنا به روش‌های اطمینان‌سازی و ایمن‌سازی پردازش‌های داخلی نرم‌افزار برای جلوگیری یا دشوار سازی نفوز و خراب‌کاری ۱۴- آشنا به روش‌ها و معماری‌های احراز هویت و نحوهٔ ادغامش با نرم‌افزار مثل:JWT, OAuth, AWS و غیره... ۱۵- آشنا به نوع پارادایم‌های زبان برنامه‌نویسی، در قالب‌های (دستوری) Imperative و (اعلانی) Declarative مثل OOP، functional و دیگر موارد. ۱۶- آشنا به سبک معماری نرم‌افزاری (Microservice یا مثلاً Monolith) مزایا و معایبشون. ۱۷- آشنا به سبک معماری طراحی مانند MVC در طراحی بدنهٔ محصول. ۱۸- آشنا به سبک و الگو‌های طراحی ساختاری در بک‌اند مانند Builder، Abstract، Factory و غیره. ۱۹- آشنا به ساختار یک زبان (در صورتی که می‌خواین جوابگوی مسائلِ پیش آمده باشید) کالبد‌شکافی زیر‌پوستی و عمیق یک زبان مهمه. ۲۰- آشنا و درک کامپایلر‌ها و مفسر‌ها، تفاوت‌ها و شیوه‌های عملکردیشون نسبت به کد‌های بهینه شده و عادی. ۲۱- آشنا و درک مدل‌های مختلفی از سیستم‌های توزیع شده مثل IaaS، PaaS، SaaS یا FaaS. ۲۲- آشنا به ابزار‌های ساخت و فرآیند کاری اون‌ها مثل CMake، NMake، QMake و غیره. ۲۳- آشنا به روش‌های مدیریت وابستگی‌های نرم‌افزار و ابزار‌های لازم برای بسته‌بندی بهتر خروجی. ۲۴- آشنا به روش‌های کد‌نویسی قابل آزمایش (Unit Test) و استفاده از ابزار‌هایی مثل CTest, GTest, Catch2 و غیره. ۲۵- آشنا به توسعهٔ آزمون محور (Test Driven- Development) ۲۶- آشنا به گام‌ها و شرایط نسخه‌نگاری و مراحل توسعهٔ نرم‌افزار (SDP) ۲۷- آشنا به روش‌های امنیت در کد و توسعه به شیوه‌های بررسی از طریق Fuzz-Test، Sanitizer، آنالیزر‌های پویا و ایستا و غیره... ۲۸-آشنا به قوائد طراحی بر پایهٔ خدمات مبتدی بر معماری ابری برای خدمات پیامی، وب‌سرویس‌ها، پردازش و غیره. ۲۹- در سطوح وب آشنا به مکانیزم شاخص بندی، فاکتور‌های SEO و شیوه‌‌های درست بهبود صفحات وب. ۳۰- آشنا به روش‌های به کار گیری و پیاده‌سازی ثبت کننده‌ٔ وقایع در دل محصول و روش‌های بازخورد برای توسعهٔ بهتر به همراه مانیتورینگ، نظارت و تریسینگ. ۳۱- در شرایط لزوم آشنا به نحوهٔ به کار گیری و دلیل استفاده از فناوری‌هایی مثل Redis، Memcached و غیره. ۳۲- آشنا و درک صحیح از مفاهیم هم‌زمانی (Concurrency) و روش‌های به کار گیری آن نسبت به زبان برنامه‌نویسی و شرایط مناسب استفاده. ۳۳- آشنا به سبک و قوائد و ساختار زبان‌های برنامه‌نویسی و فرآیند ساخت و ترجمه. ۳۴- و تا صد‌ها گزینهٔ دیگه می‌تونم لیست کنم اینجا که اگه انتخابتون زبان‌های نزدیک به سیستم باشه این داستان در ادامهٔ این توضیحات سر به فلک می‌کشه نمونش کامپایلر‌ها خودشون شونصد جور مباحث دارند، پلتفرم‌ها ومعماری‌های پردازنده‌ای هم در این زبان‌ها مهمن و شما حتی تا عمق سیستم‌عامل و رابط‌های اون‌ها و نحوهٔ رفتارشون باید اطلاعات کافی داشته باشید که هر کدوم به نوبهٔ خودشون هزاران صفحه می‌شه راجع بهشون کتاب معرفی کرد. این لیست چیزی بود که به زبان بسیار بسیار ساده شده و خیلی خلاصه به ذهنم رسید تا بدانید همچین هم الکی نیست ای عزیزانی که فتوا‌های صد من یه غاز میدین و این مسائل رو حل شده می‌دونید! در ادامه اصل ماجرا خیلی فراتر از این‌ها هم هست که بخوای حساب کتاب کنی می‌بینی باید هفت خان رستم رو فتح کنی تا در تمامی سطوح پاسخگو باشی، این امر شدنی هست اما زمانی که شما محدود به یک موضوع باشید قطعاً درک همهٔ مسائل محدود و ناتوان در اجرای آن خواهید شد. * وقتی می‌گم آشنا قطعاً در حد حروف الفبا کافی نیست، باید در حد نیاز تسلط و درک کافی ازشون وجود داشته باشه. * همهٔ این‌ها رو باید در کمترین زمان ممکن نسبت به یک مشتری، محصول و نیاز تشخیص بدین و انتخاب کنید، به این کار می‌گن ارزیابی محصول بر اساس دانسته‌های فنی که تماماً متکی بر دانش و تجربهٔ شماست. (کارشناسی پروژه دقیقاً همین موضوع است). * برای بهتر شدن و حرفه‌ای تر شدن هم باید فراتر از این‌ها پیش برید و در قالب «مثلث دانش» بهبودش بدهید. * محصولات معتبر جهانی حاصلِ چنین نقشه‌های پیش‌بردی هستند و اصول تخصصی و مهندسی رو رعایت می‌کنن تا به یک درجهٔ کیفی موفق و زبان زد می‌رسند. شاید این مسائل از نظر یک برنامه‌نویس ساده و نه چندان با تجربه مهم نباشه، اما در سطح کیفی یک محصول نرم‌افزاری همهٔ این مسائل مهم تلقی می‌شوند. برای همین می‌گم گولِ توصیه‌های ساده و ظاهر چهارتا برنامه یا کیوت، دات‌نت و امثال این ابزار‌ها رو نخورید، پشت همهٔ نیاز‌های یک محصول به فاکتور‌های بسیاری باید توجه کنید. فردا بخواهید بدون آگاهی در این مسائل وارد پروژه‌هایی بشید که به ظاهر ساده هستند یا باید دست به گریبان دیگران باشید و توی گروه‌ها مدام سوأل پرسی کنید و یا باید بیخیال آن شوید؛ چون به هیچ یک از این فاکتور‌های مورد نیاز توسعه توجه نکردین! پس این اصول رو به عنوان سر نخ مطالعه کنید تا بخش بزرگی از سرگردانی‌های شما حل شود. این مواردی که این جا اشاره کردم، همونطور که گفتم بخش بسیار کوچکی از دنیای نیازمندی‌های ساخت و ساز و طراحی یک محصول واقعی در پیرامون نرم‌افزار و کامپیوتر هست، اما یک دل‌گرمی بدم به کسایی که با خودشون فکر می‌کنند چنین مسیر یا نقشه‌ای از راه که قراره پیش بگیرند سخته و همهٔ ماجرا این نیست (جزئیات رو در کتاب‌ها، موقعیت و فرصت‌های شغلی، شکست‌ها، موفقیت‌ها و آزمون و خطاها یاد خواهند گرفت) و نتیجهٔ اون می‌تونه مطابق همین حکایت زیر باشه:

یک سوأل بسیار مهم و پر مخاطب در بارهٔ زبان‌برنامه‌نویسی سی‌پلاس‌پلاس در سال‌های اخیر این است که «آیا جایگزینی برای این زبان وجود دارد و یا قابل جایگزین است»؟ در بسیاری از پاسخ‌ها نشان از گزینه‌هایی مانند Go، Rust و D دیده می‌شود که بهتر است نسبت به نظرات متخصص‌های برنامه‌نویسی به این موضوع پرداخته شود، ابتدا باید در نظر گرفت که هر ابزاری می‌تواند جایگزینی داشته باشد اما شرایط و نحوهٔ استفادهٔ آن در رابطه با نیاز متفاوت است. اخیراً سوألات زیادی در این موضوع دیده شده است که می‌گویند، Rust یک زبان برنامه‌نویسی ایمن، سریع و سیستمیِ جایگزین برای سی‌پلاس‌پلاس است! اما آیا واقعاً اینگونه است یا صرفاً ما بر اساس احساسات و اشتیاق به به‌روز شدن به این موضوع می‌پردازیم؟ پاسخ برای این سوأل به صورت زیر در مدل‌های مختلف می‌تواند مطرح شود که نتیجه‌گیری و تصمیم از خلاصهٔ آن به عهدهٔ خودِ شماست. من بر این باورم که زبان‌های برنامه‌نویسی همه و همه در حال به‌روز رسانی و بهتر شدن نسبت به نسخه‌ها، استاندارد‌ها، و نسل‌های گذشتهٔ خودشان هستند و به هیچ عنوان هیچ زبانی تا به امروز به طور جدی منسوخ شده اعلام نشده است. برای درک این مطلب بهتر است ابتدا به واژهٔ «منسوخ شده» یا «Deprecated» بپردازیم، این واژه زمانی مورد استفاده قرار می‌گیرد که شرایط زیر بر آن حاکم باشد: گزینهٔ مورد نظر به طور رسمی از طرف سازنده، پشتیبان یا صاحب آن بد دانسته شده و رسماً کنار گذاشته شود. گزینهٔ مورد نظر به‌روز رسانی نشود و آخرین به‌روز رسانی آن نیز شامل مشکلاتی باشد که بعد از مدت‌ها نیز حل نشده باشد. گزینهٔ مورد نظر دیگر مورد استفاده قرار نگیرد و کاربردی هم در بین رقبای خود نداشته باشد. گزینهٔ مورد نظر دیگر پشتیبانی نشود و به قولی مُرده باشد. گزینهٔ مورد نظر به علاوهٔ این که شامل این موارد می‌شود، باید دارای یک جایگزین مناسب و عالی باشد. با توجه به این معیار‌ها و با در نظر گرفتن رسالت هر یک ابزار‌ها باید به آن توجه کرد که هر زبان یا ابزار برنامه‌نویسی خارج از این، در مرحلهٔ پیشرفت قرار گرفته است که آن نشان دهندهٔ زنده بودن و کاربردی بودن آن است. از طرفی، زبانی مثل سی‌پلاس‌پلاس جایگزین نمی‌شود چرا که هیچ یک از دلایل و معیار‌های بالا شامل حال آن نمی‌شود، اتفاقاً برعکس این زبان دارای ویژگی‌های معیاری زیر است: این زبان به طور رسمی توسط کمیتهٔ استاندارد‌سازی که متعلق به هیچ یک از شرکت‌های غول صنعتی و یا خصوصی نمی‌باشد پشتیبانی می‌شود. این زبان به طور مداوم در حال به‌روز رسانی است و کاربرد‌های چند-منظوره و همه جانبهٔ خود را داراست. این زبان از ویژگی‌های از ویژگی‌های بسیار خوب به همراه سریع‌ترین بازدهی‌ها را داراست. این زبان رقیب‌های بسیاری دارد، اما هیچ کدام از آن‌ها هنوز در عمل و دامنهٔ وسیعی موفق به نمایش عملکرد بهتری نبوده‌اند. این زبان همانند دیگر ابزار‌ها دارای مشکلاتی است، اما با توجه به پوشش و پشتیبانی از ویژگی BC در روند استاندارد‌سازی و به‌روز رسانی به خوبی از پس آن‌ها بر آمده است. برای مثال، زبان جاوا یکی از بهترین زبان‌های برنامه‌نویسی است و خیلی از شرکت‌ها مانند گوگل در سیستم‌های توزیع شده از آن استفاده می‌کنند. اما به معنای این نیست که به سرعت سی++ می‌رسد و در حد مقایسه با آن است. این زبان می‌تواند ده‌ها و صد‌ها برابر کند‌تر از سی++ باشد و این مربوط به طراحی، ساختار و مسائل مربوط به زبان است. از طرفی سی‌پلاس‌پلاس محبوب است زیرا که ویژگی‌های زیر را دارد و طی سال‌های بسیاری آن را ثابت کرده است: کارآیی (پرفرمنس) و سرعت فوق‌العادهٔ این زبان، البته خیلی از زبان‌ها ادعا می‌کنند که همچین ویژگی‌ای را دارند که در عمل نتیجهٔ جالبی مشاهده نمی‌شود. ذاتِ چند-سکویی و چند-منظوره بودن آن، حداقل همهٔ سیستم‌ها می‌توانند کد‌های سی++ را کامپایل و اجرا کنند. این زبان به راحتی می‌تواند با زبان‌ها و فناوری‌های دیگری ارتباط برقرار کرده و با آن‌ها تعامل داشته باشد. این زبان به عنوان یکی از کم‌مصرف‌ترین زبان‌های برنامه‌نویسی از نظر مصرف انرژی محسوب می‌شود. بسیاری از مهندسین این زبان‌ها را به صورت مقطعی و بار‌ها دیده و با آن آشنا هستند. کتابخانه‌های پیشفرض استاندارد STL و دیگر کتابخانه‌های سی‌++ بسیار قدرتمند و گسترده هستند. کتابخانه‌های نوع سوم (Third-Party) بسیار قدرتمند و به‌روز هستند. اولویت‌های سیستم‌های یونیکس و حتی ویندوز اکثراً بر روی C و ++C است و بازنویسی آن‌ها با زبان‌های دیگر هزینهٔ بسیاری را به ارمغان می‌آورد. بسیاری از وابستگی‌های ایجاد شده در سال‌های بسیار طولانی بر اساس سی و سی++ بوده و باز‌نگری و بازنویسی آن‌ها مشروط بر این که رابط‌ها باید باز‌نویسی شود بسیار سخت و کاری مشابه اختراع دوبارهٔ چرخ است. عملکرد تا حدی قابل پیش‌بینی است و می‌تواند آن را درک کرد، چیزی که در زبان‌هایی مانند جاوا، سی‌شارپ و گو نمی‌تواند پیش‌بینی کرد چرا که پیش‌بینی چرخهٔ GC دشوار است، هیچ رقیب جدی‌ای در این باره در سطح سی++ وجود ندارد که مدیریت حافظه را برای شما در قالب یک RAII ارائه کند، هرچند در مورد Objective-C و Rust می‌توان آن‌ها را به صورت جداگانه مورد بررسی قرار داد و نه عین آن. پشتیبانی از پارادایم (سبک)‌های طراحی را سی++ به خوبی پشتیبانی می‌کند، برای مثال برنامه‌نویسی عمومی در زمان کامپایل را به خوبی ارائه می‌کند. پشتیبانی از برنامه‌نویسی سیستمی و سطح پایین در این زبان یک مزیتی دیگری است که در کنار تمامی ویژگی‌های سطح بالای خود ارائه می‌کند. اما در این میان زبان‌هایی مثل Rust، Go، Swift و غیره ادعای جایگزینی را دارند اما ادعا‌های فنی به تنهایی کافی نیستند، در دسترس بودن گسترده از جامعه به اندازهٔ کافی به همراه جامعهٔ معتمد به آن مهم است. علاوه بر ویژگی‌های فنی زبان سی++، یک نقطه قوت بسیار مهم این زبان در بحث غیر فنی آن است، در واقع در پشت این زبان نه یک پیاده‌سازی محدودی وجود دارد و نه یک سازمان که در آینده در مورد آن تصمیم بگیرد و آن را کنترل کند. در حالی که تمامی زبان‌های مطرح و ادعا کننده داخل یک چهارچوبی کنترل می‌شوند که به شدت آیندهٔ آن‌ها را تیره و تار می‌کند. به طور کلی آزاد بودن یک ابزار و قدرت یک جامعه فارغ از جغرافیا، سازمان، نژاد و زبان یک قدرت بسیار خارق‌العاده‌ای را برای یک ابزار به ارمغان می‌آورد که به تنهایی بسیار اهمیت دارد. در این اواخر بسیاری از مهندسین به فکر باز‌نویسی بسیاری از موارد شدن و تحقیقات نشان می‌دهد ابزار‌هایی گرافیکی بسیار قدرتمند و سریع که اخیراً طراحی شده‌اند، مانند وُلکان که با سی++ نوشته شده‌ است زمانی می‌توانند با راست و زبان‌های دیگر امروزی باز‌نویسی شوند که یک سیستم‌عامل جدید با زبان‌های جدید ساخته شود! بنابراین صرفاً می‌توان یک نسخهٔ Wrapper یا همان (پوشنده) چرا که تقریباً همهٔ سیستم‌عامل‌های مدرن امروزی با زبان‌های سی و سی++ نوشته شده‌اند. از طرفی تولید یک سیستم‌عامل بسیار پر خطر است و سرمایه‌گذاری کلان، زمان و هزینه‌های بسیاری را می‌طلبد و تا زمانی که چنین نرم‌افزار‌هایی تحت سلطهٔ زبان‌هایی مانند سی++ قرار گرفته باشند پادشاهی سی‌پلاس‌پلاس ادامه خواهد داشت. نکتهٔ پایانی من معتقدم هر ابزار و زبان‌های برنامه‌نویسی جایگاه و شرایط استفادهٔ خودشان را شامل می‌شوند، دقیقاً مانند ابزار‌های موجود در یک جعبه‌ابزار بهتر است ابزار‌های خود را طوری بچینید که در جای لازم از مناسب‌ترین آن‌ها استفاده کنید. با این حال زبان‌ها و ابزار‌های مانند سی‌ یا سی++ طی سال‌ها ثابت کرده‌اند که معمولاً در همهٔ حوزه‌ها غالب هستند و می‌تواند هر کاری را که بخواهید با آن‌ها انجام دهید و یا با یک جایگرین مناسب آن را مدیریت کنید و این بستگی به مهارت و انتخاب شخصی شما دارد. همچنین صحبت‌های اخیر کمیتهٔ استاندارد‌سازی در رابطه با نحو ۲ از سی‌پلاس‌پلاس می‌تواند مفهوم خوبی در آیندهٔ این زبان باشد. مقالات مرتبط با این موضوع که می‌تواند به عنوان مکملی از پیش تعریف شده برای شما مفید باشد:

بله این خطا‌ها برای این هست که داده از سمت آدرس مربوطه دریافت نمی‌شه. یاشا!

بله در تنظیمات کیوت‌کریتور و کیت اندروید در پروژه. این خطا معمولاً زمانی رخ میده که یا اینترنت در زمان دریافت مخازن مشکل داشته باشه، دسترسی به خواندن و نوشتن در پوشه‌ها ممکن نباشه و یا اینکه تنظیمات در کشِ سیستم به هم خورده باشه. توی ویندوز همچین مسری یا با نام کاربری باید باشه: C:\Users\Administrator\AppData\Local واردش بشید و پوشهٔ مربوط به Android رو کلاً حذف کنید. از اول با کیوت‌کریتور طبق ویدیویی که دادم پیش برید، مطمئن باشید که اینترنت هم مشکلی نداشته باشه و از وی-پی-ان معتبری استفاده می‌کنید.

شما که گفتین مطابق آموزش پیش رفتین! این که کیوت ۶.۱ هست ? - من تأکید کردم سری ۶ فقط از نسخهٔ ۶.۲ و ۵ فقط ۵.۱۵ به بعد. به هر حال، پیام خطا واضح هست و داره می‌گه که NDK شما قابل شناسایی نیست و باید متغیر مسیر به اون تعریف بشه. به قسمت environment برید در Projects و همین مسیر رو دستی بدین. پیشنهاد، تمامی تنظیمات رو حذف و از اول اقدام کنید، روی ویندوز یا لینوکس و یا مک تنظیمات یکسان هستند.

خب وقتی تیکِ سبز‌رنگ داره یعنی مشکلی نباید داشته باشه و صرفاً build tools‌های مربوط به api‌های اخیر رو دانلود کنید و تموم. اگر خطایی هستی ارسال کنید تا بررسی کنیم.