-
تعداد ارسال ها
505 -
تاریخ عضویت
-
روز های برد
266
نوع محتوا
نمایه ها
وبلاگها
تالارهای گفتگو
گالری
فروشگاه
تقویم
مقالات
صفحات استاتیک
کتابخانه
بخش دریافت
تمامی مطالب نوشته شده توسط کامبیز اسدزاده
-
سلام، تابع getData رو باید برای کیوامال فراخوانی کنید. قبل از تابع بهتره Q_INVOKBLE رو قرار بدی تا بتونی تحت QML بهش دسترسی داشته باشی. اگر که توابع شما همانطور که به نظر میاد پیچیده هستند از آموزش زیر الگو بگیرید.
-
شما میتونید در کیوت از توابعی مثل drawImage از کلاس QPainter در ++C استفاده کنید و نتیجهی اون رو با استفاده از تابع grabToImage در سمت QML بسازید. قبل از هر چیز ماژول پرینت رو فعال کنید، برای این کار داخل فایل .pro این کد رو اضافه کنید. QT += printsupport سپس کلاسی بسازید، مثلاً کلاس PrintAction به صورت زیر: #ifndef PRINTACTION_H #define PRINTACTION_H #include <QObject> #include <QVariant> class PrintAction : public QObject { Q_OBJECT public: PrintAction(); Q_INVOKABLE void print(const QVariant &data); }; #endif // PRINTACTION_H #include "printaction.h" #include <QPrinter> #include <QPainter> #include <QPrintDialog> PrintAction::PrintAction() { } void PrintAction::print(const QVariant &data) { QImage img = qvariant_cast<QImage>(data); QPrinter printer; QPrintDialog *dlg = new QPrintDialog(&printer,nullptr); if(dlg->exec() == QDialog::Accepted) { QPainter painter(&printer); painter.drawImage(QPoint(0,0),img); painter.end(); } } فایل main.cpp به این صورت خواهد بود: #include <QGuiApplication> #include <QQmlApplicationEngine> #include <QApplication> #include <QQmlContext> #include "printaction.h" #include <QtPlugin> int main(int argc, char *argv[]) { QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling); QApplication app(argc, argv); QQmlApplicationEngine engine; //Register C++ class for QML PrintAction print; engine.rootContext()->setContextProperty("PRINT", &print); engine.load(QUrl(QStringLiteral("qrc:/main.qml"))); if (engine.rootObjects().isEmpty()) return -1; return app.exec(); } در نهایت فایل QML شما هم باید چیزی مثل این باشه: import QtQuick 2.12 import QtQuick.Window 2.12 import QtQuick.Layouts 1.3 import QtQuick.Controls 2.4 Window { visible: true width: 640 height: 480 title: qsTr("Hello World") property date currentDate: new Date() RowLayout { id:pageHeader width: parent.width Layout.fillWidth: true Label { text: "First name: " } Text { text: qsTr("<b>Kambiz</b>") } Label { text: "Last name: " } Text { text: qsTr("<b>Asadzadeh</b>") } Item { Layout.fillWidth: true; } Label { text: "Date: " } Text { text: currentDate.toLocaleDateString(); font.bold: true } } Button { x: 437 y: 137 width: 150 height: 36 text: qsTr("Print") onClicked: { var stat = pageHeader.grabToImage(function(result) { result.saveToFile("/Users/compez/Desktop/someimage.png"); PRINT.print(result.image); }); console.log("Success: ", stat); } } } موفق باشید.
-
سلام، این چیزی نیست که انتظارش رو داشتی. برای Flow هم خاصیت anchors.verticalCenter: parent.verticalCenter رو تعریف نکن. از همون GridView استفاده کن و آیتمهای درونش رو لنگر بزن (anchors).
-
کاربران GitHub اکنون مخازن خصوصی را به صورت رایگان دریافت میکنند!
کامبیز اسدزاده نوشته وبلاگ را ارسال کرد در ابزارها
اگر شما از آن دسته از کاربرانی هستید که هزینهای برای گیتهاب پرداخت نمیکنید، این هفتهی خوبی است برای شما! با توجه به تاریخ، گیتهاب همیشه حسابهای رایگان ارائه داده است، اما با توجه به قوانین آن مخازنِ شما باید در قالب عمومی ایجاد میشدند. در صورتی که شما نیاز به داشتن مخزنی از نوع خصوصی داشتید در این صورت مجبور به پرداخت هزینهای در قبال آن بودید. خبر خوش این است که، این محدودیت از امروز از بین رفته و شما میتوانید مخازن خود را به صورت خصوصی و بدون پرداخت هزینهای ایجاد کنید. -
سلام، کتابخانههای Win32 و MFC هرچند کتابخانههای قدرتمندی هستند اما باید در نظر داشته باشید اینها اختصاصی برای پلفترم ویندوز بوده و بر اساس API های ویندوز ارائه شدن و مسلماً کاربردهای آنچنان بهروز و چند منظورهای مثل Qt رو ندارند. کتابخانهٔ پیشنهادی خود مایکروسافت در قالب چهارچوب داتنت است که برای سی++ هم UWP قابل استفاده بوده و شما میتونید رابط کاربری مدرن رو هم با WPF توسعه دهید (اما انتظار نداشته باشید در حد Qt خارقالعاده باشه). با توجه به اینکه شخصاً تعامل خوبی با داتنت و سیشارپ دارم و در مواقعی که صلاح میدونم ازش استفاده میکنم، نیاز هست تا شمارو در جریان یک واقعیت قرار بدم (که سوال بسیاری از دوستان بوده)! شما برای اینکه برنامهای رو تحت هر زبانی اجرا کنید مسلماً نیاز به یک سری کتابخانهها و پیش نیازاتی خواهید داشت! برای مثال در سیشارپ شما نیاز به داتنت دارید و در سی++ نیاز به STL، Qt، Boost و غیره! حالا کتابخانهٔ پیشفرض سی++ STL و پیشفرض سیشارپ Net. هست! حالا با توجه به اینکه شما یک برنامهٔ ساده ز نوع "سلام دنیا!" بنویسید! چیزی که در سی++ ارائه خواهد شد حدود چند کیلوبایت است که برای اجرای اون تنها نیاز به فایلهای msvcr و msvcp و یا vcruntime خواهید بود که جمعاً حدود ۱ تا ۲ مگابایت نیستند! اما برعکس در سیشارپ شما بخوای همین برنامهٔ ساده رو بنویسی خبری از این سادگی نیست! نیازمند پکیج حجیمی از داتنت خواهی بود که باید نصبش کنی. در ویندوز وقتی شما با سیشارپ برنامهنویسی میکنید به دلیل اینکه چهارچوب .Net و SDKهای مربوط به داتنت بر روی سیستمعامل مستقر شدهاند نیازی نیست تا کتابخانههای مربوط به داتنت رو در کنار برنامهٔ خودتون قرار بدین (چون اینها در خود سیستمعامل نصب میشوند نه در کنار برنامه). دقت کنید آیا بدون نصب پکیج (Microsoft .NET Framework Redistributable) میتونید برنامههای مربوطه رو اجرا کنید؟ پاسخش مسلماً خیر خواهد بود! این پکیج حداقل بعد از نصب چیزی حدود ۲۰۰ تا ۷۰۰ مگابایت و حتی بیشتر کتابخانهٔ داتنت استخراج خواهد کرد و این یعنی در کنار فایل اجرایی یک برنامهٔ ساده از نوع "سلام دنیا!" چنین حجم بزرگی از کتابخانه نیاز خواهد بود! اما شما متوجه این نمیشید چون به صورت پیشفرض موقع نصب برخی از ابزارهای اختصاصی مایکروسافت مثل ویژوال استودیو، آفیس و غیره این پکیج نصب میشود! البته خارج از لطف هم نیست در برخی از نسخههای نهایی ویندوز مثل ویندوز ۱۰ بخش هستهٔ کتابخانه همراه با هستهٔ سیستمعامل ارائه میشه و آنچنان مثل قبل نیاز نصب بخش عظیم کتابخانه نیست. اما با این حال شما حتماً به پکیج مربوطه جهت اجرای تمامی قابلیتهای برنامهٔ خودتون نیاز خواهید داشت که اصلاً قابل مقایسه با یک برنامهٔ ۱ تا ۲ مگابایتی تحت سی++ نیست. حالا با توجه به این آیا حجمی معادل ۸ تا ۲۰ مگابایت واقعاً مشکل محسوب میشود؟! شما فرض کن کتابخانهٔ کیوت رو در قالب یک SDK روی هستهٔ سیستمعامل خودت نصب کرده باشی! در این صورت همون فایل اجرایی چند کیلوبایتی نهایت حجم تولید شده از یک برنامهٔ ساده است. تعداد فایلها مربوط به همون کتابخانه هستش! آیا میدونید تعداد فایلهای داتنت بسیار بیشتر و در یک کلام چند برابر کتابخانهٔ کیوت است!؟ برای اینکه متوجه واقعیت (پنهان) شوید به این مسیر بروید: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework وحشتناکه نه؟! مایکروسافت به همین راحتی سر برنامهنویسها شیره میماله و اونها رو قانع کرده. اگر کمی زیرک و حرفهای به این مسائل باشید خواهید فهمید که در پشت این مزیت خوب چه چیزی هست! در شناخهتر بودن محیط VS شکی نیست، اما این محیط توسعه یک محیط انحصاری برای پلتفرم ویندوز است. محیط توسعهٔ Qt در هماهنگی بالا با خود کتابخانه در قالب چهارچوب مخصوصاً پشتیبانی از سیستمعاملهای دیگه بسیار بهتر عمل میکنه. در مورد شباهتش به Win32 هم به خاطر درگیری مستقیم شما با کتابخانه هست. در رابطه با اینکه رابط کاربری رو با سیشارپ بنویسید و بکاند رو با سی++ کاملاً مخالفم! چون دارین خودتون رو گول میزنید! اگه قرار هست این کارو بکنید خب با همون VS تحت داتنت و C++/CLR کدنویسی کنید که تحت داتنت خواهد بود. راهحل بهتر اینه که واقعیت رو بپذیرید و قبول کنید که هر کار خارقالعادهای نیاز به تعامل بیشتری خواهد داشت. اگر میخواهید در قالب سرعت، قدرت، دسترسی، تعامل و خارج از هرگونه محدودیت برنامهنویسی کنید سی++ رو باید با تمامی سختیهاش بپذیرید! در غیر این صورت هیچ روشی برای قانع کردن خودتون وجود نداره. درضمن پاسخ اصلی به عنوان سوال : به صورت پیشنهادی فریمورک Qt هست. کتابخانههای دیگری هم هستند مثل wxWidgets.
- 2 پاسخ
-
- سیشارپ
- رابط کاربری
-
(و 8 مورد دیگر)
برچسب زده شده با :
-
شما برای اینکه به شیء مربوط به مدل در کیواماِل دسترسی داشته باشید کافیه نام مدل رو با مشخصه model مشخص کنید. ListView { .... model: myModel } delegate: ItemDelegate { Text { text: model.title } }
-
دوست عزیز لینک روش ویندوز رو هم در پست قبلی دادم که! نمیشه که پروژه رو ما انجام بدیم شما هم باید تلاش کنی.
-
هم در ویندوز و هم در لینوکس و مک این پروژه رو تست کردم و هیچ مشکلی در حین کامپایلر نداره. از MinGW استفاده نکنید، با MSVC x64 بیلدش کنید. روالش هم این هست که cmake رو اجرا کنی، مسیر سورس پروژه رو بهش تعریف و در بخش کامپایلر MSVC 2017 x64 رو انتخاب و بسازیش. در نهایت فایل ALL_BUILD.vcxproj ساخته خواهد شد و میتونید با VS کامپایلش کنید. اینم خروجی موفقیت آمیز برای من : The C compiler identification is MSVC 19.16.27025.1 The CXX compiler identification is MSVC 19.16.27025.1 Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe -- works Detecting C compiler ABI info Detecting C compiler ABI info - done Detecting C compile features Detecting C compile features - done Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe -- works Detecting CXX compiler ABI info Detecting CXX compiler ABI info - done Detecting CXX compile features Detecting CXX compile features - done Configuring done Generating done
-
خطای out of date به تنهایی برای شناسایی مشکل کافی نیست، ظاهراً باید چیزی رو بهروزرسانی کنید. مشخصات پروژه (لینک برای بررسی) همچنین نسخهی VS و CMake رو ارسال کنید تا بتونیم بیشتر بررسی کنیم.
-
خواهش میکنم.
-
کتابخانه را که بیلد کردین قرار نیست .h را هم کنار فایلهای بیلد شده قرار بدین! شما باید پوشهی libarchive را از کتابخانهی اصلی و فایلهای بیلد شده را به صورت دستی بهش اضافه کنید.
-
خب خطایی که میگیری چی هست؟ سعی کن از حالت داینامیک استفاده کنی، حالت Release یا Debug کتابخونه رو هم با برنامهی خودت هماهنگ کن.
-
نگارش 4.7.2
0 دریافت
چارچوب داتنِت (NET Framework) یک فناوری نرمافزاری است که بر روی تمامی ویرایشهای سیستمعامل ویندوز مایکروسافت قابل اجرا است و در سیستمعاملهای دیگر از جمله لینوکس و مکینتاش نیز وارد شدهاست. این چارچوب شامل مجموعهای از زبانهای برنامهنویسی است که سیشارپ و ویژوالبیسیک مهمترین آنها میباشند. مجموعهای از کتابخانههای بسیار غنی جهت کمک به سهولت توسعه نرمافزار در این چارچوب قرار گرفتهاند که در قالب بخشهای عمدهای همچون فناورهای ASP.NET, ADO.NET و بسیاری فناوریهای خاص دیگر ارائه میشوند که تعداد آنها در نسخههای اخیر همگام با محدود تر شدن اهداف مایکروسافت بیشتر شدهاست. بخش کامپایلر این چارچوب یک مفسر همزمان (Just in Time) است. به این معنی که کد تمام زبانها به یک زبان میانی، شبیه به کد ماشین ترجمه شده و توسط یک ماشین مجازی CLR بر اساس نیازها و مشخصات هر سیستمعامل و سختافزار به اجرا در میآیند. چهارچوب داتنِت فقط برای ویندوز از نسخهی Net. برای ساخت هر نوع برنامهی قابل اجرا بر روی پلتفرم ویندوز است.رایگان
-
- .net core framework
- .net framework
-
(و 4 مورد دیگر)
برچسب زده شده با :
-
نگارش 2.2
1 دریافت
داتنِت کُر (Net Core.) یک چهارچوب رایگان و منبعباز برای پلتفرمهای ویندوز، مکاواِس و لینوکس است. این بسته شامل CoreCLR، اجرا کننده کامل CLR، ماشین مجازی است که اجرای برنامههای تحت داتنِت را مدیریت میکند. داتنِت کُر همراه با یک کامپایلر بهبود یافته از نوع JIT : Just-In-Time با نام RyuJIT ارائه شده است. همچنین این بسته شامل CoreFX، که به صورت جزئی از FCL گرفته شده است شامل میشود. علاوه بر این، داتنت جدید شامل هستهی CoreRT، نسخهی بهینهسازی شدهی زمان اجرای بومی است که با AOT هماهنگ شده است. همچنین یک نوع از هستهی این کتابخانه برای WPF مورد استفاده قرار گرفته است. رابط فرماندهی داتنت کُر یک نقطهی ورود به سیستم برای سیستمعاملها ارائه میدهد که خدماتی مانند کامپایل و مدیریت بسته را فراهم میکند. داتنت کُر یک نسخهی چند-سکویی از Net. است که برای ساخت وبسایت، سرویسها و برنامههای کنسولی میباشد.رایگان
-
- dot net core
- داتنت
-
(و 1 مورد دیگر)
برچسب زده شده با :
-
تنظیمات به این صورت هستش که خودش هم توضیح داده. کتابخانه رو باید بیلد کنید و بعد به پروژه اضافش کنید. دستورات ساخت کتابخانه به صورت زیر میباشد: mkdir -p ~/marble/build cd ~/marble/build cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_KF5=FALSE -DCMAKE_INSTALL_PREFIX=/usr/local ~/marble/sources make sudo make install در نهایت کد آزمایشی به صورت زیر خواهد بود: #include <QApplication> #include <marble/MarbleWidget.h> int main(int argc, char** argv) { QApplication app(argc, argv); // Load Marble using OpenStreetMap in Mercator projection Marble::MarbleWidget *mapWidget = new Marble::MarbleWidget; mapWidget->setProjection(Marble::Mercator); mapWidget->setMapThemeId("earth/openstreetmap/openstreetmap.dgml"); mapWidget->setWindowTitle("Hello Marble!"); mapWidget->show(); return app.exec(); } اگر هم برای پلتفرم ویندوز لازمش دارید طبق این راهنمایی کامپایلش کنید. از این آموزش هم میتونید کمک بگیرید:
-
با سلام، یا توجه به مقالهٔ ذکر شده زیر در ارتباط با انتخاب زبان برنامهنویسی و تفاوت عمدهٔ زبانهای کامپایلری و مفسری لازم است تعاریفی در رابطه با جزئیات زبانهای کامپایلری که خود تفاوتهایی را شامل میشوند بپردازیم. در صورتی که مقالهٔ زیر را مطالعه نکردهاید پیشنهاد میکنیم قبل از خواندن این مقاله آن را مرور کنید. در این مقاله شما تفاوت عمدهٔ آنها را خواهید آموخت که شامل توضیحات کامپایلر و روشهای کامپایل میباشد. کامپایلر چیست؟ کامپایلر به ابزار (برنامه یا مجموعهای از برنامهها) گفته میشود، که متنِ نوشته شدهٔ برنامهنویسان (در قالب کُد) را که از سطح بالاتر (زبان مبدأ) برخوردار است و درک آن برای انسان مُیسر میباشد، دریافت کرده و آن را به زبان سطح پایینتر (زبان مقصد) مانند اسمبلی یا کُد ماشین ترجمه میکند. زبانهای کامپایلری در دو دستهی بومی (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 مورد دیگر)
برچسب زده شده با :
-
سورس کد کتابخانه رو دریافت و توسط CMake GUI بسازیدش. برنامه command prompt رو اجرا و سورس رو با دستور mingw32-make کامپایل کنید. راهنمای ساخت این کتابخانه در Mingw و MSVC
-
فضانورد سابق ناسا: سفر انسان به سیاره مریخ احمقانه است
کامبیز اسدزاده نوشته وبلاگ را ارسال کرد در علم و دانش
پس از فرود انسان روی کره ماه در قرن بیستم، سیاره مریخ همواره به عنوان مقصد بعدی در منظومه شمسی شناخته شده؛ اما یکی از فضانوردان سابق ناساانجام چنین کاری را احمقانه می داند. بیل اندرس فضانورد سابق ناسا که در مأموریت آپولو 8 سال 1968 نیز شرکت داشته، معتقد است سفر به سیاره مریخ در حال حاضر صرفاً یک نمایش تبلیغاتی از سوی ناسا بوده و هیچ نفعی برای جامعه علمی دنیا نخواهد داشت. به گفته اندرس، بودجه لازم برای سفر به مریخ می تواند صرف پروژه های مفیدتری مانند ارسال ربات های کاوشگر به سیارات مختلف شود و از این طریق، سطح آگاهی ما از جهان اطراف را افزایش دهد. آقای اندرس معتقد است سازمان ناسا از مأموریت اصلی خود فاصله گرفته و بیشتر به دنبال برنامه های فضایی پر سر و صدا برای جذب سرمایه و بودجه بیشتر است که در نهایت، این پول ها هم خرج برنامه های تبلیغاتی و کم فایده بعدی خواهند شد. سفر انسان به مریخ در حال حاضر توجیه علمی ندارد به گفته فضانورد سابق ناسا، حضور انسان روی سیاره مریخ مسلماً یک موج رسانه ای عظیم و قدرتمند را به راه خواهد انداخت اما هیچ کمکی به گسترش مرزهای دانش بشری نخواهد کرد. جالب است بدانید که چنین دیدگاهی تنها مختص به بیل اندرس نبوده و بسیاری از مدیران ناسا، اسپیس اکس و بلو اوریجین (هر سه به دنبال فرود انسان روی مریخ هستند) نیز با نظر وی موافقند. البته نظر اندرس مخالفانی هم دارد؛ به عنوان مثال فرانک بورمن (یکی دیگر از سرنشینان آپولو ? معتقد است جست و جوی عمیق در منظومه شمسی یکی از مهم ترین مأموریت های ناسا بوده که حضور انسان بخش جدایی ناپذیر چنین پروژه هایی خواهد بود. گفتنی است آقای بورمن از سوی دیگر هیجان موجود در زمینه سفر به سیاره مریخ را هم تأیید نکرده و اظهار داشته: «ماسک و بزوس (صاحبان اسپیس اکس و بلو اوریجین) درباره تشکیل جوامع انسانی در مریخ صحبت می کنند؛ چنین چیزی مسخره است.» به هرحال باید منتظر بود و دید که آیا در سال های آتی ناسا و دیگر سازمان های فضایی بودجه خود را صرف امور علمی خواهند کرد یا بر شکستن محدودیت های حضور انسان در سایر سیارات تمرکز خواهند داشت. -
اول باید کتابخانه بیلد بشه، با دستورات زیر: tar xzf libarchive-xxx.tar.gz cd libarchive-xxx ./configure make make check make install برای افزودن این کتابخانه به Qt از بخش Add Library پروژه اقدام کن، خروجیش چیزی شبیه به این باید بشه من آخرین نسخه رو امتحان کردم: LIBS += -L$$PWD/../../../Downloads/libarchive-3.3.3/build/ -larchive INCLUDEPATH += $$PWD/../../../Downloads/libarchive-3.3.3 DEPENDPATH += $$PWD/../../../Downloads/libarchive-3.3.3 PRE_TARGETDEPS += $$PWD/../../../Downloads/libarchive-3.3.3/build/libarchive.a در نهایت یک کد آزمایشی به صورت زیر برای زیپ کردن در قلب .tar امتحان کردم که مشکلی نداره و کار میکنه. فرصت زیادی ندارم تا همه مواردش رو چک کنم، شما طبق مستندات و مثالهای پیشفرض امتحان و به کیوت اضافش بکنید. #include <QCoreApplication> #include <QString> #include <QByteArray> #include <QFileInfo> #include <QDebug> #include <QDirIterator> #include <libarchive/archive.h> #include <libarchive/archive_entry.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> int main() { QString directory = "iostreamir"; struct archive *a; struct archive_entry *entry; struct stat st; char buff[8192]; size_t bytes_read; int fd; QByteArray outArray = directory.toLocal8Bit() + ".tar"; char *outDirectory = outArray.data(); qDebug() << outDirectory; QByteArray inputArray = directory.toLocal8Bit(); char *inputDirectory = inputArray.data(); qDebug() << inputDirectory; QFileInfo inputInfo; inputInfo.setFile(directory); // the name of the directory QByteArray pathArray = inputInfo.fileName().toLocal8Bit(); char *pathDirectory = pathArray.data(); qDebug() << pathDirectory; a = archive_write_new(); archive_write_add_filter_gzip(a); archive_write_set_format_pax_restricted(a); archive_write_open_filename(a, outDirectory); QDirIterator it(directory, QDirIterator::Subdirectories); while (it.hasNext()) { entry = archive_entry_new(); stat(inputDirectory, &st); archive_entry_set_pathname(entry, it.next().toLocal8Bit().constData()); archive_entry_set_filetype(entry, AE_IFDIR); archive_entry_copy_stat(entry, &st); archive_write_header(a, entry); fd = open(inputDirectory, O_RDONLY); bytes_read = read(fd, buff, sizeof(buff)); while (bytes_read > 0) { archive_write_data(a, buff, bytes_read); bytes_read = read(fd, buff, sizeof(buff)); } close(fd); archive_entry_free(entry); archive_write_finish_entry(a); archive_write_close(a); archive_write_free(a); } return 0; }
-
سلام و درود خدمت دوستان عزیز، همانطور که میدانید مهمترین و شاید بزرگترین سوال در حوزهٔ برنامهنویسی این است که من باید کدام زبان برنامهنویسی را انتخاب کنم؟! واقعیت امر این است که این سوال همیشه از سمت علاقهمندان مطرح شده است اما هیچگاه یک پاسخ اساسی در مورد آن ارائه نشده است. البته اساتید و برنامهنویسان حرفهای به خوبی میدانند که زبانهای برنامهنویسی به عنوان ابزارهای کمک کار ما کاربرد دارند و به هیچ عنوان نمیتوان یک زبان را به عنوان اولین و آخرین انتخاب در نظر گرفت، اما شناخت در مورد آنها کمک بسیاری در انتخاب ابزارهای مناسب خواهد کرد. در این پُست من قصد دارم در رابطه با انتخاب یک زبان برنامهنویسی بر اساس نیاز و علایق صحبت کنم تا شما عزیزان بتوانید به یک نتیجهٔ مطلوب برسید. بنابراین، قبل از هر چیز این بسیار مهم است که بدانیم یک زبان برنامهنویسی چیست! و چرا باید از آن استفاده کنیم؟! اجازه دهید نگاهی به دلیل استفاده از زبان برنامهنویسی داشته باشیم، چرا از زبان برنامهنویسی استفاده میکنیم؟ به برقراری ارتباط با یکدیگر فکر کنید، انسان برای برقراری ارتباط با همنوعان نیاز به ابزاری به نام زبان دارد که عناصر اساسی آن حروف است. برای مثال حروف خ-ا-ن-ه با ترکیب شدن به خانه تبدیل شده و شما میتوانید آن را درک کنید و این کدی است که شما توسط آن با جهان بیرون خود ارتباط برقرار میکنید. ممکن است کدهای شما توسط یک زبان دیگر مانند زبان انگلیسی ساخته شود، برای مثال 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 آشنا شوید، پیشنها میشود مقاله زیر را مطالعه فرمایید.
-
سلام، قبل از اینکه کدتون رو بررسی کنیم، ممکن هست خطایی که دریافت میکنید رو هم مشاهده کنیم؟
-
qtdesigner
کامبیز اسدزاده پاسخی برای قاسم رمضانی منش در یک سوال ارسال کرد در سوالات مشاورهای و تخصصی مرتبط با حوزهی برنامهنویسی
بستگی داره با چه دیدگاهی بهش نگاه کنید. مسلماً کسی که حرفهای است در کار خود نیازی به محیطهای ویزاردی ندارد. اما یک واقعیت وجود دارد، در واقع اصل استانداردی است که باید در محیطهای توسعه وجود داشته باشد. بنابراین برای اینکه کنترل سریعتر و بهتری در طراحی و پیاده سازی اجزاء داشته باشید وجود چنین ویژگی بسیار کارآمد خواهد بود. برای مثال جهت بررسی Statesها در یک جزء مشاهدهی بصری آن کمک بسیاری در تصمیم گیری بر تغییرات و توسعه خواهد کرد. فرض کنید مانیتور شما حرفهای با پهنای بسیار بزرگ است، برای طراحی حرفهای نیمی از محیط توسعهی خود را در اختیار نیمی از پهنای مانیتور خود و تمامی بخشها مرتبط با منطق آن را همزمان با یکدیگر تحت نظر قرار خواهید داد. تصویر فوق یک روش استاندارد برای تحت نظر داشتن جزء به جزء یک شیء است که تحت Satetesها بررسی میشود و شما به صورت Real-time میتونید این جزئیات را تحت نظر داشته باشید. نتیجه : کاربرد چنین ویژگی صرفاً جهت تسلط بسیار بر اشیاء و وضعیت آنها در زمان توسعه میباشد.- 1 پاسخ
-
- محیطتوسعه
- بصری
-
(و 2 مورد دیگر)
برچسب زده شده با :
-
database
کامبیز اسدزاده پاسخی برای قاسم رمضانی منش در یک سوال ارسال کرد در سوالات مشاورهای و تخصصی مرتبط با حوزهی برنامهنویسی
سلام، معیارها میتونن بسیار جزئی و کاملاً فنی باشن! مثلاً بحث هزینهها، ساختار، پرفرمنسها، ویژگیها، بحث تجاری بودن، پشتیبانی و غیره... برای مثال MySQL به خاطر سرعت بالا، پشتیبانی از چند-سکویی، پایداری خوب و همچنین پشتیبانی از لایههای چند منظوره و موتورهای چند منظوره برای اهداف خاص بسیار مطرح شده، البته نسخههای متفاوتی دارن که جدیدا MariaDB بسیار بهتر هست. از طرفی PostgreSQL در نسخههای جدیدتر از لحاظ سرعت با MySQL برابری میکند و به خاطر تضمین پشتیبانی از دادههای بسیار بزرگتر نسبت به مایاسکیوال و پشتیبانی از قابلیتهای بسیار زیاد نسبت به آن مطرح هست! مخصوصاً عملکرد بهتری که در سرورهایی با پشتیبانی از پردازندههای چند هستهای دارد. این دو مورد کاربردهای بسیار عظیمی دارند و شما میتونید برای اهداف بزرگ ازشون استفاده کنید. هر دوی این دیتابیسها چند-سکویی هستند اما برای کار حرفهای MySQL و برای کارهای حرفهای تر PostgreSQL پیشنهاد میشه. در نظر داشته باشید بهینه سازی این موارد با ترکیب مختص برای سیستمهای کشینگ مثل Memcached و Redis بسیار چشمگیر خواهد بود. برای پروژهی شما با توجه به توضیحی که دادین MySQL انتخاب خوبی هست. -
سلام، قبلاً در رابطه با این موضوع توضیحات به صورت کامل ارائه شده است. همچنین موارد زیر را مطالعه بفرمایید:
- 1 پاسخ
-
- مشاوره
- رابطکاربری
-
(و 2 مورد دیگر)
برچسب زده شده با :
-
اسلک تمام ایرانیها در همه نقاط جهان را تحریم کرد
کامبیز اسدزاده نوشته وبلاگ را ارسال کرد در ابزارها
اسلک، سرویس آنلاین سازمان دهی فعالیت های گروهی که کار خود را از سال 2015 آغاز کرده و در حال حاضر با 8 میلیون کاربر فعال روزانه یکی از پر استفاده ترین سرویس ها در جهان به شمار می رود، از صبح امروز تمامی کاربران ایرانی خود، شامل افرادی که از داخل ایران از این سرویس استفاده می کردند و همچنین افرادی که خارج از ایران حتی در شرکت هایی خارجی فعالیت داشته و تنها سابقه ای ایرانی داشته اند را تحریم و از دسترسی آنها به تمامی خدمات خود محروم کرد. اقدام عجیب اسلک در حالی صورت گرفته که افرادی با سابقه ایرانی حتی در کشورهایی مانند آمریکا، کانادا و فنلاند هم قادر به استفاده از سرویس های این شرکت نبوده اند و برای مثال اگر یک کمپانی شامل 10 کارمند از کشورهای مختلف از جمله یک کارمند ایرانی از سرویس های اسلک استفاده می کرده است، اکنون تنها کارمند ایرانی قادر به استفاده از مزایای کار گروهی اسلک نخواهد بود و 9 نفر دیگر بدون مشکل به کار خود ادامه می دهند. اسلک در پیامی که به صورت ایمیل به کاربران ایرانی ارسال شده آورده است که این کار با هدف "رعایت قوانین تحریم های اقتصادی و کنترل تجاری ایالات متحده آمریکا علیه ایران" انجام شده و "اسلک با تشخیص هویت کاربران از دسترسی افرادی که به نوعی با تحریم های آمریکا مرتبط هستند به سرویس های خود جلوگیری به عمل می آورد". وب سایت ورج با پیگیری این موضوع به نقل از مدیران روابط عمومی اسلک گزارش داده است که به جز کاربران ایرانی، افرادی با ملیت کوبا، کره شمالی، سوریه و کریمه اکراین هم در فهرست تحریم شدگان قرار دارند. این اقدام در حالی صورت می گیرد که بسیاری از خدمات اسلک به صورت رایگان در اختیار کاربران قرار می گیرد و به جز آن، استفاده از سرویس های مدیریت پروژه آنلاین عملا هیچ تاثیری در تحریم های کالایی و اقتصادی علیه ایران ندارد. ضمن آنکه ایرانیانی که خارج از کشور به کار و زندگی مشغول هستند در اثر این تحریم ممکن است کار خود را از دست داده و زندگی اجتماعی و شغلی خود را در خطر فروپاشی ببینند. دولت آمریکا اخیرا اعلام کرده بود تحریم های ایران دارای اهداف سیاسی بوده و مردم این کشور را تحت فشار قرار نمی دهد؛ اما این اقدام و تحریم های مشابه علیه ایرانیان در سراسر جهان به خوبی نشان دهنده تلاش سازمان یافته این کشور و اتاق فکرهای مرتبط با آن برای مقابله با مفهومی به نام "هویت ایرانی" است. برای جایگزینی اسلک می توانید از نمونه های دیگر خارجی مانند Trello یا سرویس های مشابه سازی شده ایرانی مانند Taskulu استفاده کنید.