اگه یه برنامه کامپایل شد دیگه هیچ مشکلی برای اجرا تو محیطهای مختلف نداره ؟
#include <stdio.h>
#include "conio.h"
main()
{
printf("hello Ajax ! \n");
getch();
return 0;
}
این برنامه در ویندوز کامپایل میشه ..؟
و در لینوکس اجرا میشه ؟
Printable View
اگه یه برنامه کامپایل شد دیگه هیچ مشکلی برای اجرا تو محیطهای مختلف نداره ؟
#include <stdio.h>
#include "conio.h"
main()
{
printf("hello Ajax ! \n");
getch();
return 0;
}
این برنامه در ویندوز کامپایل میشه ..؟
و در لینوکس اجرا میشه ؟
به شرط اینکه از استاندارد های ++C استفاده کنید توسط کامپایلرهای لینوکس مانند gcc قابل کامپایل خواهند بود، توجه کنیم که باید در همانجا دوباره کامپایل کنید چرا که فایل های باینری اجرایی دو سیستم عامل متفاوتند.
به عنوان مثال در ++ISO C جدید (در کامپایلرهای جدید) به جای getch باید از getch_ استفاده کرد تا در کامپایلرهای مختلف در دسترس باشد.
آیا کتابخانه های CLR ماکروسافت را در لینوکس هم میشود استفاده کرد؟نقل قول:
نوشته شده توسط Nima_NF
آیا ++vc را میشود تو لینوکس استفاده کرد،یا باید از mono کمک گرفت؟
با سپاس
کتابخانه های CLR مایکروسافت در سایر سیستم عامل ها وجود دارد. اما نه دقیقا مانند نسخه مایکروسافت.
++VC برای ویندوز هست و سعی کنید فکر استفاده آن را در لینوکس نکنید(حتی اگر با پروژه هایی مثل wine یا mono هم بتوان اجرا کرد).
در لینوکس شاید تنها راه همان Mono هست که کامپایلری هم برای #C ارائه کرده ولی برای ++C ارائه نکرده است.
کلا C++/CLI در ویندوز دردسر ساز هست چه برسد به سایر سیستم عامل ها.
کامپایلرهایی مثل gcc و LCC برای لینوکس (البته زبان C )برای پروژه mono وجود دارد، لیست کامپایلرها:
http://mono-project.com/Languages
اگر کسی به دنبال برنامه نویسی ++C و crossplatform هست بهتر هست دات نت را فراموش کند
یکم در این باره توضیح میدینقل قول:
نوشته شده توسط Nima_NF
اول اینکه CLR را با کل کتابخانه های .NET اشتباه نگیرید.این مطالب را قبلا توضیح داده بودم که ابتدا آن را مطالعه کنید که CLR و class library چه فرقی دارند:
با توجه به مطالب فوق، با وجود اینکه CLR استاندراد است اما عملا به تنهایی برای ما بدون کارآیی است، وقتی بحث بر سر برنامه نویسی دات نت مثلا با #C یا ++C هست همه چیز در همان class library است که در اختیار مایکروسافت است.نقل قول:
در مورد کد های مدیریت شده ، .Net Framework شامل دو جزء اصلی هست:
1- common language runtime یا همان CLR
.NET Framework class library - 2
CLR بخشی هست که اعمالی مثل مدیریت حافظه ، اجرای کد ها و thread ها ، حفظ امنیت کدها و کامپایل آن ها و سایر سرویس های سیستمی را انجام می دهد.
class library همان بخش اصلی .Net برای تولید نرم افزار ها با رابط گرافیکی کاربری (GUI) ، نوشتن برنامه های کنسول ، XML ، ASP.NET و غیره هست.
وقتی گفته می شود کدهای مدیریت شده مستقل از پلتفرم هست یعنی اینکه هر جایی که CLR وجود داشته باشد امکان اجرای آن وجود دارد، به این شکل:
ابتدا آن ها باید به زبان میانی مایکروسافت (MSIL) کامپایل شوند و سپس در هنگام اجرا از طریق کامپایلر JIT / just-in-time به کد های Native سیستمی ترجمه شوند که کدهایی مختص CPU هستند و از آنجایی که CLR از طریق کامپایلر JIT همه پردازنده ها را پشتیبانی و پیاده سازی کرده است پس می توانید برنامه هایی بنویسید که در همه کامپیوترها با ساختار معماری مختلف اجرا شود.
اما این موضوع مهمی است که تا کنون درهمین حد تبلیغاتی باقی مانده است، چرا که اگر در کدهای مدیریت شده از API های Native سیستم عامل یا کتابخانه های مختص آن سیستم عامل استفاده کنید (از جمله class library .NET که چاره ای نیست و باید از آن ها استفاده کرد) لذا برنامه مدیریت شده فقط در همان سیستم عامل قابل اجرا شدن می باشد و تنها راهی که وجود دارد این است که همه شرکت ها یک لیسانس از مایکروسافت با هزینه های بسیار بالا برای کتابخانه های .Net دریافت کنند تا برنامه های نوشته شده در ویندوز که از همان class library استفاده کرده است بتواند در سایر کامپایلرها نیز اجرا و یا کامپایل شود که تا کنون شرکتی این کار را نکرده است و فقط برخی از شرکت ها به شبیه سازی آن اقدام کرده اند.
توجه کنید که CLR و C# استاندارد جهانی هستند و نیاز به خرید ندارند و هر کسی با دریافت استاندارد ها، می تواند کامپایلر آن را پیاده سازی کند ویا حتی زبان خود را نیز مبتنی بر CLR ارائه کند تا از قابلیت های دات نت بهره مند شود. پس بخش مشکل ساز، بخش class library می باشد که تا کنون مختص ویندوز بوده است.
شما از طریق mono دقیقا همان CLR را در دسترس خواهید داشت چرا که بر اساس استاندارد ها است، خود زبان #C هم مانند CLR همین طور ISO است، اما کتابخانه های دات نت و زبان C++/CLI برای دات نت، خیر.
mono آن موارد غیر استاندارد را بر اساس کلاس ها و قابلیت هایشان پیاده سازی می کند (به قولی شبیه سازی می کند) لذا همیشه نمی توان گفت آن ها دقیقا همان هستند و البته همیشه هم به آخرین نسخه دات نت نمی رسند.
در مورد C++/CLI نیز بدتر، چون مایکروسافت هر چند سال ++C را تغییر می دهد و وصله ای مایکروسافتی (غیر استاندارد) به آن اضافه می کند تا نیازمندی های دات نت را تامین کند، ++C برای دات نت در سایر سیستم عامل ها پروژه امن، راحت و مطمئنی برای پیاده سازی نیست. چون ممکن است یکدفعه باز هم نظر مایکروسافت تغییر کند و همه چیز پیچیده شود.
به خاطر همین موارد هست که در بحث دات نت نگاه همگان به سمت #C رفته است.
نیما جان واقعا دستت درد نکنه با این توضیح کاملت.
یکمی هم میتونی از MFC بگی،ممنون میشم
توضیحات کامل در این مقالهنقل قول:
نوشته شده توسط bia2dadash2
رفیق واقعا با اون توضیحاتت شاهکار کردی.نقل قول:
نوشته شده توسط Nima_NF
3 بار اون پست را خوندم.میخواستم یه پست اونجا بزنم ترسیدم بی ربط باشه.
میخواستم ببینم که میشه برنامه های native را به صورت dll در برنامه های maneged استفاده کرد؟
بله، تمامی API ها و کتابخانه های Native نوشته شده خود را می توانید در برنامه های managed استفاده کنید.
برای این کار باید از DllImport در برنامه .NET خود استفاده کنید،
توضیحات بیشتر در این لینک داده شده است.
اینرا به این دلیل گفتم که وقتی میخواستم form را تو native اضافه کنم،به من اطلاع میداد که برنامه شما باید maneged بشه:گریه:نقل قول:
نوشته شده توسط Nima_NF
به نظر من لزومی ندارد که دات نت کار بیاید و native را یاد بگیره،آخه من قبلا با MFC کار کردم و با وجود اینکه خیلی امکانات داشت ولی همون امکانات event دات نت برای من کافی بود.البته دلیلش بیسوادی من بود.
خیلی خیلی ممنون استاد.در ضمن روش توضیحتان،یعنی معرفی کردن به پست پربار خیلی جالب بود،استاد این روش را به بقیه هم بگید تا پست تکراری ایجاد نشه:تشویق:
در اینباره هم توضیح میدهید:
.نقل قول:
توجه کنید که CLR و C# استاندارد جهانی هستند و نیاز به خرید ندارند و هر کسی با دریافت استاندارد ها، می تواند کامپایلر آن را پیاده سازی کند ویا حتی زبان خود را نیز مبتنی بر CLR ارائه کند تا از قابلیت های دات نت بهره مند شود. پس بخش مشکل ساز، بخش class library می باشد که تا کنون مختص ویندوز بوده است.
یکی از پروژه های هم دانشگاهی هام persian #c بود.آیا اون هم از این روش رفته بود،درباره "class library"نمیخواهد توضیح بدید،یکمی درباره همون استاندارد و چگونگی استفاده از آن.
آخه من خیلی دوست دارم یک کامپایلر AVR باشه که با زبان #c بشه program اش کرد
استاندارد چیز خاصی نیست، یکسری اطلاعات هست که در سایت رسمی استانداردها مثل ECMA برای هر نسخه وجود دارد، شامل syntax و قوانین تفسیر و سیمانتیک و ...
http://www.ecma-international.org/pu...s/Ecma-334.htm
حال با داشتن این اطلاعات و استاندارد های دیگر باید شروع به ساختن کامپایلر کنید (طبق مراحل ساخت کامپایلر، انواع تحلیل ها و ...) چیزی به این وسعت به همین راحتی نیست که هر کسی بیاید و آن را با کیفیت خوب پیاده سازی کند. (در هر حال شدنی است)
این پروژه های نصفه و نیمه #C فارسی نیز در حال حاضر یک جایگزینی لغات است تا پروژه عملی. یعنی چند خط کد به آن بدهید و برایتان مراحل تحلیل را انجام دهد. ما در پروژه های کوچک خودمان بخش هایی از ++C را پیاده سازی کردیم، آن ها #C را ...
اگر class-library را از #C بگیرید چه باقی می ماند؟ #C خالی بی معنی است، یک syntax و مدیریت حافظه و ... یعنی تمام علاقه افراد به این زبان به خاطر syntax آن است؟
وقتی نتوانید حتی یک کلمه با آن بنویسید یا چیزی رسم کنید؛ #C هر چه دارد از کتابخانن های GUI و کاربردیش دارد که همراه دات نت است. اگر کسی بخواهد برای سیستم یا سیستم عامل خودش آن ها را پیاده سازی کند باید کاری مثل mono انجام دهد.
مایکروسافت قصد داشت با دات نت , CLR و #C دستگاه های جانبی را نیز در دست بگیرد، اما سرعت پایین تر آن در مقابل سایر زبان های برنامه نویسی و قیمت های گران مایگروسافت برای لیسانس دات نت تا کنون این میل را در دیگران ایجاد نکرده است.
شاید روزی کسی مانند mono چنین کارهایی با #C کرد.
نیما جان واقعا ببخشید که اینقدر سوال میپرسم.آخه بحث جالبی هست و جالب ترین بحثی که تو برنامه نویس دیدم،بدون هیچ گونه غرض ورزی و به دید یک برنامه نویس حرفه.نقل قول:
نوشته شده توسط Nima_NF
منظورت از وسایل جانبی چی هست؟
به نظر تو میشود یک روز ماکروسافت دات نت فریم ورکش را برای وسایل میکرو بگذارد و اسمش را مثلا light dot net بزاره؟ (یک چیزی مثل flash light،ببخشید مثال دیگه بلد نبودم بزنم) و بخش هاییش رو هم متن باز کنه؟ یا شرکت بسکام را بخرد؟
با سپاس فراوان
الآن هم هست،
سال ها است برای smartphone ها و PDA و امثال آن که سیستم عامل مایکروسافتی دارند از compact .NET Framework استفاده می شود. نسخه کوچک شده .NET
برای دستگاه های تعبیه شده Embedded هم پروژه ای با نام : .NET Micro Framework که نسخه 3 آن کم کم باید عرضه شود، برای دستگاه هایی با پردازنده ARM و امثال آن.
به گفته مایکروسافت تاکنون 1.5 میلیون دستگاه بر اساس این framework عرضه شده است. اما هنوز خیلی کم هست و قابل مقایسه با تعداد دستگاه ها نیست (جایی که مایکروسافت و هزینه های آن باشد)
لینک آن:
http://www.microsoft.com/netmf/default.mspx
دستت درد نکنه آقا نیما.من این سول رو از خیلی از AVR کارها پرسیدم اطلاع نداشتند،حتی تو تالار "برنامه نویسی سیستم های Embedded هم پرسیدم،ولی...نقل قول:
This download is the full SDK, which lets you develop C# code for the .NET Micro Framework and run it on our extensible emulator. Then choose from several development kits to deploy your code to real hardware.
آقا نیما به نظر من یکی از خصوصیاتی که باید دات نت داشته باشد تا بتواند گوی برنامه نویسی میکرو هم برباید،مقیاس پذیری یا scalability هست.آیا دات نت مانند برنامه های native دارای این خصوصیت هست؟تا بتوان با آن میکرو avr ها را هم program کرد؟
سلام آقا نیما
منم چند تا سوال دارم که ممنون میشم جواب بدید:
1)این API رو میشه تعریف کنید؟ من یه جایی خونده بودم که توابع و کتابخانه هایی هستند که در dll های خود ویندوز قرار دارن و دیگه نیازی به قرار دادن اون در کتاب خانه های زبان نیست. ولی باز یه مقدار شک کردم، آیا درسته این تعریف؟
2) برنامه نویسی win32 چه جوریه؟ البته توضیحات شما رو توی اون مقاله که نوشته بودین خوندم ولی منظورم از از نظر کد نویسی هست. چون شما گفته بودین که MFC فریم ورکی هست که win32 رو در قالب کلاس ارائه میکنه، حالا میخواستم ببینم همین برنامه هایی که به صورت ساده ماها مینوسیم چه نوعی محسوب میشن. iostream و سایر هدر ها مال چه کتابخانه ای هستند؟
3) آیا از MFC میشه توی محیط هایی مثل C# هم استفاده کرد؟ یا اینکه C# فقط از خود .net استفاده میکنه؟
4) این کلمه CLI یعنی چی که توی C++/CLI میادش؟ البته میدونم به معنی C++.net هست ولی چرا میگن CLI اصلا؟
5) وقتی که از .net هم توی C++ استفاده میکنیم آیا کد های نوشته شده در بستر همون محیط CLR اجرا میشن؟ یعنی همون مراحل تبدیل به کد MSIL و JIT روشون انجام میشه؟
6) در توضیحات بالا گفتین که .net از کتابخانه های مختص سیستم عامل ویندوز استفاده میکنه که این مورد باعث میشه برنامه های .net فقط روی ویندوز اجرا بشن، حالا فرضا یه شرکتی لیسانس .net رو اگر بخره چطور میتونه از اون توی سیستم عامل خودش استفاده کنه؟ به هر حال باز هم .net داره از کتاب خانه های سیستم عامل ویندوز استفاده میکنه که سیستم عامل اون شرکت اونا رو نداره. من درست نمیفهمم این مورد رو.
ببخشید من یه خورده خنگ میزنم، شاید عملا با این ها کار نکردم نمیتونم درکشون کنم.
با تشکر
1- کلمه API یعنی Application Program Interface یا همان "رابط برنامه کاربردى" برای ارتباط با سیستم عامل است که می تواند شامل رابط کاربری UI نیز باشد. پس در هر سیستم عاملی وجود دارد و مختص ویندوز نیست. بلکه فقط و فقط توسط سازنده سیستم عامل منتشر می شود.نقل قول:
1)این API رو میشه تعریف کنید؟
و او است که تصمیم می گیرد چطور آن ها را عرضه کند و چه زبان هایی را پشتیبانی کند.
معمولا شرکت ها برای اینکه کاربران بتوانند از آن استفاده کنند کتابخانه ها و هدر فایل ها را منتشر می کنند بقیه در سیستم عامل وجود دارد.
2- کلمه win32 نامی هست که اکنون به آن windows API می گویند (چون برنامه نویسی را از 16 بیت تا 64 بیت پشتیبانی میکند)، ولی با توجه به محبوبیت همچنان نام win32 را برای برنامه نویسی API در ویندوز به کار می برند.نقل قول:
برنامه نویسی win32 چه جوریه؟
سطح پایین ترین نوع و قوی ترین نوع برنامه نویسی در ویندوز هست. وقتی گفته می شود برنامه نویسی win32 API منظور همین نوع است که خود ویندوز بر اساس آن نوشته شده است و شامل رابط گرافیکی کاربر نیز هست.
در برنامه نویسی MFC می توانید از کلاس های MFC استفاده کنید و یا مستقیم API های win32 را فراخوانی کنید و از آن ها استفاده کنید.
به این برنامه های ساده ای که در محیط کنسول می نویسید، win32 console می گویند. که همان استفاده از windows API است فقط بدون رابط گرافیکی، اما سایر API های ویندوز و امکانات آن قابل استفاده است.نقل قول:
حالا میخواستم ببینم همین برنامه هایی که به صورت ساده ماها مینوسیم چه نوعی محسوب میشن.
در پست 4 و 5 تاپیک گرافیک در ++C/C ، دو مثال win32 با رابط گرافیکی گذاشته ام، مطالعه کنید و انجام دهید تا متوجه شوید؛ نوع پروژه win32 project است نه console:
https://barnamenevis.org/showthread.php?t=103584
iostream و مانند آن برای استاندارد C و ++C هستند.نقل قول:
کتابخانه iostream و سایر هدر ها مال چه کتابخانه ای هستند؟
خیر از MFC نمی توانید.نقل قول:
3) آیا از MFC میشه توی محیط هایی مثل C# هم استفاده کرد؟ یا اینکه C# فقط از خود .net استفاده میکنه؟
شما از win32 API می توانید در #C استفاده کنید. یعنی هر کتابخانه ویندوز را که می خواهید load کرده و توابع آن را استفاده کنید (که به اصلاح به این توابع API می گویند)
CLI یا همان Common Language Infrastructure که Infrastructure یعنی همان زیر ساخت، که در آن نیز CLR , CIL قرار دارد.نقل قول:
4) این کلمه CLI یعنی چی که توی C++/CLI میادش؟ البته میدونم به معنی C++.net هست ولی چرا میگن CLI اصلا؟
اگر به C++این CLI را چسبانده اند برای آن است که مشخص شود همان زبان ++C استاندارد نیست، بلکه برای ارتباط با CLR است.
از این عکس همه چیز مشخص می شود:
http://upload.wikimedia.org/wikipedi...astructure.png
در این لینک نیز توضیحان بیشتر:
Standard ECMA-335
بله،نقل قول:
5) وقتی که از .net هم توی C++ استفاده میکنیم آیا کد های نوشته شده در بستر همون محیط CLR اجرا میشن؟ یعنی همون مراحل تبدیل به کد MSIL و JIT روشون انجام میشه؟
اگر لینک آخری که برای استاندارد گذاشتم را مشاهده کرده باشید متوجه می شوید که CLI استانداردی هست که باعث می شود قوانین کامپایل و ترجمه و ... در آن بدون توجه به معماری و زبان برنامه نویسی در همه جا یکی باشد.
نه وابستگی کامل ندارند. شاید در موارد بالا کمی بد گفتم.نقل قول:
6) در توضیحات بالا گفتین که .net از کتابخانه های مختص سیستم عامل ویندوز استفاده میکنه که این مورد باعث میشه برنامه های .net فقط روی ویندوز اجرا بشن، حالا فرضا یه شرکتی لیسانس .net رو اگر بخره چطور میتونه از اون توی سیستم عامل خودش استفاده کنه؟
مطمئنا نیاز نیست همه موارد پیاده سازی شوند، چون تمامی گرافیک، کنترل ها و غیره ... وابستگی به کنترل ها Native سیستم عامل ندارند و یک پیاده سازی جدید هستند، لذا باید بتوان آن موارد را با یک لیسانس به سیستم های دیگر منتقل کرد. (چیزی شبیه java)
(هر چند که با توجه به اطلاعات منتشر شده هنوز هم در مورد این سوال اطلاع کاملا دقیق ندارم)
فرق های دیگری که وجود دارد این است،
- قوانین طراحی و specifications در اختیار شرکت قرار می گیرد تا همه چیز را بتوانند پیاده سازی کنند؛ کاری که mono نتوانست.
- همواره نسخه های عرضه شده به روز خواهند بود، چرا که مایکروسافت آن ها را از سال ها قبل از تغییرات باخبر خواهد کرد.
- و مطمئنا مایکروسافت کارهای دیگری خواهد کرد که ما از آن ها اطلاع نداریم...
و اما جواب من....
این micro.net که همه avr ها رو پشتیبانی نمیکنه(حتی avr mega ها رو).
با سپاس
خیلی خیلی ممنون نیما جان
یعنی توابع موجود در کتابخانه ها خودشون از API ها برای ارتباط با ویندوز استفاده میکنند یا اینکه توابعی که ما استفاده میکنیم خود API ها هستند. مثلا توی اون برنامه گرافیکی از توابعی مثل DrawBorder و SetCursor و ... استفاده شده بود. آیا این توابع خود API های ویندوز هستند یا اینکه توابعی از کتابخانه های ارائه شده هستند؟نقل قول:
معمولا شرکت ها برای اینکه کاربران بتوانند از آن استفاده کنند کتابخانه ها و هدر فایل ها را منتشر می کنند بقیه در سیستم عامل وجود دارد.
آیا میشه API ها رو به نوعی همون Interrupt ها فرض کرد؟ البته به نوعی یه level بالاتر، مثلا interrupt ها در سطح کار با ثبات های cpu دونست ولی API ها رو در سطح سیستم عامل؟
اگه میشه از این توابع API یه تابعی چیزی مثال بزنید تا بهتر بشه فهمید.
در عکسی که بالا قرار دادید، آیا MSIL که گفتین زبان میانی مایکروسافت هست همون CIL میشه که کد ها رو به زبان میانی ترجمه میکنه؟
قاعدتا کامپایلر JIT هم باید در CLR باشه که کد های 0 و 1 تولید شده از CLR در تصویر بالا از همین JIT هست. آیا درسته؟
راستی توی برنامه نویسی win32 همه چیز رو باید خود برنامه نویس بسازه؟ اینجوری که من توی اون برنامه گرافیکی متوجه شدم، حتی یه دکمه هم وجود نداره و باید پیاده سازی بشه. البته توی صحبت های شما قبلا گفته بودین که همه چیز رو باید برنامه نویس کنترل کنه و پیاده سازی کنه ولی تا این حد فکر نمیکرم دیگه :دی
بازم ممنون بابت توضیحات خوبتون ;)
بله به تمام آن توابعی که از dll های ویندوز استفاده می کنیم API می گوییم(دقیق تر windows API).
برای یک مثال که خودتان می شناسید: تابع GetKeyboardState برای دریافت حالت کلید های کیبرد یک API هست، داخل user32.dll است و هدر آن نیز در Windows.h قرار دارد. import library آن نیز User32.lib هست که باید در کامپایر در linker تعریف شود (این مورد در VC به طور پیش فرض تعریف شده است، برای سایر موارد باید دستی اضافه کنیم)
تابع SetCursor برای کار باموس ، یا Rectangle برای گرافیک نیز API هستند، حال در dll های مختلف مثلا در Gdi32.lib که با نام GDI شناخته می شود.
پس نیاز به مثال مجدد نیست، همه توابعی که در آن مثالی که لینکش را گذاشتم دیدید و نمی شناختید یا در windoes.h قرار داشتند همه API بودند (یا کلا بخشی از SDK ویندوز).
API ها را نمی توان به Interrupt تعبیر کرد، فقط یکسری توابع برای انجام کارها هست، مثلا برای پیاده سازی توابع کار با کیبرد از ++C (و شاید در صورت نیاز اسمبلی) استفاده شود برای خواندن پورت های ورودی .
کلا حتی اگر شما یک سخت افزار بسازید و برای آن یکسری SDK یا توابعی منشر کنید که با فرخوانی آن ها بتوان با سخت افزارتان ارتباط برقرار کرد ( مثلا روی آن چیزی بنویسد، بوق بزند و ... ) در اصطلاح به آن ها API می گوییم.
در مورد CLR هم بله درست است.
JIT در شکل نیامده ولی کدها توسط همان JIT ترجمه می شوند
خیر همه چیز وجود دارد.(فراموش نکنید پایه تمامی قسمت های ویندوز win32 است)نقل قول:
راستی توی برنامه نویسی win32 همه چیز رو باید خود برنامه نویس بسازه؟ اینجوری که من توی اون برنامه گرافیکی متوجه شدم، حتی یه دکمه هم وجود نداره
من برای اینکه کاربران تازه کار درگیر control های پیشرفته نشوند حرفی از آن ها نزدم و فقط محیطی برای رسم اشکال فراهم کردم.
این مثال را ببینید(با عکس است):
http://www.winprog.org/tutorial/controls.html
شما مثل سایر شیوه ها و زبان های برنامه نویسی محیط visual دارید تا طراحی دیالوگ کنید، اما به راحتی آن ها یا .NET نیست. (و تعداد کنترل ها نیز به اندازه و وسعت .NET نیست)
مثلا در win32 این طور نیست که بر روی یک button کلیک کنید تا اتوماتیک رویدادی را بسازد و راحت داخلش کد بنویسید. شما باید ID آن button را کپی کنید و سپس در بخش مربوط به پیام ها خودتان دستی بخشی برای فراخوانی آماده کنید، (یعنی ID آن را در switch-case اضافه کنید)
در MFC این سختی کمتر شده و اتومات سازی مانند سایز زبان ها وجود دارد و کمتر نیاز به نوشتن دستی هست.
برای خواندن یا نوشتن اطلاعات در کنترل ها نیز، با یک = نمی توانید داده ها یا رشته ها را بخوانید. باید دستی پیامی به شکل زیر بفرستید با ID همان کنترل تا در متغیر مورد نظر داده کپی شود، مثلا برای اضافه کردن رشته به listbox:
int index = SendDlgItemMessage(hwnd, IDC_LIST, LB_ADDSTRING, 0, (LPARAM)"Hi there!");
زیاد تعجب نکنید، اکثر برنامه های معروف که در منزل استفاده می کنید در نسخه ویندوز خود، اگر از MFC کمک نگیرند، مستقیم از طریق همین win32 برنامه خود را نوشته اند:
3ds max ، Photoshop ، ...
اصلا آیا میشه VS رو تو لینوکس run کرد؟
این سوال در همین تاپیک پرسیده شد! ای کاش ابتدا مطالعه می کردید...نقل قول:
نوشته شده توسط fazel-d
خیر، ++VC مخصوص ویندوز هست.
شما می توانید کدهای ++C/C را به صورت استاندارد بنویسید در ویندوز با VC کامپایل کنید و در لینوکس با gcc و در MAC OS با Xcode
بچه ها با micro dot net کسی کاری کرده؟
نیما جان چرا پرسش من رو جواب ندادی؟
در کل در مورد سوال آخر شما باید دوستانی که وابستگی به #C دارند نظر بدهند!نقل قول:
نوشته شده توسط bia2dadash2
زبان هایی مثل java و pythin نشان داده اند که می توانند برای دستگاه های میکرو به خوبی استفاده شوند، پس بله #C هم به همان صورت می تواند کاربردی باشد اما با توجه به وابستگی آن به CLR مطمئنا هرگز به کیفیت C نخواهد بود و به همین زودی راه 30 ساله C را نمی تواند طی کند.(ضمن اینکه دسترسی مستقیم و سطح پایین به حافظه و غیره را از دست خواهید داد) در هر حال ما که تاکنون در جایی یا دستگاهی ندیدیم که #C جز افرایش سرعت در تولید با آن، برتری چشمگیر دیگری ارائه دهد.
(توجه داشته باشید که ابتدا باید سایر سخت افزارها را نیز پشتیبانی کند در غیر این صورت فعلا باید منتظر بمانید تا شاید روزی ...)
پرسش شماره 16 منظورم بود
دوستان واقعا بحث جالبی راه انداختین
اما حقیقتا خود من شاید حدود کمتر از دو هفته از که اصلا متوجه شدم چیزی به نام C++/cli وجود داره که با دات نت فریم ورک کار میکنه
متاسفانه توی مملکت ما همش میگن vb.net یا C#.net ! اصلا نمیزارن این زبون جدید (اگه اشتباه نکنم از سال 2005 با دات نت فریم ورک 2 اومد) پا بگیره از همه دوستان که در این زمینه خبره هستند خواهش میکنم بیشتر در مورد این زبان مطلب بنویسن.
به قدر کافی در مقاله زیر توضیح داده شده است که چرا در دنیا (نه فقط در ایران) کمتر حرف C++/CLI زده می شود، مخصوصا که مطالب جدید هم اضافه شده است:نقل قول:
نوشته شده توسط asemaneahvaz
برنامه نویسی ++C/C از نوع Native یا managed ؟
از همان آغاز در .NET با ++C نیز امکان برنامه نویسی بود. قبلا با extention هایی به زبان ++C این کار انجام می شد ولی از VC++2005 با نام C++/CLI و تغییرات یکپارچه دیگری در این زبان.
ضمنا توجه داشته باشید که قرار دادن لینک کتاب های تجاری ممنوع است.
من کی گفتم که قبل از vs 2005 نمیشد کدهای C++ رو داخل دات نت نوشت!!نقل قول:
از همان آغاز در .NET با ++C نیز امکان برنامه نویسی بود. قبلا با extention هایی به زبان ++C این کار انجام می شد ولی از VC++2005 با نام C++/CLI و تغییرات یکپارچه دیگری در این زبان.
مطلب من رو دقت نکردید. من گفتم که C++/cli که کدهای اون managed هستن و تحت نظارت دات نت ( و البته از فواید دات نت فریم ورک هم استفاده میکنند.) از vs 2005 به بعد عرضه شد. وگرنه چه قبلا و چه الان میشه کدهای C++ استاندارد رو در پروژه های دات نت استفاده کرد.
البته منظور من هم استفاده ++C استاندارد در پروژه های دات نت نبود، بلکه دقیقا نوشتن پروژه کامل managed با ++C به همان شکل C++/CLI بود.نقل قول:
نوشته شده توسط asemaneahvaz
قبل از ارائه C++/CLI چیزی با نام "++Managed Extensions for C" یا نام کوتاه آن "++Managed C"وجود داشت، که معادل همین C++/CLI بود یعنی managed بود و garbage collection داشت و از کل دات نت می شد استفاده کرد و ....
آنها توابع و امکانات جدید در کامپایلر های اولیه VC++.NET به زبان ++C بودند تا بتوان یک پروژه کامل managed با .NET نوشت (همانند #C وVB.NET و ...)، syntax ها هم شبیه آن بود، کلا فقط به آن نام زبان را نمی دانند، که بعد از تغییراتی و افزودن امکاناتی با نام C++/CLI عرضه شد و syntax ها نیز عوض شد.
قبلا در ++Managed C برای تخصیص حافظه managed و امثال آن از دستوراتی مثل gc class__ ، همان new (اما برای managed) و ... استفاده می شد که در C++/CLI نیز معادل آن ها، اما با نامی متفاوت از ++C استاندارد، مانند gcnew و ... ارائه شدند. ( که با سبک متفاوت همه چیز را یکباره به هم ریخت)
در نسخه های اخیر ++VC دیگر ++Managed Extensions for C پشتیبانی نمی شود و منسوخ شده است و باید از C++/CLI استفاده کرد.
منظور من این مطالب بود، اگر شما می دانستید که خوب، سایر دوستان می توانند استفاده کنند و آگاه شوند که در طی این سال ها مایکروسافت چه بلاهایی بر سر ++C آورد.
آقا نیما این مقاله را با تمام لینک های توش رو بخونید.
میشه لطفا یکم توضیح بدید؟،چون هیچی نفهمیدم.
نقل قول:
Although SharpOS and Cosmos are still largely experimental and aren't really intended for use on regular desktop systems, they provide some insight into the kind of innovations that would be made possible if next-generation operating system kernels were designed to use managed code. The theoretical implications of these projects are very intriguing and will likely spur a lot of discussion in the operating system design community.
مطالب داخلی آن خیلی زیاد بودند، وقت نداشتم همه را مطالعه کنم.
البته بهتر هست مطالب #C در بخش خودش مطرح شوند نه در اینجا.
از این گونه پروژه های تحقیقاتی فراوان هست، ساخت سیستم عامل های آزمایشی با #C بر اساس CLI که خود kernel را نیز با #C نوشتند (بر خلاف رقیبش java که مطرح می کنند مانند آن kernel را با assembly ننوشتند )؛ به گفته خودشان از اسمبلی بسیار کم استفاده شده است شاید 10 خط.
مثلا در پروژه Cosmos توسط کامپایلر IL2CPU کدهای میانی #C به assembly تبدیل می شدند و سپس توسط NASM به کد native x86 تبدیل می شدند و ...
من بیشتر دوست داشتم در مورد کد نویسی kernel اطلاعات بدست آورم تا کد #c و توانمندیهایش.نقل قول:
نوشته شده توسط Nima_NF
و موضوع بحث من بیشتر native و managed کد بود
در پروژه ای آینده از nasm استفاده نمیگنند.در ضمن ضحمت #C به assembly هم MIL میکشد.نقل قول:
مثلا در پروژه Cosmos توسط کامپایلر IL2CPU کدهای میانی #C به assembly تبدیل می شدند و سپس توسط NASM به کد native x86 تبدیل می شدند و ...
فقط انجاش رو نمیفهمم که چجور این assembly ها و کدهای درست شده را به X86 مرتبط میسازند.میخواستم کمی در باره kernel توضیح بفرمایید و اینکه آیا میشود kernel هم با برنامه نویسی managed نوشت؟
با تشکر