نگرانی برنامه‌نویسان در مقابل ویندوز 8 و آینده

[hjran abdpor]

با سلام.یه سوال کوجولو داشتم ، ایا WinRt جای Win32 را میگره یا نه ؟
میشه توشح بدین هسته WinRT چی هست ؟

[iranpcl]

سلام
اینکه به نظر نمیاد مایکروسافت بتونه دانت فریمورک رو حذف کنه یه فکر غلط هست
چرا که تجربه ویندوز vista هنوز قابل فراموشی نیست
ویندوزی که هر لایسنسش با قیمتی بیشتر از قیمت یه کامپیوتر معمولی فروخته شد و همونطور ناقص رها شد اینکه ایران و کشورهایی که عضو انجمن بین المللی رعایت کنندگان قوانین کپی رایت نیستن رفع این چنین تجرباتی برامون آسونه
اگر قراره ویندوز 8 از ابزارالات ویندوز 7 به پایین رو پشتیبانی کنه ناچاری مایکروسافت رو به این کار نشون میده ولی گفته شده ویندوز 8 نرم افزار های نوشته شده وین 7 رو پشتیبانی میکنه! این یعنی تضمینی برای نرم افزار های سایر سیستم عامل های ویندوز وجود نداره!!! و این یعنی ویندوز بعدی مشخص نیست چند مرده حلاج باشه یا اصلا... !
هرچند میشه حدس زد که چقدر این شرکت تلاش برای بالا بودن این پشتیبانی با سیستم عامل جدیدش میکنه!
شاید برنامه های نوشته شده برمبنای سیلورلایت و فلش و ... تو ویندوز 8 به خوبی کار کنند ولی این به معنی ویندوزی جدید با پشتیبانی wpf یا سیلورلایت و ... شاید نباشه چرا که از اشاره های متنی برای پشتیبانی نرم افزار های وین 7 "نرم افزار های ویندوز7 به خوبی در سیستم عامل جدید اجرا خواهند شد" میشه حدس زد که یک لایه از وین 7 برای اجرای کار برنامه های نوشته شده براش گذاشته شده
وقتی یه شرکت نرم افزاری برنامه ای رو مینویسه درواقع روی ان نرم افزار سرمایه گذاری چند ساله یا چند ده ساله و یا برای شرکت های بزگ جند صد ساله میکنه و دو مورد اول برای اشخاص حقیقی برنامه نویس(یعنی ما ها هم) صادقه
البته وین8 تا جانشین ویندوز های فعلی بشه......... چرا که هنوز XP سرویس پک دوش هم خیلی جاها استفاده میشه و اونم تو کشوری که شکر خدا قوانین بین المللی کپی رایت نداره وگرنه که الان کمتر کسی وین 7 داشت چه برسه به بحث روی وین 8 که هنوز نسخه نهاییش عرضه نشده و این یعنی فرصت برای تغییر
اینکه سیلور لایت، wpf ، دات نت و ... حذف شه یعنی مایکروسافت داره یه تکون دسته جمعی میده و چیزی هم براش جز پیشرفت مهم نیست، این نیت مایکروسافت میتونه تو ویندوز بعدیش چند برابر لرزه بیشتری داشته باشه!!!!!! اونقدری که فرصت چندانی برای تغییر نباشه

[مهران رسا]

با سلام.یه سوال کوجولو داشتم ، ایا WinRt جای Win32 را میگره یا نه ؟
میشه توشح بدین هسته WinRT چی هست ؟

What is WinRT

[hjran abdpor]

دوستعزیز وبلاگت باز نشد اگه میشه یه ذره توضیح بدن البته خلاصه دریک خط.

[morrning]

ولی این هم درست نیست که مایکروسافت ما رو به ویژوالش معتاد کنه بعد بگه من هر سازی زدم شما برنامه نویس ها باید باهاش برقصید

یه تجربه شخصی که من حدود 6 سال پیش گرفتم و هنوزم به این تصمیم افتخار میکنم این بود رابطم با ابزار های توسعه ماکروسافت قطع کردم برای طرحی وب رفتم دنبال php و برای دسکتاپ هم رفتم دنبال جاوا .اوایل خیلی سخت بود به خصوص اینکه برنامه های یک پارچه که هم رو وب باشن هم دسکتاپ اجراشون خیلی مشکل بود ولی با مدتی مطالعه و تمرین و به خصوص php-gtk خیلی از مشکلاتم حل شد.

به دلیل همین تحولات غیر منتظره ماکروسافت هم که مدیر عاملشون صبح از خوب بلند میشه تصمیم میگیره نصف تولیدات شرکتشون رو عوض کنه چند سالی هست که تولیدات شرکتمون رو با تمرکز بر سکوی لینوکس دست مشتری میدیم . به هر حال خوبی تولیدات متن باز اینه که روند تغییرات با شیب متعادلی پیش میره مثل گذر از php4 > php5 و لازم نیست اطلاعات قبلیت رو دور بریزی بلکه فقط آپدیتشون میکنی ولی توی ماکروسافت از این خبرا نیست vb6 به vb.net رو در نظر بگیرید .یه شبه حدود 1000تا تابع و کلاس به نسخه جدید اضافه شد و از اون طرف 1000 تا رو حذف کردن.

این نظر شخصی منه که همیشه به دلیل این تغییرات وسیع و تبلیغات بی حد و حساب روی این تغییرات ماکروسافت همیشه پول خوبی به جیب زده و در عوض شرکت ها و سازمان ها همیشه باید برای آموزش کارمنداشون ضرر های زیادی رو متحمل میشن. فرض کنید یه شرکت متوسط توی کشوری مثل هند که 400 تا برنامه نویس داشته باشه که با دات نت کار میکنن یهو باید چه هزینه ای بده که همه برنامه نویساش رو با ویندوز 8 با این همه دنگ و فنگاش کوچ بده, ویندوزی که این طور که در این خبر اومده قراره بدون دات نت و سیلورلایت باشه

[ARC]

فعلا که چیزی درست مشخص نیست پس بهتره صبر کنیم تا مشخص و بشه و هر چی به ذهنمون رسید رو نگیم...
در مورد تغییرات هم دنیای کامپیوتر به قول برخی از دوستان پیشرفت و تغییراتش سریع هست ولی متاسفانه ما ایرانی ها همیشه دنبال راحتی هستیم و میخوایم مثلا با یادگیری یک زبان تا آخر عمر همه نیاز هامون رو پوشش بدیم و حتی حاضر نیستم در در نسخه های بعدی همون زبان هم تغییر کلی به وحود بیاد که نیاز باشه 2 تا کتاب بخونیم و میخوایم با 2 تا صفحه وب یا یه PDF 50 صفحه کار رو تموم کنیم. اگر دنبال تغییر نیستین خوب رشته هایی مثل میکانیک رو انتخاب کنید که هر مثلا 100 سالی یکی بیاد یه تغییر بده.
البته میتونه در حوزه های متن باز کار کنه که تغییراتش کمتره.
باید بگم تا جایی که اطلاع دارم این تغییرات حاصل 1 پروژه است که 10 سال پیش شروع شده (قابل توجه کسانی که فکر میکنن مدیر های مایکروسافت یه شبه تصمیم گرفتن!!!)

[vcldeveloper]

در مورد تغییرات هم دنیای کامپیوتر به قول برخی از دوستان پیشرفت و تغییراتش سریع هست ولی متاسفانه ما ایرانی ها همیشه دنبال راحتی هستیم و میخوایم مثلا با یادگیری یک زبان تا آخر عمر همه نیاز هامون رو پوشش بدیم و حتی حاضر نیستم در در نسخه های بعدی همون زبان هم تغییر کلی به وحود بیاد که نیاز باشه 2 تا کتاب بخونیم و میخوایم با 2 تا صفحه وب یا یه PDF 50 صفحه کار رو تموم کنیم. اگر دنبال تغییر نیستین خوب رشته هایی مثل میکانیک رو انتخاب کنید که هر مثلا 100 سالی یکی بیاد یه تغییر بده.

چه ربطی به ایرانی بودن داشت؟! جنابعالی اگر سری به مطالب سایت ها، انجمن ها، و وبلاگ های مربوط به برنامه نویسی برای سکوی ویندوز؛ در بازه زمانی بعد از معرفی ویندوز 8 تا اتمام کنفرانس Build مایکروسافت بزنید، حجم گسترده ایی از نگرانی ها، ابراز یاس و نا امیدی ها، حدس و گمان ها، و سایر واکنش ها را خواهید دید. اونها هم ریشه ایرانی داشتند؟!!

[betisa]

به نظر من به جای اظهار نظر های مبهم در مورد حرف های دیگران و چیزی که مایکروسافت به عنوان نو آوری در سیستم عامل جدیدش معرفی کرده خیلی راحت میشه با سیستم عامل جدید کار کرد و نتیجه رو دید. بیشترین نگرانی که ابراز شده مربوط به زبان های Native هست چون بیشتر اون ها با Api سیستم عامل کار می کنند. به نظر من در مورد .net و زبان های مربوط به اون نگرانی خاصی نیست چرا که مایکرو سافت ابزار های توسعه .net را در نسخه developer این ویندوز قرار داده که نشون دهنده پشتیبانی کامل این سیتم عامل از .net و کتاب خانه های مربوط به اون هست. و در مورد رابط کاربری metro هم باید گفت که این رابط استاندارد جدید در طراحی برنامه ها رو داره پایه گزاری میکنه و اگر ما به تاریخ مراجعه کنیم این مسئله مارو یاد ویندوز تا نسخه 3 میندازه که هر دو محیط (ویندوز و داس) رو در کنار هم برای کاربران فراهم کرده بود و این باعث اقبال بیشتر کاربران از این سیستم عامل در برابر رقیبانش شد نه تجربه بد کاربران در محط گرافیکی. به نظر من مایکرو سافت با این عمل به شرکت های توسعه نرم افزار این قابلیت رو میده تا زمان گزار از نرم افزار های صرفا pc رو با آرامش بیشتر به سمت tablet طی کنند و این یکی از خصوصیات شرکتی مثل مایکرو سافت (این کاملا نظر شخصی منه و هر کسی میتونه باهاش مخالف باشه!) و در ضمن مایکروسافت با این کار دو رقیب عمده خودش که android و ios باشه رو در مسئله تعداد application های موجود برای سیستم عامل که یکی از بزرگترین مسائل در زمینه رقابت بین سیستم عامل هاست رو کنار میگزاره و همچنین در مسئله راحتی توسعه هم این قابلیت رو داره. پس با یک نگاه منطقی و دقیق میبینم که مایکرو سافت در حقیقت قدم بسیار بزرگی رو در زمینه تحول سیستم های عامل برداشته. و این تحول منطبق با قدم های قبلیش و هماهنگ با توسعه تکنولوژی های نرم افزاری و سخت افزاری که خودش یکی از سردم دارانش هست برداشته.

نتیجه کلی:

1- درمورد زبان های native چون این زبان ها در برنامه نویسی برای سیستم عامل وابسته به API های سیستم عامل هستند ناگزیر به تغییر با آن هستند. و این یکی از مسائلی هست که باعث جهت گیری مایکروسافت به سمت .net شد.

2- در مورد زبان ها و تکنولوژی های مربوط به .net: اگر مایکروسافت قصد حذف کردن .net و خانواده تکنولوژی های مربوط به اون رو داشت در نسخه developer هیچ وقت visual studio .net 11 رو قرار نمی داد.

3- در مورد محیط کاربری metro هم همین بس که این محیط برای استفاده در touche device ها طراحی شده و برای استاندارد سازی محیط های کاربری جدید برای این نوع خاص دستگاه ها نه محدود کردن کاربران این دستگاه ها به این نوع از محیط کاربری ( که صد البته چون برای touche طراحی شده بسیار کاربردی تر و راحت تر خواهد بود).

[ARC]

چه ربطی به ایرانی بودن داشت؟! جنابعالی اگر سری به مطالب سایت ها، انجمن ها، و وبلاگ های مربوط به برنامه نویسی برای سکوی ویندوز؛ در بازه زمانی بعد از معرفی ویندوز 8 تا اتمام کنفرانس Build مایکروسافت بزنید، حجم گسترده ایی از نگرانی ها، ابراز یاس و نا امیدی ها، حدس و گمان ها، و سایر واکنش ها را خواهید دید. اونها هم ریشه ایرانی داشتند؟!!

جناب کشاورز عزیز بنده قصد بی احترامی به کسی رو نداشتم من خودم هم یک ایرانی هستم پس اگر چیزی بگم شامل خود من هم میشه. بنده چیزی رو که روزانه دارم میبینم میگم خیلی از ما هایی که اسم خودمون رو میزاریم برنامه نویس گاهی حتی اطلاع درستی از زبانی که روش کار میکنیم هم نداریم، نه بلدیم اصولی کد بنویسیم، نه حاضریم یکم تحقیق کنیم و 2 تا کتاب بیشتر بخونیم من نمی خوام بگم من همه این کارو انجام میدم یا نه فیلسوفی هستم توی کامپیوتر شاید از همه دوستان این انجمن هم بی سواد تر باشم ولی سعیم رو میکنم که درست کار کنم و چیزایی رو که نمیدونم یاد بگیرم و با اومدن یک تکنولوژی جدید فکر نمی کنم که آسمون به زمین امده و ... ولی خیلی ببخشید خیلی از ما هایی که اسم خودمون رو گذاشتیم برنامه نویس تا کد بلد میشیم یا 1-2 تا کتاب میخونیم دیگه فکر میکنیم تموم شد حالا دیگه شدیم یه برنامه نویس حرفه ای و دو روز بعد اگه مثلا یه تغییری به وجود امد میگیم این کار اشتباه هست و ... چرا ؟!! چون ما فقط بلد بودیم در حد همون 2 تا کتاب کد بزنیم و حاضر هم نیستیم به هیچ عنوان چیزی یاد بگیریم. شاید خارج از ایران هم همین طور باشه (که من مطمئن نیستم) ولی به همین مهندس های کامپوتری که هر ساله از دانشگاه فارغ التحصیل میشن نگاه کنید چند درصدش بلده 1 برنامه درست حسابی بنویشه یا یک شبکه رو مدیریت کنه.

[mazdadoost]

تایید میشه.دو نوع IE10 در وین ۸ هست.یکی برای مترو یکی برای دسکتاپ معمولی.

سایت هایی که با سیلورلایت طراحی شده با دانلود افزونه سیلورلایت و نصب آن در بخش Desktop در اینترنت اکسپلورر 10 مشابه با ویندوز 7 اجرا میگردد

[Dariuosh]

سلام
مایکروسافت به غیر از ویندوز 8 و ویژوال استودیو 11 ، اکسپرشن بلند 5ام تو این پکیجش داده
به نظرم عمده دلیلش برا ارتباط بیشتر با زمل (XAML)ه ، زمل ام یعنی دبلیو پی افو سیلورلایت .
IE10 ایی که تو 8 داده(PP3) ، دوتا فیس داره ، یکی برا دنیای کنوونی ویندوز ،یکیم برا دنیای تاچش یا هموون مترو
به نظره شما منطقیه که یهو مایکروسافت بگه از این به بعد هر کی بخواد با تاچ بره اینترنت فقط میتونه جاهایی بره که HTML5 هست ولا غیر ؛ این یعنی مثلا یوتیوب خاستی بری از این ور چیزی ایدت نمیشه ، از اوون ور باید بری
خودشونم که گفتن این کار برا ایجاد یه تجربه جدید برا برنامه نویس هاس ، این ورژن حتی بتا هم نیست

بعدشم دات نت داد که برنامه نویس درگیر یه عالمه هیاهو نشه دیگه ، حالا بیاد ورش داره که چی ؟ دات نت 4.5 هم که تو کاره ،تو 8 .

[FastCode]

به جای اینکه خوشحال باشیم که مغزمان از کارکردن با تکنولوژی‌های تکراری یخ نمی‌زند و با چنین پلتفرم جزابی می‌توانیم به سادگی برنامه‌نویسی کنیم، من نمی‌دانم اینهمه نق و غر برای چیست ؟

اونهایی که میخوان مغزشون یخ نزنه, میتونن و با محیطهای دیگه تحت ویندوز مثل Qt و wx و java و صد تا چیز دیگه کار کنن و میکنن.اونهایی که با API ویندوز کار میکنند(مثل خود من) مجبور هستند که این کار رو بکنند.
وگرنه API ویندوز در مقابل موارد فوق اصلاً چیز خوشایندی نیست.

[L u k e]

به نظر شما با آومدن این ویندوز جاوا و زبان های دیگه باید نسخه جدیدی واسه ویندوز 8 ارئه کنند یا نه ؟

[مهران رسا]

WinRT و برنامه نویسی سرور

Most WinRT APIs are only usable inside Metro style apps. ASP.Net or any server programming for that matter, is done in the context of a desktop application. Thus a large amount of WinRT is not usable there. If you look at the WinRT reference, you will see that most of what is present is aimed at consumer apps, not server applications.

Microsoft has not said what will happen in the future, but for Windows 8/Server 8 WinRT is not aimed at server development.

[A.Karimi]

اونهایی که میخوان مغزشون یخ نزنه, میتونن و با محیطهای دیگه تحت ویندوز مثل Qt و wx و java و صد تا چیز دیگه کار کنن و میکنن.اونهایی که با API ویندوز کار میکنند(مثل خود من) مجبور هستند که این کار رو بکنند.
وگرنه API ویندوز در مقابل موارد فوق اصلاً چیز خوشایندی نیست.

بنده با وجود اینکه بر روی سکوهای مایکروسافت کار می‌کنم از زمانی که Red Hat فقط Linux متن باز داشت با Linux نیز کار کرده‌ام. برای من در اکثر اوقات در کنار ویندوز، Linux نیز نصب است و حداقل در Linux برنامه نویسی کرده‌ام. خوب است بدانید که از آن زمان (متن باز بودن Red Hat) تا کنون Qt، wx و Java چه تغییراتی کرده‌اند (فارق از اینکه در ویندوز توسعه بدهید یا در Linux). زمانی مغز ما یخ می‌زند که فقط در یک مسیر ثابت حرکت کنیم. البته این حرف فقط از منظر برنامه‌نویسی قابل بررسی است.

در حال حاظر متاسفانه یا خوشبختانه دو رقیب اصلی وجود دارند Java و dotNet که بر همه آشکار است، قدرت و انعطاف زبان #C بسیار بسیار بیشتر از زبان Java است حالا از امکاناتی مثل LINQ، WCF، WPF و بچه‌های WPF و ... بگذریم. ساختار پلتفرم dotNet در زمینه وب کوچکتر از چیزهایی امثال J2EE است چون J2EE با هدف Application Server ایجاد شده ولی dotNet هدفی دیگر داشته! از نظر راحتی کاربر هم؛ بیشتر کاربران نهایی (Power Users) وقتی می‌شنوند یک برنامه با Java نوشته شده پشتشان می‌لرزد! (انصافاً برنامه‌های بسیار خوبی مثل Eclipse هم وجود دارد اما...)

در مورد ++C هم بهتر می‌دانید که در وادی دیگری قابل بررسی است.

بنده به شخصه اگر انتخاب بهتری از تکنولوژیهای زنده مایکروسافت وجود داشته باشد با کمال میل دوست دارم وارد آن وادی شوم.

[FastCode]

بنده با وجود اینکه بر روی سکوهای مایکروسافت کار می‌کنم از زمانی که Red Hat فقط Linux متن باز داشت با Linux نیز کار کرده‌ام. برای من در اکثر اوقات در کنار ویندوز، Linux نیز نصب است و حداقل در Linux برنامه نویسی کرده‌ام. خوب است بدانید که از آن زمان (متن باز بودن Red Hat) تا کنون Qt، wx و Java چه تغییراتی کرده‌اند (فارق از اینکه در ویندوز توسعه بدهید یا در Linux). زمانی مغز ما یخ می‌زند که فقط در یک مسیر ثابت حرکت کنیم. البته این حرف فقط از منظر برنامه‌نویسی قابل بررسی است.

در حال حاظر متاسفانه یا خوشبختانه دو رقیب اصلی وجود دارند Java و dotNet که بر همه آشکار است، قدرت و انعطاف زبان #C بسیار بسیار بیشتر از زبان Java است حالا از امکاناتی مثل LINQ، WCF، WPF و بچه‌های WPF و ... بگذریم. ساختار پلتفرم dotNet در زمینه وب کوچکتر از چیزهایی امثال J2EE است چون J2EE با هدف Application Server ایجاد شده ولی dotNet هدفی دیگر داشته! از نظر راحتی کاربر هم؛ بیشتر کاربران نهایی (Power Users) وقتی می‌شنوند یک برنامه با Java نوشته شده پشتشان می‌لرزد! (انصافاً برنامه‌های بسیار خوبی مثل Eclipse هم وجود دارد اما...)

در مورد ++C هم بهتر می‌دانید که در وادی دیگری قابل بررسی است.

بنده به شخصه اگر انتخاب بهتری از تکنولوژیهای زنده مایکروسافت وجود داشته باشد با کمال میل دوست دارم وارد آن وادی شوم.

بنده شخصاً مدت زیادی نیست با Qt آشنا شدم و وافعاً راضی هستم.
البته از داتنت سختتره.ولی محدودیتهایی رو که در داتنت دارم در Qt ندارم.
به عنوان مثال همین آخری, توی یک سری گزارش نیاز به SSE داشتم که توی داتنت به هیچ عنوان قابل پیاده سازی نیست. ولی با یک بنچمارک ساده فهمیدم که چون SSE ندارم سرعتم زیر یک درصده.
یا مثلاً استفاده از shared memory با semaphore که پیاده سازیش توی C#‎ رو من هنوز بعد از ۵ سال نفهمیدم.
توی این چیزها dotnet هرگز به پای C++‎ نمیرسه.

در مواردی که اشاره کردید مثل WPF و WCF و .... از نظر تئوری هم C++‎ نمیتونه حرفی برای گفتن داشته باشه.

[A.Karimi]

بنده شخصاً مدت زیادی نیست با Qt آشنا شدم و وافعاً راضی هستم.
البته از داتنت سختتره.ولی محدودیتهایی رو که در داتنت دارم در Qt ندارم.
به عنوان مثال همین آخری, توی یک سری گزارش نیاز به SSE داشتم که توی داتنت به هیچ عنوان قابل پیاده سازی نیست. ولی با یک بنچمارک ساده فهمیدم که چون SSE ندارم سرعتم زیر یک درصده.
یا مثلاً استفاده از shared memory با semaphore که پیاده سازیش توی C#‎ رو من هنوز بعد از ۵ سال نفهمیدم.
توی این چیزها dotnet هرگز به پای C++‎ نمیرسه.

در مواردی که اشاره کردید مثل WPF و WCF و .... از نظر تئوری هم C++‎ نمیتونه حرفی برای گفتن داشته باشه.

البته عقیده من بر این است که dotNet برای پروژه های تجاری و حتی سیستم‌عاملهای آینده مناسب تر است اما به هیچ عنوان دلیل بر بد بودن یک زبان یا تکنولوژی دیگر نخواهد بود و چنین عقیده‌ای ندارم. این مورد درباره Qt که یک کتابخانه بسیار عالی برای ++C است هم صادق است. اگر شما بخواهید با ++C برنامه بنویسید مسلماً Qt اگر بهترین نباشد به نظر من یکی از بهترین گزینه‌هاست.

اما بحث این پست بر سر تغییرات تکنولوژی بود که باز هم تاکید می‌کنم Qt نسبت به چند سال قبل مثلاً زمان dotNet 2.0 چه تغییری کرده؟ و dotNet چه تغییری؟ این تغییرات به نظر بنده باعث سرزندگی است!

در مورد Shared Memoery و Semaphore که اشاره کردید و در کل درخصوص برنامه نویسی غیر همزمان (Asynchronous Programming) اگر کار با ++C را در این زمینه «جهنم» تصور کنید کار با #C را می‌توانید «بهشت» تصور کنید. و البته در dotNet نسخه 5 این مورد فوق العاده و فوق العاده ساده‌تر و شیرین‌تر شده بدون اینکه از قدرت کار کاسته شود. به طوری که برنامه‌نویسی Async ظاهری شبیه Sync خواهد داشت و مفهومی به نام Callback دیگر وجود نخواهد داشت. اگر این موارد برای شما مهم هستند حتماً مطالعه‌ای بر روی C#‎ 5.0 و دستورات کلیدی async و await داشته باشید. و البته سمافور هم دیگر مانند دهه‌ی 70 میلادی نیست و با استفاده در دستور lock در زبان #C به راحتی می‌توانید عملیات مورد نظرتان را انجام دهید. هرچند سمافور به همان شکل سنتی هم در dotNet قابل دسترس است.

[AlgorithmX]

بنابراین طبق اطلاعات موجود اینطور گفته میشود كه قرار است به زودی Silverlight و WPF حذف شوند و در ادمه آن .NET (دات نت) نیز حذف خواهد شد!

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=

Windows Application، WPF Application و ... هنوز بر روی ویندوز 8 قابل برنامه نویسی و استفاده است، تکنولوژی های جدیدتر هم اضافه شده اند.

کاملا درسته!
حذف WPF, Silverlight و .. عملی غیر ممکن از سوی مایکروسافته! چون این تکنولوژی ها این قدر قدرتمند و قابل رشد هستند که اگه هم اتفاقی قرارباشه رخ بده اضافه کردن امکان جدیدی از جمله طراحی رابط کاربری برای مترو به این تکنولوژی هاست، نه حذف آنها!!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=
واسه این تکنولوژی و این دگرگونی ها هم نسخه جدید ویژوال استدیو رو داره عرضه میکنه! که دوستان لینکش رو گذاشته بودن!
خبری از نسخه جدید ویژوال استدیو و امکانات جدید!!

[FastCode]

البته عقیده من بر این است که dotNet برای پروژه های تجاری و حتی سیستم‌عاملهای آینده مناسب تر است اما به هیچ عنوان دلیل بر بد بودن یک زبان یا تکنولوژی دیگر نخواهد بود و چنین عقیده‌ای ندارم. این مورد درباره Qt که یک کتابخانه بسیار عالی برای ++C است هم صادق است. اگر شما بخواهید با ++C برنامه بنویسید مسلماً Qt اگر بهترین نباشد به نظر من یکی از بهترین گزینه‌هاست.

اما بحث این پست بر سر تغییرات تکنولوژی بود که باز هم تاکید می‌کنم Qt نسبت به چند سال قبل مثلاً زمان dotNet 2.0 چه تغییری کرده؟ و dotNet چه تغییری؟ این تغییرات به نظر بنده باعث سرزندگی است!

در مورد Shared Memoery و Semaphore که اشاره کردید و در کل درخصوص برنامه نویسی غیر همزمان (Asynchronous Programming) اگر کار با ++C را در این زمینه «جهنم» تصور کنید کار با #C را می‌توانید «بهشت» تصور کنید. و البته در dotNet نسخه 5 این مورد فوق العاده و فوق العاده ساده‌تر و شیرین‌تر شده بدون اینکه از قدرت کار کاسته شود. به طوری که برنامه‌نویسی Async ظاهری شبیه Sync خواهد داشت و مفهومی به نام Callback دیگر وجود نخواهد داشت. اگر این موارد برای شما مهم هستند حتماً مطالعه‌ای بر روی C#‎ 5.0 و دستورات کلیدی async و await داشته باشید. و البته سمافور هم دیگر مانند دهه‌ی 70 میلادی نیست و با استفاده در دستور lock در زبان #C به راحتی می‌توانید عملیات مورد نظرتان را انجام دهید. هرچند سمافور به همان شکل سنتی هم در dotNet قابل دسترس است.

حیف نمیتونم نمیونه کد بزارم که بفهمید lock یک ابداع احمقانه بیشتر نیست.(اگر بزارم انقدر پیچیدست که نمیفهمید/فقط توضیح میدم.)
فرض کنید دو تا لیست داریم که در شرایطی از تغییرات اولی دومی هم تغییر میکنه ولی در زمانی که دومی داره تغییر میکنه اولی دیگه قرار نیست تغییر کنه و اگر اولی باز بشه ممکنه طوری تغییر بکنه که دومی نخواد تغییر بکنه.
این جزء مواردیه که نمیشه با lock پیاده سازی کرد.

از این موارد در C++‎ زیاده.
مثل ترکیب for و switch

[A.Karimi]

حیف نمیتونم نمیونه کد بزارم که بفهمید lock یک ابداع احمقانه بیشتر نیست.(اگر بزارم انقدر پیچیدست که نمیفهمید/فقط توضیح میدم.)
فرض کنید دو تا لیست داریم که در شرایطی از تغییرات اولی دومی هم تغییر میکنه ولی در زمانی که دومی داره تغییر میکنه اولی دیگه قرار نیست تغییر کنه و اگر اولی باز بشه ممکنه طوری تغییر بکنه که دومی نخواد تغییر بکنه.
این جزء مواردیه که نمیشه با lock پیاده سازی کرد.

از این موارد در C++‎ زیاده.
مثل ترکیب for و switch

هر موردی که با سمافور قابل حل باشد با بلاک lock نیز قابل حل است. مضاف بر اینکه عرض کردم در دات نت شما به سمافور ها دسترسی دارید. تا جایی که من متوجه شدم این مسئله‌ای که مطرح کردید با بلاک lock قابل حل است. فقط شما باید شی مناسبی را جهت دادن به این دستور انتخاب کنید. شما چه شیی را به بلاک lock میدادید که با مشکل مواجه می‌شدید؟

چرا نمی‌توانید نمونه کد ارسال کنید؟ خیلی مشتاق شدم که این مساله را با C#‎ حل کنم. هر چند که از موضوع بحث این تاپیک خارج شدیم. اگر موضوع نفهمیدن ماست، نگران فهمیدن ما نباشید نمونه کد را بفرستید.

پیشنهاد می‌کنم یک تاپیک جدید برای این موضوع ایجاد کنید تا با زبانهای مختلف این مساله حل شود. نتیجه خیلی جالب خواهد بود.

[vcldeveloper]

حیف نمیتونم نمیونه کد بزارم که بفهمید lock یک ابداع احمقانه بیشتر نیست.(اگر بزارم انقدر پیچیدست که نمیفهمید/فقط توضیح میدم.)
فرض کنید دو تا لیست داریم که در شرایطی از تغییرات اولی دومی هم تغییر میکنه ولی در زمانی که دومی داره تغییر میکنه اولی دیگه قرار نیست تغییر کنه و اگر اولی باز بشه ممکنه طوری تغییر بکنه که دومی نخواد تغییر بکنه.
این جزء مواردیه که نمیشه با lock پیاده سازی کرد.

مکانیزم lock در دات نت با استفاده از monitors پیاده سازی شده، و هر چیزی که بشه با Semaphores پیاده سازی کرد رو میشه با monitors هم پیاده سازی کرد، پس ادعایی که کردی از نظر فنی فاقد ارزش هست. علاوه بر اون، synchronization primitives مثل semaphores، critical sections, events و غیره توسط سیستم عامل پیاده سازی میشند و در اختیار برنامه ها قرار می گیرند. زبان های برنامه نویسی می تونند بر اساس آنها ساختارهای سطح بالاتری (مثل monitors) ایجاد کنند. این synchronization primitives در اختیار هر زبان برنامه نویسی که بتونه با API سیستم عامل تعامل برقرار کنه، هستند؛ پس تصورت مبنی بر اینکه semaphore یا هر کدام از سایر synchronization primitives ها مختص یک زبان برنامه نویسی خاص (مثل ++C) هستند، یا در فلان ابزار برنامه نویسی لزوما نباید در دسترس باشند، هم اشتباه هست.

[FastCode]

خب بزارید یه جور دیگه توضیح بدم که از نظر فنی درست بشه!!!!
lock obj1
lock obj2
unlock obj1
unlock obj2
الان این رو یکی با C#‎‎ حل کنه.میخوام بخندم.


بهترین روش برای این کار استفاده از جاواست.

[A.Karimi]

خب بزارید یه جور دیگه توضیح بدم که از نظر فنی درست بشه!!!!
lock obj1
lock obj2
unlock obj1
unlock obj2
الان این رو یکی با C#‎‎ حل کنه.میخوام بخندم.


بهترین روش برای این کار استفاده از جاواست.

دوست عزیز lock و unlock کردن یک object جزو عملیات سیستمی است! شما با این چهار خط توضیحات فنی دادید؟ obj1 و obj2 چه ارتباطی با هم دارند؟ این دو از نوع static هستند یا dynamic؟ چهار خطی که اشارده کردید در چه contextی قرار دارند؟ هرکدام از عملیاتها چقدر زمانبر هستند (چون شما می‌توانید کل عملیات را داخل یک بلاک synchronize شده قرار داده و به راحتی انجام دهید)؟

لطفاً به جای مطرح کردن موضوع به این شکل، مسئله را شفاف مطرح کنید. شک نکنید که با همه زبانهای برنامه نویسی می‌توان آنرا حل کرد! نه فقط #C بلکه همه زبان‌های مدرن که قابلیت ارتباط با سیستم عامل را داشته باشند (از جمله جاوا و ...) و یا به صورت توکار از مفاهیم synchronization پشتیبانی کنند می‌توانند این مسائل را حل کنند.

لطفاً مساله را واضح و روشن مطرح کنید تا کدهای ساده و روشن زبانهای مختلفی چون #C را مشاهده کنید. و البته باز هم پیشنهاد می‌کند در یک تاپیک جدا گانه مطرح کنید و در اینجا لینک بدهید تا موضوع این تاپیک حفظ شود.
توجه داشته باشید که بحث ما کل کل بر سر زبانها نیست و من به شخصه دوست دارم مسائل مشکل synchronization را حل کنم. بنده خالق هیچ یک از این تکنولوژی‌ها نیستم و دلیلی بر دفاع از جان گذشته از آنها نمی‌بینم. علاقه من و امثال من به برنامه‌نویسی است و همانطور که از ++C به #C مهاجرت کردیم در صورت لزوم از #C هم به یک زبان بهتر مهاجرت خواهیم کرد (بدون ناراحتی).

با تشکر.

[vcldeveloper]

الان این رو یکی با C#‎‎‎ حل کنه.میخوام بخندم.

الان به نظر خودت اون چهار خطی که نوشتی، صورت یک مسئله هست؟!

بهترین روش برای این کار استفاده از جاواست.

جان هر کس که دوست داری، اینقدر اظهار نظرهای الکی و غیر فنی نکن! جاوا از نظر مکانیزم های lock و Synchronization چیز بخصوصی بهت نمیده که در #C یا خیلی از سایر زبان های امروزی موجود نباشه. این چیزهایی که اینجا مطرح میکنی، مسائلی نیست که به یک زبان برنامه نویسی بخصوص برای حل شدن نیاز داشته باشه، و همانطور که در پست قبلی هم گفتم، ربطی به زبان برنامه نویسی نداره.

[Dariuosh]

سلام
مایکروسافت به غیر از ویندوز 8 و ویژوال استودیو 11 ، اکسپرشن بلند 5ام تو این پکیجش داده
به نظرم عمده دلیلش برا ارتباط بیشتر با زمل (XAML)ه ، زمل ام یعنی دبلیو پی افو سیلورلایت .
.

نظرم کاملاً اشتباه بوود چون اکسپرشن بلند 5 تو این پکیج برا طراحی برنامه های مترو فرم هستش ،همشم HTML5 , CSS
Expression Blend for HTML

[محمد باقری نسب]

دوستان همه مطمئن باشید که شرایط بسیار بهتر از اینچه که هم اکنون در دنیای IT شاهد آن هستیم خواهد شد.

[iranpcl]

دوستان همه مطمئن باشید که شرایط بسیار بهتر از اینچه که هم اکنون در دنیای IT شاهد آن هستیم خواهد شد.

صد در صد
ولی باید یکم به تگ و توگ مایکروسافت برقصیم

[AlgorithmX]

با این دگرگونی و انقلابی که مایکروسافت راه انداخته، آیا ممکنه ایقدر امنیت محصولاتش (ویندوز، ویژوال استدیو و ..) اینقدر بالا رفته باشه که امکان کرک شدنشون به -0- برسه!! (حالا صفر هم نه، خیلی سخت بشه!!)؟ یعنی نیم بیشتر ما مجبور به خرید محصولاتش بشیم؟!!

[iranpcl]

اینکه سخت تر بشه نمیدونم ولی هیچ وقت 0 نمیشه چرا که اصلا ساختار سخت افزاری pc اینطوره
مثالا: برای اجرای هر اپلیکیشنی باید اپلیکیشن تو رم لود شه!!!!!!!!!!!
پ.ن: میشه با ابزار هایی محتوای رم و دامپ کرد

[A B C D]

احتمالا با فناوری TC میشه به چنین هدفی رسید یا حداقل خیلی نزدیکتر شد. یعنی طوری که مهندسی معکوس و در نتیجه کرک کردن برنامه ها که نیاز به مهندسی معکوس داره، غیرممکن یا بسیار بسیار دشوارتر بشه.
این تاپیک رو ملاحظه کنید: پالادیوم - NGSCB

یکی از خواص این فناوری که گفته ببینید چیه:

بنابراین برای هرکسی، منجمله مالک رایانه، بسیار دشوار خواهد بود تا یک برنامهء قابل اعتماد را فریب دهد تا خارج از حافظهء پنهان شده اجرا شود. این از روی دیگر موجب میشود تا مهندسی معکوس یک برنامهء قابل اعتماد بینهایت دشوار شود.

--------------------------

با این دگرگونی و انقلابی که مایکروسافت راه انداخته، آیا ممکنه ایقدر امنیت محصولاتش (ویندوز، ویژوال استدیو و ..) اینقدر بالا رفته باشه که امکان کرک شدنشون به -0- برسه!! (حالا صفر هم نه، خیلی سخت بشه!!)؟ یعنی نیم بیشتر ما مجبور به خرید محصولاتش بشیم؟!!

این دگرگونی ها بنظرم ارتباط خاصی به کرک و اینها ندارن. بلکه پیشرفت در بالا بردن سطح برنامه نویسی هستن. حتی میشه گفت خیلی از فناوریهای جدید در برابر مهندسی معکوس و کرک شدن ضعیف تر هستن. بطور مثال چون این برنامه ها حتی پس از کامپایل دارای ساختارهای سطح بالاتر و متادیتای زیادی هستن. یا مثلا دات نت که اساسا خیلی راحتتر قابل مهندسی معکوس و کرک شدن هست.
در طراحی فناوریهای امروزی موضوع مهندسی معکوس و کرک رو چندان درنظر نمیگیرن. چون حداقل در مراحل اولیه این مسائل اهمیت و اولویت بالایی ندارن و هزینه هاشون توجیه شده نیست و درواقع فرایند طراحی و مشکلات فنی رو بیش از حد گسترده و پیچیده میکنن و اصلا در خیلی موارد نمیشه از بیشتر شدن امکان مهندسی معکوس و کرک جلوگیری کرد مگر اینکه از یکسری امکانات و ساختارهای سطح بالای مهم یا حتی اساسی صرفنظر بشه.
اینکه برنامه های exe قدیمی رو خیلی سخت تر میشه مهندسی معکوس و کرک کرد بخاطر اینه که با امکانات و زبان برنامه نویسی سطح پایین تری نوشته میشن و در نهایت به کد اجرایی خیلی بدوی تری کامپایل میشن که متادیتای خیلی کمی داره و خیلی کمتر با ساختارها و الگوهای خودکار و سطح بالا تولید شده یا به کتابخانه های سطح بالا و سرویسهای خارجی سطح بالا پیوند خورده.
هرچی سطح برنامه نویسی بالاتر میره، مهندسی معکوس و کرک برنامه ها ساده تر میشه و راه کامل و راحت و کم هزینه ای هم برای جلوگیری از این امر وجود نداره. یعنی این راه حداقل چیزی نیست که بتونه در سطح نرم افزاری (به تنهایی) باشه.
چیزی که بدیهی هست اینه که باوجود اینها، بالا بردن سطح برنامه نویسی اونقدری مزایا داره که کمتر کسی ترجیح میده بخاطر سخت تر شدن کرک و مهندسی معکوس بیاد از فناوریهای برنامه نویسی سطح بالا صرفنظر کنه. در خیلی جاها و موارد اصلا این مسائل چندان مهم نیستن. و در کشورهای دیگر هم میشه گفت بخاطر اعمال حقوق انحصار فکری (کپی رایت و غیره) از طریق قانون، نیاز به راههای فنی خیلی کمتر هست و از موارد محدودی که سوء استفاده صورت میگیره صرفنظر میشه و بهرحال بقدر کافی از فروش و انحصار قانونی خودشون درآمد دارن.

اما همونطور که در بالا مطرح کردم فناوریهای مثل TC اساسا قدرت زیادی در این وادی (جلوگیری از مهندسی معکوس و کرک) دارن و بنظرم میشه با اون حتی برنامه های دات نت رو هم در برابر مهندسی معکوس و کرک تا حد زیادی ایمن تر کرد (یا شاید هم کاملا). اما فناوری TC هنوز به اون شکل پیاده سازی و دارای کاربرد کامل و گسترده نشده و خیلی ها باهاش مخالف هستن و اون رو خطرناک میدونن؛ چون معتقد هستن ازش بیشتر سوء استفاده خواهد شد و درکل سایدافکت های منفی بیشتری خواهد داشت تا اینکه مفید باشه. چون امکان کنترل انحصاری برنامه نویسان رو بر رایانه ها افزایش میده و کاربران تاحد زیادی قدرت کنترل خودشون رو بر رایانهء خودشون از دست میدن. این مسئله ممکنه برای همه کس حتی برنامه نویسان پیش بیاد و نامطلوب باشه. مثلا ممکنه میکروسافت ویژگی نامطلوبی رو بخاطر منفعت خودش در سیستم عامل و برنامه هاش بذاره که باوجود فناوری TC ما به هیچ وجه قادر به از بین بردن اون نباشیم، اما الان این امکان رو داریم و میتونیم تقریبا همه چیز رو حالا سخت یا آسون دستکاری کنیم و تغییر بدیم و شاید به همین خاطر شرکتهای بزرگ تولیدکنندهء نرم افزار ویژگیهای ناخوشایند و پنهان خیلی کمتری رو در محصولات خودشون قرار میدن، اما وقتی قدرت اونها بواسطهء TC افزایش پیدا کنه ممکنه از این قدرت برای تحمیل خواسته های خودشون به ما استفاده کنن.
ریچارد استالمن حرف جالبی میزنه که میگه با این فناوری رایانه های ما بجای اینکه از ما اطاعت کنن از دیگران اطاعت میکنن و ممکنه بر علیه خودمون استفاده بشن.
مشکل پایمال شدن حقوق انحصار فکری و بعضی مسائل امنیتی یه چیزه، که TC میتونه به اون کمک کنه، و مشکل سوء استفادهء طبیعی و قابل پیشبینی از TC چیز دیگه ای که بنظر خیلی ها بیشتر و مهمتره.

بهرصورت بنظر نمیرسه براحتی دست از پیاده سازی چنین چیزی برداشته بشه چون کاربردهای قابل توجهی داره و برای خیلی ها هم منافع مهمی درش هست.
بطور مثال ارتش آمریکا اجازهء خرید رایانه هایی رو که امکانات سخت افزاری لازم برای TC رو نداشته باشن نمیده. هرچند این امکان هنوز بصورت کامل در نرم افزارها پیاده سازی نشده و مورد استفاده نیست، اما احتمالا پیشبینی آیندهء نزدیک رو میکنن که از این فناوری برای تامین امنیت بیشتر رایانه های مورد استفاده در مراکز نظامی استفاده کنن.

[iranpcl]

آیا wpf قراره از روی vs2012 هم حذف شه؟؟؟
کسی اطلاعی داره؟

[Amir Oveisi]

این دو صفحه رو کامل بخونید لطفا، پاسخ خیلی از سوالاتتون رو می گیرید:
http://arstechnica.com/microsoft/new...eam-reborn.ars
http://arstechnica.com/microsoft/new...m-reborn.ars/2

[iranpcl]

این دو صفحه رو کامل بخونید لطفا، پاسخ خیلی از سوالاتتون رو می گیرید:
http://arstechnica.com/microsoft/new...eam-reborn.ars
http://arstechnica.com/microsoft/new...m-reborn.ars/2

ممنون ولی فیلترند

[FastCode]

سلام.
فکر میکنم توی این چند روزی که آفلاین بودم بحث عوض شده.

خب اگر میشد با C#‎‎ نوشت که اینطوری نمینوشتم.
یه نمونه آماده کردم.نمیدونم کامپایل میشه یا نه.

static class TheSimpleCode

{

public static void Main()

{

object obj1 = new object();

object obj2 = new object();

lock(obj1)

{

lock(obj2)

{



//change these two lines in some way to

//release obj1 before releasing obj2

}//line 1

}//line 2

}

}



static class Example_MoreRealistic

{

public static void Main()

{

syncRoot = new object ();

MyList = new Tuple<object,List<int>>[100000];

System.Threading.Thread[] Threads = new Thread[100];

for(int ThreadCounter = 0;ThreadCounter != 100;ThreadCounter++)

{

Threads[ThreadCounter] = new Thread(myProcedure);

Threads[ThreadCounter].Start();

}

for(int ThreadCounter = 0;ThreadCounter != 100;ThreadCounter++)

{

Threads[ThreadCounter].Join();

}

Console.WriteLine("Done.");

}

static object syncRoot;

static Tuple<object, List<int>>[] MyList;

static void myProcedure()

{

Random R = new Random();

for(int OuterLoopCounter = 0 ;OuterLoopCounter != 100000;OuterLoopCounter++)

{

int sum = 0;

lock(syncRoot)

{

List<int> Ints = null;

object obj2 = null;

if(MyList[OuterLoopCounter] == null)

{

obj2 = new object();//the same obj2 in example 1

Ints = new List<int>();

MyList[OuterLoopCounter] = new Tuple<object,List<int>> (obj2, Ints);

//look at next comment (4 lines down)

}

else

{

obj2 = MyList[OuterLoopCounter].Item1;

Ints = MyList[OuterLoopCounter].Item2;

//If the thing was possible, i could lock obj2 right here and unlock syncRoot, but i simply can't.

}

lock(obj2)//Instead i lock obj2 here, without unlocking syncRoot; because i can't.

{

for(int n = 0 ;n !=100;n++) // note:this loop is worth releasing and locking syncRoot.

{

int Next = R.Next(65536);

sum += Next;

Ints.Add(Next);

}

if(sum > 3276800)//Half the times

{

MyList[OuterLoopCounter].Item2.Clear();

}

}

}

}

}

}

[mehdi.mousavi]

سلام. فکر میکنم توی این چند روزی که آفلاین بودم بحث عوض شده. خب اگر میشد با C#‎‎ نوشت که اینطوری نمینوشتم. یه نمونه آماده کردم.نمیدونم کامپایل میشه یا نه.

سلام.
lock در حقیقت متود Exit کلاس Monitor رو در finally block قرار میده تا مطمئن بشیم که Lock آزاد شده. فقط همین!
در نتیجه، در این کدی که اشاره کردید:

object obj1 = new object();

object obj2 = new object();



lock (obj1)

{

    lock (obj2)

    {

        //change these two lines in some way to

        //release obj1 before releasing obj2

    }

}

کافیه تا بدین شکل عمل کنیم:

object obj1 = new object();

object obj2 = new object();



Monitor.Enter(obj1);

Monitor.Enter(obj2);



Monitor.Exit(obj1);

Monitor.Exit(obj2);

تا به هدفمون برسیم. اینجا، طبق خواسته شما، با Enter وارد ناحیه بحرانی اول میشیم (و سپس ناحیه بحرانی دوم). در نهایت، اول lock ای که روی obj1 گذاشته شده رو آزاد می کنیم (به بیان دیگه از ناحیه بحرانی اول خارج میشیم، در حالیکه obj2 هنوز Lock هستش) و سپس lock دوم رو آزاد می کنیم... طبیعتا باید حواسمون به Exception های احتمالی ای که ممکنه این بین رخ بده نیز باشه...

موفق باشید.

[FastCode]

سلام.
lock در حقیقت متود Exit کلاس Monitor رو در finally block قرار میده تا مطمئن بشیم که Lock آزاد شده. فقط همین!
در نتیجه، در این کدی که اشاره کردید:

object obj1 = new object();

object obj2 = new object();



lock (obj1)

{

    lock (obj2)

    {

        //change these two lines in some way to

        //release obj1 before releasing obj2

    }

}

کافیه تا بدین شکل عمل کنیم:

object obj1 = new object();

object obj2 = new object();



Monitor.Enter(obj1);

Monitor.Enter(obj2);



Monitor.Exit(obj1);

Monitor.Exit(obj2);

تا به هدفمون برسیم. اینجا، طبق خواسته شما، با Enter وارد ناحیه بحرانی اول میشیم (و سپس ناحیه بحرانی دوم). در نهایت، اول lock ای که روی obj1 گذاشته شده رو آزاد می کنیم (به بیان دیگه از ناحیه بحرانی اول خارج میشیم، در حالیکه obj2 هنوز Lock هستش) و سپس lock دوم رو آزاد می کنیم... طبیعتا باید حواسمون به Exception های احتمالی ای که ممکنه این بین رخ بده نیز باشه...

موفق باشید.

سلام.
ممنون, دقیقاً دنبال همین بودم.
البته به این نتیجه هم رسیدیم که lock اینجا کارایی نداره.

از همه عذر میخوام که باعث شدم موضوع تاپیک منحرف بشه.

[A.Karimi]

سلام.
فکر میکنم توی این چند روزی که آفلاین بودم بحث عوض شده.

خب اگر میشد با C#‎‎‎‎ نوشت که اینطوری نمینوشتم.
یه نمونه آماده کردم.نمیدونم کامپایل میشه یا نه.

static class TheSimpleCode

{

public static void Main()

{

object obj1 = new object();

object obj2 = new object();

lock(obj1)

{

lock(obj2)

{

 

//change these two lines in some way to

//release obj1 before releasing obj2

}//line 1

}//line 2

}

}

 

من حدس می‌زنم شما با شی Monitor در dotNet آشنا نباشید. نیازی نیست حتماً از lock استفاده کنید. lock تضمین می‌کند که اگر در بلاک به هر دلیلی اجرای برنامه به جای دیگری پرش کرد (مثلا به علت Exception و...) در این صورت حتماً Monitor.Exit فراخوانی شود.

در واقع کد زیر:

lock (obj)

{

    ...

}

معادل کد زیر است:

System.Threading.Monitor.Enter(x);

try {

   ...

}

finally {

   System.Threading.Monitor.Exit(x);

}

منبع : http://msdn.microsoft.com/en-us/libr...(v=vs.71).aspx

در این صورت چیزی که شما دنبال آن هستید شبیه کد زیر خواهد بود:

object obj1 = new object();

object obj2 = new object();

 

System.Threading.Monitor.Enter(obj1);

System.Threading.Monitor.Enter(obj2);

...

System.Threading.Monitor.Exit(obj1);

System.Threading.Monitor.Exit(obj2);

همانطور که ملاحظه می‌کنید طبق کامنت شما خط 1 و 2 جابجا شدند. این باید همان چیزی باشد که شما به دنبال آن هستید.

برای اطلاعات بیشتر و همچنین آگاهی از بقیه امکانات: http://msdn.microsoft.com/en-us/libr...g.monitor.aspx

مقایسه درباره همزمان سازی در Java و #C (این مقایسه در رابطه با ویژگی‌های زبان است):
1. http://www.javacamp.org/javavscsharp/sync.html
2. http://en.csharp-online.net/CSharp_F...a_synchronized
و ...

اگر علاقه بیشتری به مقایسه این دو زبان دارید، در این خصوص به لینک زیر مراجعه بفرمایید:
http://en.wikipedia.org/wiki/Compari...Sharp_and_Java

توضیح اینکه با احترام به برنامه‌نویسان جاوا در این مقایسه قدرت و زیبایی زبان #C کاملاً مشخص است. لطفاً جدول مقایسه ویژگی‌های زبان و همچنین مقایسه قطعه کدهای هر دو زبان را ملاحظه کنید.
در کل هدف بنده این بود که بدانید از نظر امکانات همزمان سازی تقریباً فرقی بین #C و Java وجود ندارد. با این تفاوت که در dotNet 4.5 امکانات Multi-threading بسیار ساده‌تر و قوی‌تر شده است.

و البته این مورد به این تاپیک بی ربط نیست؛ اگر زبان #C اکنون اینقدر پویا و کامل است علتش همین سیاست‌های مایکروسافت بوده که در آن، «تغییر» جایگاه ویژه‌ای دارد. همانطور که ما در مهندسی نرم‌افزار در سالهای اخیر آموختیم چابکی و تغییر پذیری جزوء مهمترین فاکتورهای موفقیت در پروژه‌های امروزه است.

-- ویرایش --
قبل از ارسال پست صفحه تاپیک را بروز رسانی نکرده و پاسخی که قبلاً این مورد داده شده بود را ندیدم. اما به دلیل رفرنس‌هایی که دادم و همچنین مقایسه بین #C و Java و ... این پست را حذف نمی‌کنم.
متشکرم.

[vcldeveloper]

توضیح اینکه با احترام به برنامه‌نویسان جاوا در این مقایسه قدرت و زیبایی زبان #C کاملاً مشخص است. لطفاً جدول مقایسه ویژگی‌های زبان و همچنین مقایسه قطعه کدهای هر دو زبان را ملاحظه کنید.
در کل هدف بنده این بود که بدانید از نظر امکانات همزمان سازی تقریباً فرقی بین #C و Java وجود ندارد. با این تفاوت که در dotNet 4.5 امکانات Multi-threading بسیار ساده‌تر و قوی‌تر شده است.

مکانیزم های lock در #C و synchronized در جاوا هر دو از Monitors استفاده می کنند، و از این لحاظ #C برتری خاصی نسبت به جاوا نداره. از نظر کتابخانه های مربوط به Parallel Computing، فرق جاوا با #C در این هست که برای #C به جز شرکت مایکروسافت، بازیگر بخصوصی وجود نداره، و مایکروسافت خودش این ابزارها رو معمولا تهیه میکنه، ولی در جاوا بازیگران گسترده تر هستند، و معمولا برنامه نویس باید از بین چند انتخاب موجود بهترین گزینه برای کار خودش را انتخاب کنه.

و البته این مورد به این تاپیک بی ربط نیست؛ اگر زبان #C اکنون اینقدر پویا و کامل است علتش همین سیاست‌های مایکروسافت بوده که در آن، «تغییر» جایگاه ویژه‌ای دارد. همانطور که ما در مهندسی نرم‌افزار در سالهای اخیر آموختیم چابکی و تغییر پذیری جزوء مهمترین فاکتورهای موفقیت در پروژه‌های امروزه است.

خیلی بحث تغییرات مکرر مایکروسافت در جهتگیری هاش در حوزه توسعه نرم افزار درش دخیل نیست. جاوا حداقل یک دهه قبل از #C عرضه شده، و طراح #C هم قبل از اینکه به کار روی #C مشغول بشه، روی کامپایلر جاوا مایکروسافت و ماشین مجازی اختصاصی آن کار میکرده، پس طبیعی هست که بعد از این همه سال و اون همه تجربه طراح #C در حوزه جاوا، نقاط ضعف و قوت جاوا برای وی و تیمش عیان بوده باشند. در #C سعی شده که از نقاط قوت جاوا بهره برداری بشه، و از نقاط ضعفش پرهیز بشه. پس این برتری ها یا روان تر بودن که در #C مطرح می کنید، لزوما به خاطر تغییر پذیری در مایکروسافت نبوده. البته این بحث درباره برتری یک زبان بر زبان دیگه نیست، بلکه درباره علت وجود برخی نقاط قوت و ضعف در یک زبان نسبت به یک زبان دیگه هست.

[A.Karimi]

مکانیزم های lock در #C و synchronized در جاوا هر دو از Monitors استفاده می کنند، و از این لحاظ #C برتری خاصی نسبت به جاوا نداره. از نظر کتابخانه های مربوط به Parallel Computing، فرق جاوا با #C در این هست که برای #C به جز شرکت مایکروسافت، بازیگر بخصوصی وجود نداره، و مایکروسافت خودش این ابزارها رو معمولا تهیه میکنه، ولی در جاوا بازیگران گسترده تر هستند، و معمولا برنامه نویس باید از بین چند انتخاب موجود بهترین گزینه برای کار خودش را انتخاب کنه.

قدرت یک زبان فقط به توانایی انجام یک یا چند کار نیست. بلکه از خوانایی تا سرعت کد نویسی و Performance اجرا در آن اهمیت دارد. همانطور که ملاحظه می‌کنید در جداول مقایسه‌ای بین #C و Java موارد متفاوتی از نظر زبانی بررسی شده است. این مورد فقط درباره Synchronization نیست. در مورد کتابخانه‌های موجود برای Java حق با شماست کما اینکه بنده معتقد هستم متاسفانه برنامه‌نویسان تنبل در وادی محصولات مایکروسافت بیشترند و معمولاً دنبال محصولات و روشهای از پیش آماده هستند که بر روی اجتماع دات نت کمی اثر گذاشته‌اند. اما نباید طرفداران ALT.NET که انصافاً بسیار فعال هستند را نا دیده بگیرید. پروژه‌هایی مثل NHibernate و iTextSharp شاید در ابتدا یک ترجمه از روی نسخه Javaی آنها بودند ولی اکنون و در آینده حرفی برای گفتن خواهند داشت. در هر صورت این انتخاب شماست که از ابزارهای Community استفاده کنید و یا از ابزارهای معمولاً توکار مایکروسافت. و یا حتی خودتان برای خوتان ابزار بسازید.

خیلی بحث تغییرات مکرر مایکروسافت در جهتگیری هاش در حوزه توسعه نرم افزار درش دخیل نیست. جاوا حداقل یک دهه قبل از #C عرضه شده، و طراح #C هم قبل از اینکه به کار روی #C مشغول بشه، روی کامپایلر جاوا مایکروسافت و ماشین مجازی اختصاصی آن کار میکرده، پس طبیعی هست که بعد از این همه سال و اون همه تجربه طراح #C در حوزه جاوا، نقاط ضعف و قوت جاوا برای وی و تیمش عیان بوده باشند. در #C سعی شده که از نقاط قوت جاوا بهره برداری بشه، و از نقاط ضعفش پرهیز بشه. پس این برتری ها یا روان تر بودن که در #C مطرح می کنید، لزوما به خاطر تغییر پذیری در مایکروسافت نبوده. البته این بحث درباره برتری یک زبان بر زبان دیگه نیست، بلکه درباره علت وجود برخی نقاط قوت و ضعف در یک زبان نسبت به یک زبان دیگه هست.

در همان لینکی که درخصوص تفاوت Java و #C ارائه شد به کرات به محافظه کار بودن طراحان و نگهدارندگان زبان Java اشاره شده است که البته یک مثال از شرکتهای اینچنینی است. البته که گروه طراحان #C مخصوصاً Anders Hejlsberg به جز مطالعه جاوا، Object Pascal و ... را هم مطالعه کرده و یا در طراحی آنها فعال بوده‌اند و بعد از رفع ایرادات اقدام به طراحی زبان جدید کرده‌اند. بله بنده این موارد را قبول دارم اما شدیداً بر این موضوع تاکید دارم که چابکی و تغییرات ناگهانی یکی از مهمترین دلایل زنده بودن شرکت بزرگی مثل مایکروسافت است و مقایسه این دو زبان به عنوان تشبیهی برای دو شرکت که یکی محافظه کارتر و دیگری خطرپذیرتر است بیان شد.

همانطور که عرض کردم در علم مهندسی نرم‌افزار امروز «چابکی»، «تکرار»، «تغییر» و از این قبیل اهمیتی بیش از پیش دارد. مایکروسافت عادت دارد محصولات جدید را با شتاب ارائه کند و البته مشاهده باگها و موردهای اینچنی در اینگونه محصولاتش عادت همه ما شده شاید به نظر ما برنامه نویسان خوش نیاید، اما به نظر می‌رسد که این روش ارائه محصول بهتر، کم هزینه‌تر و در زمان کمتری به جواب می‌رسد و تغییر سیاستها راحتتر است.
کسانی که دوست ندارند در برخی از پیچ و خم های اجباری سیاست‌های کسب کار نرم‌افزار گرفتار شوند و تحمیل‌های اینجنینی را بچشند، می‌توانند به جای استفاده از تکنولوژی‌های Cutting Edge از تکنولوژی‌های مسن‌تر با خیال آسوده‌تر استفاده کنند و مدتی را تا مشخص شدن اوضاع صبر کنند. اما به نظر من در دنیای امروز این کار پر خطرتر است!

[vcldeveloper]

بله بنده این موارد را قبول دارم اما شدیداً بر این موضوع تاکید دارم که چابکی و تغییرات ناگهانی یکی از مهمترین دلایل زنده بودن شرکت بزرگی مثل مایکروسافت است و مقایسه این دو زبان به عنوان تشبیهی برای دو شرکت که یکی محافظه کارتر و دیگری خطرپذیرتر است بیان شد.

برخلاف شما، من مایکروسافت رو یک شرکت چابک و ریسک پذیر نمیدونم، اتفاقا در اکثر مواقع مایکروسافت بسیار محافظه کار و کند هست. همین مسئله رو می تونید در سیاستگذاری های کلی این شرکت و حرکت بسیار کندش به سمت موبایل و تبلت (فقط یکی از موارد ببینید). به طوری که الان ارزش سهام شرکت مثل اپل که رقیب دیرینه این شرکت بود، و مدت ها بود بازارش به واسطه فروش PC و ویندوز محدود شده بود، الان در حد ارزش سهام شرکت های نفتی هست. همین عدم ریسک پذیری و کند بودن مایکروسافت در مواجه اش با گوگل هم کاملا مشهود بود. مایکروسافت اگر دیر بجنبه، تبدیل میشه به IBM دهه اواخر دهه 90 میلادی.

درباره تغییرات در زبان های برنامه نویسی، وضع جاوا با #C خیلی فرق میکنه؛ جاوا سابقه اش از #C خیلی بیشتره و استفاده از آن هم به نسبت #C بسیار گسترده تر هست. از طرف دیگه، هر چند شرکت Oracle (و قبل از آن Sun)، وظیفه اصلی توسعه جاوا را برعهده دارند، ولی وجود چندین شرکت تکنولوژی بزرگ مثل IBM که سرمایه گزاری های عظیمی در جاوا کردند هم در سیاستگذاری های جاوا دخیل هست. همچنین، Oracle برخلاف مایکروسافت به تنهایی مالک هیچ سیستم عامل با کاربرد گسترده ایی نیست (فقط سولاریس). مایکروسافت مالک پر کاربرد ترین سیستم عامل دنیا ست. خودش هم تنها توسعه دهنده #C هست، و تغییرات در زبان #C هم اثر گزاری به گستردگی اثر گزاری یک تغییر در جاوا نداره؛ در نتیجه مایکروسافت دستش بسیار باز تر هست. اگر مایکروسافت تغییری را اعمال کنه، شما به عنوان برنامه نویس ناچار به قبول آن تغییر هستید، چون ریش و قیچی دست مایکروسافت هست، میگه این پلت فرم من هست، پر استفاده ترین سیستم عامل جهان هم هست، اگر میخواید براش برنامه بنویسید و ازش پول در بیارید، راهش همینه که من میگم! دوست نداری، به سلامت! این هست که برنامه نویسان مایکروسافتی همیشه باید دنبال مایکروسافت بدوند. نمونه جالبش همین خبر چند هفته اخیر درباره پشتیانی از ODBC در نسخه های آینده SQL Server هست؛ سالیان سال هست که مایکروسافت داره گلو خودش رو پاره میکنه که ODBC یک تکنولوژی منسوخ شده است، سرعتش پایینه، امکانات نداره، و برنامه نویسان باید ازش دوری کنند، و به OLE DB رو بیارند. اما جدیدا نظر مایکروسافت تغییر کرده، میگه نسخه آینده SQL Server آخرین نسخه ایی خواهد بود که از OLE DB پشتیبانی میکنه، و بعد از این SQL Server فقط از ODBC پشتیبانی خواهد کرد! همه چیز دست خودشه، شما وزنه خاصی ندارید. همین مسئله رو در سایر تغییرات مایکروسافتی هم می بینیم، یک روز می گفت اصلا Native Code رو دیگه فراموش کنید، فقط دات نت، اصلا ویستا که بیاد، ما دات نت رو در ویندوز یکپارچه می کنیم. بعدا معلوم شد که یکپارچکی دات نت فقط در حد نصب دات نت فریم ورک به صورت پیش فرض روی ویندوز هست. الان هم که برای ویندوز 8 دوباره داره برای Native Code بازار گرمی میکنه. COM هم همینطور؛ COM قرار بود همه چیز رو کن فیکون کنه، دیدن اینقدر پیچیده هست که همه به نوعی سعی دارند ازش فرار کنند، گفتن دات نت که بیاد، عصر COM تموم میشه. دات نت هم اومد، خبری نشد. الان هم که در ویندوز 8 رابط گرافیکی Metro مبتنی بر COM بنا شده. در هر حال مایکروسافت در حوزه سیستم عامل خودش فعالیت میکنه و به شدت هم در این زمینه انحصار طلبانه رفتار میکنه، پس این اعمال تغییرات در #C یا سایر تکنولوژی های مایکروسافتی رو نمیشه چندان به چابک بودن و ریسک پذیر بودن این شرکت مرتبط دونست. از مایکروسافت انحصار طلب تر میخواید، اپل! اپل به زور زبان برنامه نویسی عهد عتیق خودش (Objective-C) رو به خورد برنامه نویس ها میده، اجازه نصب برنامه روی آیفن یا آیپد خودتون رو بدون دریافت مجوز از این شرکت بهتون نمیده، کل نرم افزارهای ارسالی برای فروشگاه اپل را بررسی میکنه، و در صورتی که با سیاست های این شرکت تعارض داشته باشند، از API های تایید نشده این شرکت استفاده کرده باشند، یا مستقیما با بعضی محصولات اپل در رقابت باشند، اونها رو حذف میکنه. در آخر هم میگه، همینه که هست؛ آیفن پر فروش ترین موبایل دنیا، آیپد هم پر فروش ترین تبلت دنیا ست. دوست دارید ازش پول در بیارید، این روش من هست، اگر خوشتون نمیاد، به سلامت! البته مایکروسافت هم احتمالا با عرضه ویندوز مارکت در ویندوز 8، به تدریج به همین سمت حرکت خواهد کرد.

در هر حال، از نظر من، تغییرات در محصولات انحصاری بر روی یک پلت فرم انحصاری رو نمیشه با تغییرات در یک نرم آفزار آزاد روی پلت فرم های مختلف مقایسه کرد، و به این نتیجه رسید که اولی چابک هست و دوی محافظه کار. نیاز به بررسی پارامترهای بیشتری هست.