C# یا ++C؟

[aryasoft2872]

با سلام

این تاپیک رو ایجاد کردم تا دوستان بیان نظرشون رو درباره دوتا زبان بگن البته زبان C++ که شناخته شده است و قابلیت ها و توانایی هاش هم معرف حضور هست (و البته سختی و پیچیدگی اش) حالا می خواستم ببینم آیا سی شارپ هم می تونه جایگزین مناسبی برای این زبان باشه یانه؟و اصلا سی شارپ ارزش یاد گرفتن داره یا نه؟

به طور ضمنی اگه دوستان بگن آیا ممکنه که مستقیما از وی بی به سی پلاس پلاس نقل مکان کنم یا نه؟
(اگه سوالم همچین مسخره است ببخشید دیگه چون راستش به جز VB6 در مورد زبان های دیگه اطلاعاتی ندارم)

با تشکر

[Open-Source]

به قدرت C++ شک نکن.
آره، میتونی از VB به C++ نقل مکان کنی[کلا کسی که یه زبونی رو بلده خیلی راحت میتونه یه زبون دیگه رو هم یاد بگیره](ولی ممکنه دیوونه بشی، چون با یه زبون ویژوال و ساده که همه چیش آماده بوده کار کردی، ولی توی C++ خودت همه کاره هستی).
cs , cpp قابل مقایسه با هم نیستند.

[a_aryanfar85]

سلام:
زبان ++c یک زبان سیستمی ،آموزشی و .... هست که مزایای زیادی داره از جمله ارتباط بهتر با سخت افزار و اجرای سریعتر . زبان #C که یک زبان فوق العاده پیشرفته و به نظر من راحت هست ولی بیستر یک زبان تجاریه.

[saleh.hi.62]

ببین دوست عزیز باید ببینی دنبال چی هستی؟
اگه میخای برای ویندوز و لینوکس و مک برنامه بنویسی و هر چیزی که به ذهنت میرسه به سختی یا به سادگی پیاده سازی کنی C++ گزینه خوبی . اما اینم بگم که تو این راه باید صبور باشی !

ولی C# و دات نت امکانت زیادی رو عرضه میکنن که برنامه نویسی رو اسان میکنه ولی فقط روی windows به خوبی هم جواب میده .

نمیخوام ذهنت رو به هم بریزم ولی اگه میخوای C# رو کار کنی به نطر من java بهتره .
این زبان و امکاناتی که داره باعث شده برای سالیان متوای زبان اول دنیا باشه .اینو توی اینترنت ببینین.

[East.Tiva]

اصولا نمی تونی یک زبان پیدا کنی که توی همه چیز خوب جواب بده.
cpp توی کارهای سیستمی خوب جواب می ده اما نوشتن یک برنامه تجاری واقعا پیرت می کنه !!! برعکس c# توی نوشتن یک برنامه تجاری راحتت میکنه اما توی برنامه سیستمی یه خورده اذیتت می کنه .
(طبیعی هم هست، اگر درس طراحی زبان را گذرانده باشید، می دونید که وقتی می خوان یک زبان رو طراحی کنن اول مشخص می کنن که برای چه منظوری باید باشه و بعد بر همون اساس قابلیت های زبان را طراحی می کنند.)
بنابراین بهتره که همه اینها رو بلد باشی و از هر زبانی در موقع خودش استفاده کنی. مثلا اگر یک پروژه سیستمی به پستت خورد، باید بری سراغ cpp ولی اگر یک پروژه تجاری به پستت خورد، میری سراغ c#.

جاوا هم بد نیست هرچند که اون هم جوابگوی همه نیازها نیست و باید در موارد خودش از اون استفاده کنی. (پس خیلی تفاوتی با c# نمی کنه)

[PC2st]

با زبان سی‌شارپ شما یک برنامه‌نویس وابسته به مایکروسافت هستی.
با زبان ++C یا پایتون یا ... شما یک برنامه‌نویس مستقل هستی.

[silverfox]

خیلی وقتا این وابستگی و پشتیبانی باعث تسهیل و تسریع کارها می شه و امکانات خوبی در اختیارتون می ذاره...

[مرتضی پیروزی]

توی کارهای سیستمی خوب جواب می ده اما نوشتن یک برنامه تجاری واقعا پیرت می کنه !!! برعکس C#‎ توی نوشتن یک برنامه تجاری راحتت میکنه اما توی برنامه سیستمی یه خورده اذیتت می کنه .
سلام
اولاً که بیشترین نرم افزارهایی که ما با اونا سروکار داریم با C++/C نوشته شدند!! این دلیلی بر اینکه پیرت نمیکنه! دوماً که منطق جالبی دارید! ++C پیرت میکنه ولی #C توی کارای سیستمی یه خورده اذیت میکنه!!
جالب بود!

[eshpilen]

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

[PC2st]

بهرحال میکروسافت هم مسیر قطعی ای رو در پیش گرفته و ظاهرا در آینده همه چیز رو بر مبنای سی شارپ و دات نت ارائه میکنه و معلوم نیست فناوریهای قدیمی تر پشتیبانی کافی داشته باشن (میگن دیگه نمیخواد بعضیاش رو داکیومنت بکنه).
البته که «اساس دات نت» بر اساس همین «فناوری‌های قدیمی» شکل گرفته و بنا شده...
در پشت پردهٔ دات نت، از Windows API و زبان nativeای به نام ++C استفاده شده...
حتی این XNA هم در ویندوز یک لایهٔ اضافی بر روی DirectX است.
و سوال اینجاست که آیا مایکروسافت حاضر می‌شه اساس خودش Windows API را نابود کنه؟
دات نت برای جایگزینی ++C نیامده... بلکه یک مکمل در کنار روش‌های قدیمی است.

[eshpilen]

البته که «اساس دات نت» بر اساس همین «فناوری‌های قدیمی» شکل گرفته و بنا شده...
در پشت پردهٔ دات نت، از Windows API و زبان nativeای به نام ++C استفاده شده...
حتی این XNA هم در ویندوز یک لایهٔ اضافی بر روی DirectX است.
و سوال اینجاست که آیا مایکروسافت حاضر می‌شه اساس خودش Windows API را نابود کنه؟
دات نت برای جایگزینی ++C نیامده... بلکه یک مکمل در کنار روش‌های قدیمی است.
بله درسته.
اما مسئله در حیطهء خاصی هست بنام اپلیکیشن نویسی.
مثلا وقتی مایکروسافت یک widget جدید رو برای رابط گرافیکی اپلیکیشن ها ایجاد میکنه ممکنه عملا در دات نت پشتیبانی و داکیومنت و ساختار خیلی بهتری برای استفاده داشته باشه یا اصلا به کتابخانهء Native اضافه نشه.
همینطور جزییات و پیچیدگی های دیگر هم هستن.
شاید در آینده میکروسافت دیگه در بهینه سازی و گسترش فناوری اپلیکیشن نویسی ویندوز بر مبنای Win API مثل MFC و غیره کار نکنه و این درحالی باشه که فناوریها و فریمورک های جدید گسترده تری برای دات نت بیاد. در اینصورت دیگه موقعیت یک برنامه نویس سی++ عملا عقب افتاده تر خواهد شد.

[saleh.hi.62]

ببینید یه کم اگه با دید بازتری نگاه کنیم ! میبینیم که تو کشور ما که دات نت و ویندوز همش رو هم 1000 تومان ! خوب همه با ویندوز کار کردن و کار هم میکنن و بهترین برای برنامه نویسی دات نت ولی اگه به فکر کار روی سیستم عامل های دیگه باشیم دیگه اینجوری فکر نمیکنیم.اون وقت میبینین که c++ هنوز هم بهترین ربان برای توسعه نرم افزاری روی linux,mac البته به کمک QT Framework برنامه نویسی برای c++ هم خیلی ساده شده .

[eshpilen]

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

[eshpilen]

خود شما بری یجا بخوای استخدام بشی و سی شارپ و دات نت کار بخوان چیکار میکنی؟
بخصوص اگر حالت تیمی باشه که دیگه هیچ انتخاب دیگه ای باقی نمیمونه. چون توی یه شرکت مثلا با 5 نفر برنامه نویس مسلما زبان انتخاب شده به احتمال زیادتر از همه سی شارپ و دات نت خواهد بود. غیر از اینه؟
بنظر شما آیا الان یه شرکت نرم افزاری تازه تاسیس که میخواد تیم برنامه نویسی داشته باشی میاد روی فریمورک و زبان دیگری سرمایه گذاری بکنه؟
منطقی هست که اونا میرن دنبال جدیدترین فناوری که برنامه نویسش زیاد هست و آینده و ساپورتش هم مشخصه و چیز استانداردی محسوب میشه.

[yasemi]

کاملا موافقم اگه یه نگاه به روزنامه بندازید می بینید که پر شده از استخدام کسی که #C و جدیدنم اوراکل بلدند درسته که ++C یه زبان قدرتمنده اما باید به فکر درامد هم بود الان داخل دانشگاه هم تقریبا همه استادا پرژه رو با #C تو اولویت میزارن

[East.Tiva]

سلام
اولاً که بیشترین نرم افزارهایی که ما با اونا سروکار داریم با C++‎‎‎/C نوشته شدند!! این دلیلی بر اینکه پیرت نمیکنه! دوماً که منطق جالبی دارید! ++C پیرت میکنه ولی C#‎‎‎ توی کارای سیستمی یه خورده اذیت میکنه!!
جالب بود!

اولا، اینکه اکثر نرم افزارهای دور و بر ما با ++C نوشته شده اند دلیل بر راحت بودن این زبان نیست! دلیل نمیشه که آدم رو پیر نکنه

دوما، آره چرا که نه، نمی دونم با C#‎‎ کارهای سیستمی یا پردازش های سنگین انجام دادید یا نه ولی همین رو میگم که به همون نسبت که نوشتن یک برنامه تجاری توی C#‎‎ آسونه، انجام کارهای پیچیده و سنگین هم آسونه فقط سرعت اجرای پایین تری دارند. (مثال: مثل WMI برای کار کردن با سخت افزارها در Net. و یا پردازش تصویر در C#‎‎ ... )

[PC2st]

دوست عزیز، سی‌شارپ یک زبان سیستمی نیست.

[saleh.hi.62]

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

دوست عزیز شما یه سفارش کار دریافت میکنی درسته ؟ خوب اونو چه با جاوا چه با سی شارپ و چه با C++‎‎‎(QT framework بنویسی فرقی نمیکنه !!! مشتری برنامه رو میخواد که کار کنه و دزست جواب بده .

اگه من از دیگر سیستم عامل ها صحبت کردم به خاطر اینه که وقتی رو که صرف میکنیم برای یادگیری چیزی چند منظوره باشه و نه فقط برای یک سیستم عامل و فقط برای یک سری زمینه های خاص.

برای مثال : یکی از بزرگترین پروژه های ایران که بدستور وزارت اموزش و پرورش آغاز به کار شده ! یکی از اعضای این تیم دوست خود من .
پروژه داره برای windows application با QT نوشته میشه و برای web application با پایتون و فریمورک Django و سیستم عامل هم linux هست.

و دستمزدی هم که در نهایت میگیرن به احتمال زیاد یک رقم نجومی ! چون پروژه سنگینی !

[eshpilen]

دوست عزیز شما یه سفارش کار دریافت میکنی درسته ؟ خوب اونو چه با جاوا چه با سی شارپ و چه با C++‎‎‎‎(QT framework بنویسی فرقی نمیکنه !!! مشتری برنامه رو میخواد که کار کنه و دزست جواب بده .

آره در همچین مواردی میشه.
اما بازم اینکار یه ریسک ها و دردسرهایی داره. به امنی و آسونی نوشتن برنامه با سی شارپ نیست. این تاپیک رو بخونید باید متوجه بشید چرا: http://barnamenevis.org/forum/showthread.php?t=225430
از طرف دیگه بعضی مشتری ها ممکنه به عللی، زبان برنامه نویسی رو مشخص کنن.


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


برای مثال : یکی از بزرگترین پروژه های ایران که بدستور وزارت اموزش و پرورش آغاز به کار شده ! یکی از اعضای این تیم دوست خود من .
پروژه داره برای windows application با QT نوشته میشه و برای web application با پایتون و فریمورک Django و سیستم عامل هم linux هست.

و دستمزدی هم که در نهایت میگیرن به احتمال زیاد یک رقم نجومی ! چون پروژه سنگینی !

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

[Mehdi Asgari]

برای مثال : یکی از بزرگترین پروژه های ایران که بدستور وزارت اموزش و پرورش آغاز به کار شده ! یکی از اعضای این تیم دوست خود من .
پروژه داره برای windows application با QT نوشته میشه و برای web application با پایتون و فریمورک Django و سیستم عامل هم linux هست.
سعی کن کم تر مثل روزنامه نویسا حرف بزنی. اینجا فروم تخصصیه و حداقل احتمال بده که کسانی هستن که شاید در مورد این پروژه اطلاعاتی دارن و تصادفا پروژه های بزرگ هم در عمرشون دیدن و هم روی پروژه های بزرگ کار کردن
ایضا:

به احتمال زیاد یک رقم نجومی ! چون پروژه سنگینی

[saleh.hi.62]

آره در همچین مواردی میشه.
اما بازم اینکار یه ریسک ها و دردسرهایی داره. به امنی و آسونی نوشتن برنامه با سی شارپ نیست. این تاپیک رو بخونید باید متوجه بشید چرا:

http://barnamenevis.org/forum/showthread.php?t=225430
دوست عزیزی که این مطالب رو نوشته بود یک جاهای جق به جانب ایشون بود و یک سری جاها نه ! بهتره که جواب هایی که دیگر دوستان متخصص هم تو این زمینه در ادام اون تاپیک مطرح کردن رو هم بت دقت بخونین . به خیلی هاش پاسخ داده شد.


سعی کن کم تر مثل روزنامه نویسا حرف بزنی. اینجا فروم تخصصیه و حداقل احتمال بده که کسانی هستن که شاید در مورد این پروژه اطلاعاتی دارن و تصادفا پروژه های بزرگ هم در عمرشون دیدن و هم روی پروژه های بزرگ کار کردناگه شما در این مورد اطلاع کافی دارین میتونم بپرسم توی این پروژه قرار چه کاری انجام بگیره؟
من اگه چیزی گفتم همین تور که گفتم یک از دوستان من از اعضای این تیم !

بعدشم این طرز برخورد اصلا جالب نیست ! من یک مثال رو مطرح کردم ! به کس خاصی توهین شد ؟

[Mehdi Asgari]

اگه شما در این مورد اطلاع کافی دارین میتونم بپرسم توی این پروژه قرار چه کاری انجام بگیره؟
من اگه چیزی گفتم همین تور که گفتم یک از دوستان من از اعضای این تیم !

بعدشم این طرز برخورد اصلا جالب نیست ! من یک مثال رو مطرح کردم ! به کس خاصی توهین شد ؟
نخیر نمی تونید ، ربطی به فروم نداره.
دقیقا توهین هست به خوانندگان مطالب شما.
شما معنی کلماتی چون "رقم نجومی" و "پروژۀ بزرگ" رو نمی دونی چون پروژۀ بزرگ ندیدی؛ البته این به معنای کوچک کردن ارزش کار این دوستان نیست ، ولی مفهومی مثل "بزرگی" یا زیاد بودن رقم یا ارزش مالی پروژه ، نسبی هست. مثلا کار دوستان در مقایسه با یک برنامۀ حسابداری ساده ، پروژه ای بزرگ و گران قیمت هست ، ولی در مقایسه با خیلی از پروژه های بزرگ انجام شده در ایران (یا پروژه های بسیاری که الان در حال توسعه هستن و بنده در جریانشون هستم) کار خیلی کوچکیه (البته من از مقدار دقیق قرارداد! دوستان اطلاع ندارم ولی اون هم قابل تخمین هست)
من با مثالی که زدی مشکلی ندارم ، با طرز روایتت مشکل دارم {به هر حال این تاپیک جای بحث این موارد نیست. فقط خواستم تذکری داده باشم }
موفق باشی

[eshpilen]

دوست عزیزی که این مطالب رو نوشته بود یک جاهای جق به جانب ایشون بود و یک سری جاها نه ! بهتره که جواب هایی که دیگر دوستان متخصص هم تو این زمینه در ادام اون تاپیک مطرح کردن رو هم بت دقت بخونین . به خیلی هاش پاسخ داده شد.

استارتر اون تاپیک که بنده هستم :لبخند:
اونجا پستهای دوستان رو خوندم و جوابشون رو دادم.
شما اگر ادعا دارید چیزی جاهلانه بوده با دلیل بیان بفرمایید که چرا و بتونیم روش بحث کنیم. اگر نظر شما مستدل باشه من میپذیرم.
اما بحث این نیست که من ندونم کیوت رابط کاربری رو درست میکنه و بقیش رو با کتابخانه های دیگه باید ساخت، که البته باید بگم این حرف کاملا نادقیق هست و کیوت امکاناتی خیلی بیشتر از GUI هم داره.
موضوع اصلی اینه که حالا که در یک برنامهء بزرگ در حال یا آینده ما ممکنه نیاز به ترکیبی از Qt و کتابخانه های دیگه و بخصوص کتابخانه های بومی پیدا بکنیم، و اینکار درمقایسه با برنامه های بومی خالص چندان بی دردسر هم نیست، آیا مزایای اصلی کیوت خدشه دار نمیشن و دیگه چه دلیلی داره دو یا چند کتابخانه و فریمورک رو یاد بگیریم و با هم ترکیب کنیم و چرا نریم از ابتدا مثلا کتابخانه و زبانهای بومی خود ویندوز رو یاد بگیریم و استفاده کنیم که باعث انسجام کدها و استفاده کامل از راحتی و امکانات فریمورک و کم شدن کار یادگیری و برنامه نویسی میشه.
البته خیلی از برنامه ها رو میشه با Qt هم بصورت کامل پیاده کرد. اما بهرصورت اون نیازها و انتظاراتی هم که گفتم برای من عملا پیش آمده و نادر و غیرمنطقی نیستن. من فکر میکنم اگر برنامه ای نوشتم و در آینده مشتری نیاز داشت یک امکان خاص رو بهش اضافه کنم که کیوت تامین نمیکنه، چقدر ممکنه برای من دردسر بشه و اگر بخوام اون کار یا میزان دستمزدش رو بخاطر کم بودن رد کنم، باید چی به مشتری بگم!
آدم دوست داره با چیزی برنامه بنویسه که هروقت خواست بتونه هر گسترشی رو بدون دردسر و هزینهء اضافه بهش اعمال کنه و کار اولیه مخدوش نشه. هرچند همینطور آدم دوست داره از فناوریهای بازمتن/آزاد و مستقل از پلتفرم استفاده کنه، و بنابراین ما یک تعادل و نسبی بودن رو در تصمیمگیری ها شاهد هستیم. من شخصا ممکنه برنامه های موردی و کوچک یا حتی متوسط رو یا اونایی رو که میدونم ذاتا از امکانات خاصی که در کیوت نیست استفاده نخواهند کرد، با کیوت درست کنم. بخصوص که یک پروژهء بازمتن باشه. البته حتی اگر بازمتن هم نباشه بازم این مزیت که میتونه روی لینوکس هم براحتی منتقل و اجرا بشه بالاخره خاصیت مطلوبی هست.

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

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

[saleh.hi.62]

نخیر نمی تونید ، ربطی به فروم نداره.
دقیقا توهین هست به خوانندگان مطالب شما.
شما معنی کلماتی چون "رقم نجومی" و "پروژۀ بزرگ" رو نمی دونی چون پروژۀ بزرگ ندیدی؛ البته این به معنای کوچک کردن ارزش کار این دوستان نیست ، ولی مفهومی مثل "بزرگی" یا زیاد بودن رقم یا ارزش مالی پروژه ، نسبی هست. مثلا کار دوستان در مقایسه با یک برنامۀ حسابداری ساده ، پروژه ای بزرگ و گران قیمت هست ، ولی در مقایسه با خیلی از پروژه های بزرگ انجام شده در ایران (یا پروژه های بسیاری که الان در حال توسعه هستن و بنده در جریانشون هستم) کار خیلی کوچکیه (البته من از مقدار دقیق قرارداد! دوستان اطلاع ندارم ولی اون هم قابل تخمین هست)
من با مثالی که زدی مشکلی ندارم ، با طرز روایتت مشکل دارم {به هر حال این تاپیک جای بحث این موارد نیست. فقط خواستم تذکری داده باشم }
موفق باشی

تذکری که دادید کاملا بی ربطه ! به چند دلیل :
1-این جور که به نظر میاد از جزئیات کامل پروژه اطلاع کامل ندارید !

2-پروژه های بزرگی انجام شده و انجام میشه و خواهد شد ! اینم یکی از اوناست ! من نگفتم بزرگتیرین پروژه در حال اجرا در تاریخ ایران !! فقط گفتم پروژه بزرگی .
اگه به مزاج شما خوش نیومده پای دیگران رو وسط نکشین !

3-اینجا (این وبسایت) فروم تخصصی ! قبول . ولی این بخش گفتگوی آزاد و از تالارهایی که بحث تخصصی دارن در مورد یک موضوع خاص سواست . پس شما بهتره که به این ستاره هایی که روی پیشونیتون بستین ننازین و اگه دوست ندارین توی این بخش شرکت نکنین .
(تخصص زدگی هم یک مد جدید که به تازگی ظهور کرده و بعضی ها با این کلمه به خودشون اجازه میدن هر چی که خواست بگن !!!!)

باید یک تجدید نظر در مورد دادن اختیارات به افراد صورت بگیره (داشتن تخصص تنها ملاک مدیر شدن نیست !!!) یکی از مشخصه های بارز یک مدیر ریز ادب و درایت !

[Mehdi Asgari]

مسئلهء دیگه اینه که اگر اون بخشهای دیگه بازمتن نباشن دیگه برنامهء من بازمتن نیست
کیوت لایسنس LGPL هم داره. یک برنامه که proprietary هست می تونه از Qt استفاده کنه بدون این که مجبور باشه سورس کد خودش رو هم عرضه کنه.
http://qt.nokia.com/products/licensing/


This version of Qt is appropriate for the development of Qt applications (proprietary or open source) provided you can comply with the terms and conditions contained in the GNU LGPL version 2.1.
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License


The main difference between the GPL and the LGPL is that the latter can be linked to (in the case of a library, 'used by') a non-(L)GPLed program, regardless of whether it is free software or proprietary software.[1] This non-(L)GPLed program can then be distributed under any chosen terms if it is not a derivative work. If it is a derivative work, then the terms must allow "modification for the customer's own use and reverse engineering for debugging such modifications." Whether a work that uses an LGPL program is a derivative work or not is a legal issue. A standalone executable that dynamically links to a library is generally accepted as not being a derivative work (in LGPL). It would be considered a "work that uses the library" and paragraph 5 of the LGPL applies.

A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

[saleh.hi.62]

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

دوست عزیز جناب eshpilen (http://barnamenevis.org/forum/member.php?u=148005)
شما بهتر از من میدنید که هنوزه که هنوزه بهترین زبان برای توسعه نرم افزار نه تنها برای windows بلکه برای linux , mac در اکثر جاهای که واقعا نرم افزار مینویسن C++ هست!
شما داری از فریمورک QT استفاده میکنی و در کنارش زبان قدرتمند C++ حضور داره . من دلیل نگرانی شما رو نمیتونم بفهمم !!!

[...StacK...]

نخیر نمی تونید ، ربطی به فروم نداره.
دقیقا توهین هست به خوانندگان مطالب شما.
شما معنی کلماتی چون "رقم نجومی" و "پروژۀ بزرگ" رو نمی دونی چون پروژۀ بزرگ ندیدی؛ البته این به معنای کوچک کردن ارزش کار این دوستان نیست ، ولی مفهومی مثل "بزرگی" یا زیاد بودن رقم یا ارزش مالی پروژه ، نسبی هست. مثلا کار دوستان در مقایسه با یک برنامۀ حسابداری ساده ، پروژه ای بزرگ و گران قیمت هست ، ولی در مقایسه با خیلی از پروژه های بزرگ انجام شده در ایران (یا پروژه های بسیاری که الان در حال توسعه هستن و بنده در جریانشون هستم) کار خیلی کوچکیه (البته من از مقدار دقیق قرارداد! دوستان اطلاع ندارم ولی اون هم قابل تخمین هست)
من با مثالی که زدی مشکلی ندارم ، با طرز روایتت مشکل دارم {به هر حال این تاپیک جای بحث این موارد نیست. فقط خواستم تذکری داده باشم }
موفق باشی

حقیقتا همینطوره...

به کار بردن کلماتی چون "پروژه بزرگ" -"رقم نجومی" بدون اینکه ذره ای مباحث علمی و فنی به همراه داشته باشه و صرفا نقل قول باشه .... به معنای واقعی کلمه ,شخصیت خواننده رو زیر سوال میبره...

چون این مطلب بدون توجه به مخاطب و اینکه در چه سطحی باشه ,داره بزرگ بودن پروژه رو به اون تحمیل و بدنبال اون تحقیر مخاطب میشه.

[PC2st]

بازمتن --> متن‌باز :چشمک:


البته تمام اینا که گفتم به معنای کم شدن ارزش و کاربرد Qt نیست. من خودم به دلایلی که قبلا گفتم دنبال کیوت و چند زبان دیگر بازمتن و مستقل از پلتفرم رفتم و استفادش رو هم برده و میبرم و احتمالا خواهم برد. اما اگر دیدگاه صرفا بازاری و جهت شغل و درآمد و انجام پروژه های بومی ویندوز باشه، بنظر من یک چیزی مثل سی شارپ و دات نت گزینهء تقریبا بی رقیبی هست یا در آینده خواهد بود (در حال حاضر سی++ با کتابخانه های بومی خود ویندوز مثل MFC هم کاملا کاراست). البته برای من عجیب است که چطور بعد از عدم موفقیت در استفاده از Qt نتیجه گرفتید که زبان سی‌شارپ بعلاوه کتابخانهٔ NET. به استفاده از ++C ارجحیت دارد؟ من زمانیکه می‌خواستم بین Qt و Gtk یکی را انتخاب کنم (برای برنامه‌نویسی در ++C)، از انتخاب Qt صرف‌نظر کردم چونکه Qt با استاندارد تعریف‌شده در ++C ناسازگار است (هم در syntax هم در کتابخانهٔ مورد استفاده‌اش هم در نحوهٔ کامپایل در واقع نباید تعجب کرد که چرا بعضی‌ها فکر می‌کنند Qt یک زبان برنامه‌نویسی است!).

در رابطه با مشکلی که در استفاده از کتابخانه ++cypro با Qt داشتید بعید نیست که همین ناسازگاری با استاندارد ++C دلیل ایجاد این مشکل در ترکیب‌شدن Qt با سایر کتابخانه‌ها (و فریم‌ورک‌ها) بوده باشد، البته اگر واقعا مشکلی وجود داشته است، شاید شما به روش اشتباه می‌خواستید کار مورد نظر را انجام دهید یا شاید نسخه‌های مورد استفاده بخوبی با هم match نبوده‌اند شاید و هزاران شاید دیگر تا زمانیکه دلیل اصلی این مشکل ذکر نشده است. البته نمی‌دانم از چه نسخهٔ Qt استفاده می‌کردید ولی Qt از نسخهٔ 4.5 به بعد به مراتب بهتر شده است (بر اساس گفته‌های دیگران).

در ضمن چرا برای برنامه‌نویسی در ++C حتماً باید یک framework وجود داشته باشد؟ تا جایی که می‌دانم معمولا از گردهمایی چند کتابخانه، نیازهای برنامه‌نویسی در ++C برطرف خواهد شد. در واقع من با این نوع نتیجه‌گیری شما مخالف هستم :لبخند:. خوشبختانه کتابخانه‌های زیادی برای ++C وجود دارد (نه به عنوان framework) و اینطور نیست که بگویید کار یک برنامه‌نویس ++C لنگ خواهد ماند. به عنوان آخرین کلام، شما از سی‌شارپ و دات‌نت به عنوان ابزارهای بومی ویندوز یاد کرده‌اید ولی فراموش شده که زبان ++C یک زبان بومی (native) در ویندوز است (یعنی اینکه ویندوز بدون هیچ واسطه‌ای با آن کنار می‌آید). اگر به دنبال بهانه می‌گردید که از ++C به زبان دیگری کوچ کنید، این بهانهٔ خوبی نبود :شیطان:.

[eshpilen]

کیوت لایسنس LGPL هم داره. یک برنامه که proprietary هست می تونه از Qt استفاده کنه بدون این که مجبور باشه سورس کد خودش رو هم عرضه کنه.
http://qt.nokia.com/products/licensing/

http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
اینو که میدونم.
هرچند ممکنه این امکان ها از نظر بعضی افراد مزیتی بنظر بیاد، اما از نظر من نه، چون من به برنامه های انحصاری علاقه ای ندارم و فقط بخاطر ماهیت نرم افزارهای بازمتن/آزاد بهشون علاقه دارم و این یکی از مزایای اصلی کیوت بوده که منو به خودش جلب کرده. اینکه بتونم باهاش برنامهء انحصاری هم بنویسم برای من اهمیت زیادی نداره، خصوصا که اون برنامه با اجزایی همراه باشه که گزینهء بازمتن رو به هیچ صورتی ندارن و کاملا انحصاری هستن. اگر میخواستم با کتابخانه ها و فریمورک های انحصاری کار کنم دیگه احتمالا دنبال کیوت نمیرفتم. میخوام چی بشه برنامه ای که نصفش انحصاری باشه و نصف دیگش بازمتن باشه؟ چنین برنامه ای به هیچ دردی نمیخوره از نظر من.
من گفتم بازمتن بودن یه مزیته. نگفتم توانایی نوشتن نرم افزار انحصاری یه مزیته. نگفتم اینکه بتونی از اجرای انحصاری هم در برنامه هات همراه کیوت استفاده کنی یه مزیته. و ضمنا به مشکل مجوز هم اشاره نکردم.
آیا تمام این مجوزها واقعیت رو تغییر میدن؟
واقعیت اینه که برنامهء شما دیگه بازمتن و آزاد نیست، و این رو شما انتخاب نکردید، بلکه مجبور شدید. وقتی من مجبور باشم از اجزای انحصاری در برنامم استفاده بکنم دیگه برای چی باید بازمتن بودن رو بعنوان یک معیار و مزیت درنظر بگیرم؟ برنامه ای که فقط نصفش بازمتن باشه به درد اونایی که به فلسفهء نرم افزار آزاد اعتقاد دارن نمیخوره و تقریبا انگار نه انگار که یه بخشی از اون بازمتنه. بازمتن بودن یه چیزی هست که باید کامل و خالص باشه تا مفهوم و ارزش حقیقی داشته باشه.


دوست عزیز جناب eshpilen (http://barnamenevis.org/forum/member.php?u=148005)
شما بهتر از من میدنید که هنوزه که هنوزه بهترین زبان برای توسعه نرم افزار نه تنها برای windows بلکه برای linux , mac در اکثر جاهای که واقعا نرم افزار مینویسن C++‎ هست!
شما داری از فریمورک QT استفاده میکنی و در کنارش زبان قدرتمند C++‎ حضور داره . من دلیل نگرانی شما رو نمیتونم بفهمم !!!
دوست عزیز توضیح کافی که دادم.
اصلا بحث سی++ یا سی شارپ نیست.
من میتونم با کتابخانه ها و ابزارهای انحصاری خود مایکروسافت هم روی ویندوز برنامه بنویسم. اگر مسئله فقط سی++ بودن باشه چرا کیوت رو انتخاب کنم؟ خب میرم از کتابخانه و فریمورک بومی میکروسافت تحت سی++ استفاده میکنم و دیگه خیالم راحته که همهء امکانات مورد نیاز روی ویندوز رو داره و لازم نیست چند کتابخانه و فریمورک رو یاد بگیرم و با هم ترکیب کنم.
کیوت چه مزیتی داره بر انتخاب فریمورک بومی ویندوز؟
آیا اون بازمتن بودن و مستقل از پلتفرم بودن نیست؟
خب منم همش دارم همینو میگم که روی ویندوز کیوت بقدر کافی کامل نیست که آدم رو در هر موردی از کتابخانه های انحصاری و وابسته به پلتفرم بی نیاز بکنه. هرچند شاید بگردم و برای هر نیازی یک کتابخانهء بازمتن و مستقل از پلتفرم پیدا کنم، که میتونه کار سخت و حتی غیرممکنی باشه، اما بعدش برنامهء کیوت من از ساختار فریمورک کیوت خارج میشه و یادگیری و پیوند اینهمه اجزاء باهم هزینه بر هست از نظر وقت و انرژی برنامه نویس.
هرچند من اگر بهم یک مجموعه راهکار بازمتن و مستقل از پلتفرم کامل ارائه بشه احتمالا تاحد زیادی راضی میشم. اما الان از کجا بدونم آیا برای هر نیازی میتونم روی کیوت و وجود کتابخانه های بازمتن و مستقل از پلتفرم دیگه اتکا بکنم یا نه؟ یک برنامه نویس سی شارپ یا سی++ بدون هیچکدوم از این دغدغه ها و دردسرها و هزینه ها هرکاری میخواد روی ویندوز انجام میده، اما کار من اینقدر سخت و پیچیده میشه. مثلا الان من دنبال یک کتابخانهء بازمتن و مستقل از پلتفرم میگردم که روی ویندوز بتونم باهاش با وبکم کار کنم و توی برنامه های کیوت ازش استفاده کنم (یعنی عملا بشه با widget های کیوت ترکیبش کرد). شما سراغ دارید؟
بعدشم این داستان احتمالا همیشه ادامه داره. چون میکروسافت روی سی شارپ و دات نت سرمایه گذاری کرده و مدام امکانات به اینا اضافه میکنه و من باید مدام دنبال معادل بازمتن و مستقل از پلتفرم اونا بگردم که بروز هم باشه (که اکثرا بقدر کافی نیستن).

[eshpilen]

بازمتن --> متن‌باز :چشمک:

چه فرقی میکنه حالا؟
تازه بازمتن که بهتره!
مثلا ما میگیم «سرخ رنگ»، نه «رنگ سرخ».


البته برای من عجیب است که چطور بعد از عدم موفقیت در استفاده از Qt نتیجه گرفتید که زبان سی‌شارپ بعلاوه کتابخانهٔ NET. به استفاده از ++C ارجحیت دارد؟
نه من نمیگم لزوما سی شارپ و دات نت. میتونیم از سی++ و MFC استفاده کنیم.
من دارم میگم برای برنامه نویسی روی ویندوز، اونم با درنظر گرفتن بازار کار، Qt بقدر کافی کامل نیست و بنابراین چرا باید ازش استفاده بکنیم؟ آیا امکاناتی که Qt ارائه میده برابر با کل امکاناتی که کتابخانه های بومی خود ویندوز ارائه میدن هست؟


من زمانیکه می‌خواستم بین Qt و Gtk یکی را انتخاب کنم (برای برنامه‌نویسی در ++C)، از انتخاب Qt صرف‌نظر کردم چونکه Qt با استاندارد تعریف‌شده در ++C ناسازگار است (هم در syntax هم در کتابخانهٔ مورد استفاده‌اش هم در نحوهٔ کامپایل در واقع نباید تعجب کرد که چرا بعضی‌ها فکر می‌کنند Qt یک زبان برنامه‌نویسی است!).
منکه فکر میکنم اشتباه کردید. اصلا GTK قابل مقایسه با کیوت نیست. من یک بار بصورت رقابتی با برنامه نویسان GTK، کدهای کیوت و GTK رو برای چند مثال عملی مقایسه کردم که Qt کدهاش حداقل نصف GTK بود و ساختار و خوانایی بهتری هم داشت.
Qt فقط از یکسری ابزارهای اختصاصی خودش استفاده میکنه که اونا هم بازمتن هستن و با روش غیرعادی ای که در اختیار میذاره کلی مزیت و راحتی به برنامه نویس داده. اینا کجاش بده؟


در رابطه با مشکلی که در استفاده از کتابخانه ++cypro با Qt داشتید بعید نیست که همین ناسازگاری با استاندارد ++C دلیل ایجاد این مشکل در ترکیب‌شدن Qt با سایر کتابخانه‌ها (و فریم‌ورک‌ها) بوده باشد، البته اگر واقعا مشکلی وجود داشته است، شاید شما به روش اشتباه می‌خواستید کار مورد نظر را انجام دهید یا شاید نسخه‌های مورد استفاده بخوبی با هم match نبوده‌اند شاید و هزاران شاید دیگر تا زمانیکه دلیل اصلی این مشکل ذکر نشده است. البته نمی‌دانم از چه نسخهٔ Qt استفاده می‌کردید ولی Qt از نسخهٔ 4.5 به بعد به مراتب بهتر شده است (بر اساس گفته‌های دیگران).
من از نسخه های اخیر Qt استفاده کردم.
ضمنا با ++cypro هم مشکلی نداشتم. اما کامپایل و ترکیبش با کیوت کار راحتی هم نبود و تقریبا شانسی موفق شدم. مشکل کیوت در اینجا اینه که خودش یک کتابخانهء رمزنگاری رسمی، یعنی بصورت پیشفرض نصب و کامپایل شده باشه، نداره (حداقل تا اون زمان که نداشت). مشکل دیگه اینه که نسخه ای از کیوت که با MSVC کامپایل شده باشه بصورت آماده برای دانلود وجود نداره. چون ما برای استفاده از بیشتر کتابخانه های تحت ویندوز نیاز به کیوت کامپایل شده با MSVC داریم. شاید همهء اینا قابل حل باشه و مثلا کامپایلش راحت باشه، اما به تجربهء من مشکلات عملی زیاد هست و برنامه نویس رو درگیر مسائلی میکنه که یک برنامه نویس اپلیکیشن انتظار نداره و ممکنه دانش و مهارت فنی لازم رو هم نداشته باشه.


در ضمن چرا برای برنامه‌نویسی در ++C حتماً باید یک framework وجود داشته باشد؟ تا جایی که می‌دانم معمولا از گردهمایی چند کتابخانه، نیازهای برنامه‌نویسی در ++C برطرف خواهد شد. در واقع من با این نوع نتیجه‌گیری شما مخالف هستم :لبخند:.
موضوع اینه که وقتی خود میکروسافت چنین فریمورکی رو داره که کامله (کامله یا تقریبا کامله بهرحال کاملتر از روشهای وصله و پینه ای دیگس) چرا باید از محصولات غیرمیکروسافتی استفاده کنیم؟
بعدهم این کتابخانه هایی که میگید باید دو خصیصهء بازمتن بودن و مستقل از پلتفرم بودن رو هم داشته باشن تا واقعا با کیوت بصورت کامل مچ بشن. وگرنه برنامهء ما دیگه این دو مزیت مهم رو که کیوت رو بخاطر اونا انتخاب کردیم از دست میده.


خوشبختانه کتابخانه‌های زیادی برای ++C وجود دارد (نه به عنوان framework) و اینطور نیست که بگویید کار یک برنامه‌نویس ++C لنگ خواهد ماند. به عنوان آخرین کلام، شما از سی‌شارپ و دات‌نت به عنوان ابزارهای بومی ویندوز یاد کرده‌اید ولی فراموش شده که زبان ++C یک زبان بومی (native) در ویندوز است (یعنی اینکه ویندوز بدون هیچ واسطه‌ای با آن کنار می‌آید). اگر به دنبال بهانه می‌گردید که از ++C به زبان دیگری کوچ کنید، این بهانهٔ خوبی نبود :شیطان:.

همونطور که گفتم واسه من فرقی نمیکنه. روی زبان خاصی اصرار ندارم. میتونه سی++ هم باشه و کتابخانه هایی مثل Win32 API یا MFC. اما شخصا فکر میکنم آیندهء اپلیکیشن نویسی روی ویندوز عملا برتری کیفی و کمی سی شارپ و دات نت رو شاهد خواهد بود (احتمالا بخشی از این بخاطر سیاستهای میکروسافت هم خواهد بود). بهرحال همونطور که گفتم فعلا این قضیه هنوز مطمئن و وقوع یافته نیست. اما منم روی زبان و فریمورک و فناوری خاصی اصرار ندارم. بحث مقایسهء کیوت و سی شارپ نبود، بحث مقایسهء کیوت و کتابخانه ها و فناوریهای بومی میکروسافت برای برنامه نویسی روی ویندوز بود.

[PC2st]

درسته Gtk در مقابل امکانات Qt عددی نیست ولی:
۱) برای طراحی رابط گرافیکی کاربر کافی است. برای سایر نیازها از کتابخانه‌های دیگر استفاده می‌شود.
۲) بر خلاف عقیدهٔ خیلی‌ها، ایجاد ویدجت‌های جدید در آن نیازی به صبر ایوب ندارد (Custom Widgets فقط نیاز به آگاهی و یادگیری نحوه کار Gtk و Gobject دارد).
۳) با استانداردها سازگار است و برای زبان C است. پس استفادهٔ گسترده‌تری می‌توان از آن کرد.


منکه فکر میکنم اشتباه کردید. اصلا GTK قابل مقایسه با کیوت نیست. من یک بار بصورت رقابتی با برنامه نویسان GTK، کدهای کیوت و GTK رو برای چند مثال عملی مقایسه کردم که Qt کدهاش حداقل نصف GTK بود و ساختار و خوانایی بهتری هم داشت.اگر حوصله تایپ ندارید از Glade برای طراحی (بصورت XML ذخیره می‌شود) استفاده کنید (خیلی وقت است که Glade بطور مستقیم از کلاس GtkBuilder برای ساخت اشیاء استفاده می‌کند و نیازی به libglade نیست).

در کل منظورم این بود که اگر Qt برای شما مزاحمت ایجاد کرده، به این معنا نیست که کتابخانه‌های croos platform بد هستند! کتابخانه‌های دیگری هم هستند که ارزش امتحان کردن را دارند و برنامه‌نویسی مستقل از سکوی GUI فقط به Qt محدود نشده و Qt به معنای مطلق، از بقیهٔ ابزارهای cross platform برتر نیست.


موضوع اینه که وقتی خود میکروسافت چنین فریمورکی رو داره که کامله (کامله یا تقریبا کامله بهرحال کاملتر از روشهای وصله و پینه ای دیگس) چرا باید از محصولات غیرمیکروسافتی استفاده کنیم؟با این حرف شما موافقم اگر «می‌خواهید تنها در محدودهٔ مایکروسافت برنامه بنویسید» و اگر احساس می‌کنید تنها نیاز شما را NET Framework. برطرف خواهد کرد.

در رابطه با همین ابزار webcamای که کتابخانهٔ کار با آن را نیاز دارید. این کتابخانه را برای C ببینید:
http://opencv.willowgarage.com/wiki/Welcome
اگر به فرض این کتابخانه نیازهای شما را برآورده نکرد، چه ایرادی دارد که بطور مستقیم از توابع سیستم‌عامل استفاده کنید؟ یعنی در گنو/لینوکس از Video4Linux و در ویندوز از DirectShow استفاده کنید. یعنی خودتان یک کتابخانهٔ برای کار با webcam بنویسید. سختی آن در حد همان win32 و ... است. در این حالت شما نهایت کنترل را خواهید داشت چیزی بیشتر از آنکه یک کتابخانهٔ آماده به شما بدهد.


همونطور که گفتم واسه من فرقی نمیکنه. روی زبان خاصی اصرار ندارم. میتونه سی++ هم باشه و کتابخانه هایی مثل Win32 API یا MFC. اما شخصا فکر میکنم آیندهء اپلیکیشن نویسی روی ویندوز عملا برتری کیفی و کمی سی شارپ و دات نت رو شاهد خواهد بود (احتمالا بخشی از این بخاطر سیاستهای میکروسافت هم خواهد بود). بهرحال همونطور که گفتم فعلا این قضیه هنوز مطمئن و وقوع یافته نیست. اما منم روی زبان و فریمورک و فناوری خاصی اصرار ندارم. بحث مقایسهء کیوت و سی شارپ نبود، بحث مقایسهء کیوت و کتابخانه ها و فناوریهای بومی میکروسافت برای برنامه نویسی روی ویندوز بود. من فکر می‌کردم که به cross platform بودن معتقدید ولی شما در اینجا همه‌اش دربارهٔ ویندوز صحبت می‌کنید :شیطان: بنابراین همان MFC یا NET Framework. عالی است.

به یاد زمانی افتادم که اکثر طراحان وب، سایت‌ها را فقط برای IE طراحی می‌کردند و برایشان استانداردها بی‌معنی بود، تا زمانیکه هم‌اکنون هستند وب‌سایت‌هایی که تنها با IE کار می‌کنند در حالیکه ۳۰٪ کاربران از فایرفاکس استفاده می‌کنند. موفق باشید.

[M.T.P]

سی پلاس پلاس

[eshpilen]

من فکر می‌کردم که به cross platform بودن معتقدید ولی شما در اینجا همه‌اش دربارهٔ ویندوز صحبت می‌کنید :شیطان: بنابراین همان MFC یا NET Framework. عالی است.من به cross platform بودن بعنوان یک مزیت نگاه میکنم. اما مسلما پارامترهای دیگری هم وجود دارن.
همه چیز در این دنیا نسبی هست و قاعدهء مطلقی وجود نداره.
بسته به شرایط و برنامه و هدفی که داریم تفاوت میکنه که هر پارامتر چقدر اهمیت داشته باشه.
دقیقا مثل همین واقعیت که هر زبانی کاربرد خودش رو داره. آیا قاعدهء مطلقی در بکارگیری همیشگی یک زبان خاص حتی در کاربردهایی که تخصص اون زبان هست وجود داره؟ آیا ممکن نیست شرایط خارجی روی تصمیم ما اثر بذارن؟

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


به یاد زمانی افتادم که اکثر طراحان وب، سایت‌ها را فقط برای IE طراحی می‌کردند و برایشان استانداردها بی‌معنی بود، تا زمانیکه هم‌اکنون هستند وب‌سایت‌هایی که تنها با IE کار می‌کنند در حالیکه ۳۰٪ کاربران از فایرفاکس استفاده می‌کنند. موفق باشید.بله اینکار صددرصد اشتباهه و اینو بعنوان یک طراح و برنامه نویس وب هم میگم.
چون با اینکار اون کاربرانی رو که از لینوکس یا حتی مرورگرهای دیگری روی ویندوز استفاده میکنن نادیده گرفتن. و البته تعداد این کاربران هم قابل توجه هست. اصولا وب و وبسایت باید تاحد امکان مستقل از سیستم عامل و مرورگر خاصی باشه.
درمورد برنامه نویسان وب این یک وظیفه هست که سایت رو فقط برای IE طراحی نکنن.
اما بحث نوشتن اپلیکیشن بیشتر فرق میکنه چون شرایط و تعریفش تفاوت هایی داره.
مثلا طراحی یک سایت بصورت مستقل از پلتفرم و مرورگر، از طراحی یک اپلیکیشن به همین صورت خیلی راحتتر و رویهء استاندارد هست. معمولا هیچ ضرورتی نداره ما سایتی رو وابسته به یک مرورگر خاص و سیستم عامل خاص طراحی کنیم. و سختی آنچنانی هم نداره که ما سایت رو بصورت مستقل از سیستم عامل و مرورگر طراحی کنیم (البته به شرط یادگیری اصولی و کامل و کمی تجربه و تنبل نبودن طراح و برنامه نویس). ضمنا تعداد کاربران مرورگرهای دیگر و سیستم عاملهای دیگر قابل مقایسه با کاربران لینوکسی که بخوان از یک اپلیکیشن سفارشی که برای یک شرکت اونم ایرانی (!) طراحی شده استفاده کنن قابل مقایسه نیست.
هرچند بطور کلی ایدهء بازمتن بودن و مستقل از پلتفرم بودن خوب هست و باید تا حد امکان دنبال بشه. اما نه به هر قیمتی (بخصوص درمورد مستقل از پلتفرم بودن). و همونطور که گفتم میزان این ضرورت با توجه به نوع برنامه و شرایط فنی و غیرفنی تفاوت میکنه. احتمالا من اگر یک برنامهء خیلی جالب مثل torrent رو برای اولین بار ایده پردازی بکنم باید به فکر این باشم که اون رو آزاد و مستقل از پلتفرم طراحی کنم. هرچند برنامه نویسان پلتفرمهای دیگه معمولا این زحمت رو میکشن (ولی آیا کس دیگری میتونه بعنوان یک کپی از سایت یک سازمان یا شرکت یا حتی سایت شخصی عمل کنه؟).

[eshpilen]

در رابطه با همین ابزار webcamای که کتابخانهٔ کار با آن را نیاز دارید. این کتابخانه را برای C ببینید:
http://opencv.willowgarage.com/wiki/Welcome

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


اگر به فرض این کتابخانه نیازهای شما را برآورده نکرد، چه ایرادی دارد که بطور مستقیم از توابع سیستم‌عامل استفاده کنید؟ یعنی در گنو/لینوکس از Video4Linux و در ویندوز از DirectShow استفاده کنید. یعنی خودتان یک کتابخانهٔ برای کار با webcam بنویسید. سختی آن در حد همان win32 و ... است. در این حالت شما نهایت کنترل را خواهید داشت چیزی بیشتر از آنکه یک کتابخانهٔ آماده به شما بدهد.
مطمئنید زیاد سخت نیست؟
نمیدونم ولی نیاز به بررسی و یادگیری داره.
فکر نمیکنید اینجا از حیطهء تخصص و وظایف یک برنامه نویس اپلیکیشن ممکنه کمی خارج شده باشیم؟ برنامه نویسان اپلیکیشن اینطور کتابخانه ها رو معمولا حاضر و آماده استفاده میکنن، نه اینکه خودشون بنویسن!
نهایت کنترل در اینطور کاربردها زیاد مهم نیست. بطور مثال من از Qt استفاده میکنم و بنظرم در کاربرد اپلیکیشن نهایت کنترلی را که نیاز دارم میدهد. آیا مثلا بنده میروم یک دکمه را خودم از ابتدا با استفاده از توابع ترسیمی پایه ای سیستم عامل طراحی کنم؟ چه نیازی به اینکار هست؟ اصلا کار راحتی هم نیست.

[PC2st]

مسلماً با کتابخانهٔ OpenCV کار نکرده‌ام. همانند Qt که علارقم وجود امکانات زیاد، استفاده از آن ساده است. کتابخانهٔ OpenCV هم به خاطر امکاناتی که ارائه می‌دهد نباید آن را به سخت بودن متهم کنیم.

http://qt-apps.org/content/show.php/Qt+Opencv+webcam+viewer?content=89995
در لینک بالا، فایل سورس برنامه‌ای که برای نمایش تصاویر از webcam از OpenCV در Qt استفاده کرده است را می‌توانید دانلود و مرور کنید.


مطمئنید زیاد سخت نیست؟
نمیدونم ولی نیاز به بررسی و یادگیری داره.
فکر نمیکنید اینجا از حیطهء تخصص و وظایف یک برنامه نویس اپلیکیشن ممکنه کمی خارج شده باشیم؟ برنامه نویسان اپلیکیشن اینطور کتابخانه ها رو معمولا حاضر و آماده استفاده میکنن، نه اینکه خودشون بنویسن!
نهایت کنترل در اینطور کاربردها زیاد مهم نیست. بطور مثال من از Qt استفاده میکنم و بنظرم در کاربرد اپلیکیشن نهایت کنترلی را که نیاز دارم میدهد. آیا مثلا بنده میروم یک دکمه را خودم از ابتدا با استفاده از توابع ترسیمی پایه ای سیستم عامل طراحی کنم؟ چه نیازی به اینکار هست؟ اصلا کار راحتی هم نیست. بستگی به تعریف ما از سختی دارد، اگر منظور از سختی، نوشتن کدهای بیشتر است، بله سخت است.
اما اگر منظور از سختی، عدم توانایی در انجام آن کار است، خیر فکر نمی‌کنم انجام اینکار سخت باشد.

[eshpilen]

باشه این Qt Opencv webcam viewer رو بعدا که نیاز شد بررسی میکنم. خیلی ممنون از لینک شما. هرچند برنامش برای لینوکس هست اما احتمالا روی ویندوز هم کار بکنه.
ولی جدا اگر اینقدر راحت هست چرا توی Qt نمیذارنش؟
این امکان خیلی جذاب و بدردبخوری هست.

[aryasoft2872]

این که شد کل کل،دوستان سوال من رو انگار بی خیال شدن رفتن وارد جزییات شده،پس سوالم رو دوباره مطرح می کنم و جوابم هم خیلی کوتاه می تونه داده بشه (با دلیل)(البته از دوستانی که نظر دادن ممنونم)

سی شارپ برای یادگیری و مهاجرت از Vb بهتره یا ++C?

(در ضمن من رشته ام برنامه نویسی نیست که بخوام از بازار کارش بترسم فقط از روی علاقه کار می کنم پس بحث بازار داخل مطرح نیست...)

با تشکر

[FastCode]

در ضمن من رشته ام برنامه نویسی نیست
پس C++ چون C# یه زبون تجاریه.

[eshpilen]

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

[eshpilen]

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

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

[...StacK...]

با همه ی این اوصاف...چرا یک تابو شده که لااقل تو ایرن بلد نبودن c# یعنی تزلزل در اشتغال برنامه نویس. هست

من خودم به تازگی دارم روی win32 api تو visual c++ کار میکنم و خیلی هم مصمم هستم و اصلا انگیزه ای ندارم روی c# کار کنم ,چون فکر میکنم در این صورت نمیتونم روی هیچ کدوم تسلط کامل و یا به اصطلاحی حرفه ای بشم.

میخوام بدونم visual c++ چه بازه ای از تولید نرم افزار رو دربر میگیره که برنامه نویس بتونه به طور مستقل از لحاظ مالی تامین بشه و یا اینکه من الان بدونم طی یه پروسه 3 یا 4 ساله روی چه فاکتور هایی باید تمرکز داشته باشم که بهترین بازدهی رو واسم داشته باشه.



چرا gtk دز مقابل qt عددی نیست؟


یه ابهامی که تو ذهن من هست اینه که تو vc++ ما مستقیما میتونیم از توابع api بدون واسط استفاده کنیم ...

حالا فریم ورکهایی مثل qt ایا تمام این توابع و خاصیت ها رو پشتیبانی میکنند؟ که به هر دلیلی برنامه نویس با اطمینان کامل از vc دست بکشه؟

و سوال دیگه اینکه مشابه visual c++ در لینوکس چیه؟ که خالص بتونیم از توابع محلی سیستم عامل استفاده کنیم؟ gcc ؟G++ یعنی میشه خارج از محیط ide و با یک ادیتور و کامپایل برنامه تحت کنسول خروجی یک gui پیچیده رو گرفت؟

محیط هایی مثل eclipes مشابه چه چیزی هستند و هدف از ایجاد اونا چی بوده؟

توابع سیستم عامل چطور ایجاد میشه؟ مثلا در زمانی ویندوز 1.0 ما 400 تا بیشتر تابع نداشتیم و حالا بیشمار...

میخوام بدونم چطور مایکروسافت این توابع رو ارائه میده برای برنامه نویس؟ مثل توابع gdi ...

خروجی این تابع ها در درون سیستم عامل قرار داره؟

مثلا وقتی یه برنامه تحت کنسول نوشته میشه--تقریبا توابع و کلاس ها مشخص هستند و تو یه صفحه سیاه خروجی میدن

ولی وقتی یه تابع api نوشته میشه میخوام بدونم بعد از اینکه خروجی exe داد ...وقتی اجرا میشه به کجا رجوع میکنه که gui ما نمایش داده میشه....خروجی این همه توابع کجا قرار داره و در چه سطحی از بستر سیستم عامل اجرا میشه؟

خلاصه این موارد اصلا برام روشن نیست...در این میان اگر کتاب خوبی هم در این مورد میشناسید...معرفی کنید.

با سپاس فراوان.

[...StacK...]

این که شد کل کل،دوستان سوال من رو انگار بی خیال شدن رفتن وارد جزییات شده،پس سوالم رو دوباره مطرح می کنم و جوابم هم خیلی کوتاه می تونه داده بشه (با دلیل)(البته از دوستانی که نظر دادن ممنونم)

سی شارپ برای یادگیری و مهاجرت از Vb بهتره یا ++C?

(در ضمن من رشته ام برنامه نویسی نیست که بخوام از بازار کارش بترسم فقط از روی علاقه کار می کنم پس بحث بازار داخل مطرح نیست...)

با تشکر

c++ رو به شما پیشنهاد نمیکنم.

با اگاهی از اینکه شما به مصارف این زبان ها دانش کافی دارید

من c# یا vb.net رو پیشنهاد میکنم.

[FastCode]

C++/CLI چطوره؟

[eshpilen]

من خودم به تازگی دارم روی win32 api تو visual C++‎‎‎ کار میکنم و خیلی هم مصمم هستم و اصلا انگیزه ای ندارم روی C#‎‎‎ کار کنم ,چون فکر میکنم در این صورت نمیتونم روی هیچ کدوم تسلط کامل و یا به اصطلاحی حرفه ای بشم.

من تجربه ای با win32 ندارم اما فکر میکنم کار کردن مستقیم با win32 زیادی سطح پایین باشه. چرا از MFC استفاده نمیکنید؟
شخصا با اینکه برنامه نویسی سطح پایین و سیستمی رو تا سطح اسمبلی هم سعی کردم یاد بگیرم اما برای اپلیکیشن نویسی هرگز از اینطور چیزا شروع نکردم چون بنظرم سودی نداشت جز هدر دادن وقت و انرژی. چون اینطور کتابخانه ها کاربرد اصلیشون اپلیکیشن نویسی هست و در اپلیکیشن نویسی هم کتابخانه ها و فریمورک های سطح بالاتر تقریبا هرچی رو که نیاز باشه تامین میکنن. اگر آدم بخواد مفاهیم سطح پایین رو یاد بگیره همون الگوریتم ها و ساختمان داده های پایه ای بهترین چیزها و اساس همه چیز هستن. صرفا با یاد گرفتن اینکه API خام تحت سی چه شکلی هست آدم مفاهیم زیربنایی برنامه نویسی رو یاد نمیگیره.
البته ببخشید که بنده اظهار نظر میکنما! شایدم اشتباه فکر میکنم اما من روی تمام سطوح مطالعه و تفکر داشتم و الان فکرم جامع و منسجم شده و فکر میکنم یک تصویر کلی خوب و واضحی دارم از جایگاه همهء اینا.


چرا gtk دز مقابل qt عددی نیست؟ GTK تحت سی هست و Qt تحت سی++.
امکانات شیء گرایی Qt عملا خیلی خوشدست تر و کاملتره.
من نمونه کدهای GTK رو که از دوستان در مقابل کدهای Qt که خودم برای برنامه های کوچک نمونه نوشتم مطالعه کردم. در کدهای GTK مثلا تابعهای جداگانه و خارج از کلاس خاصی، یعنی در فضای گلوبال، برای تعریف اعمالی که مثلا برای پاسخ به فشرده شدن یک دکمه لازم هست تعریف و استفاده شده بودن. تمام امکانات شیء گرایی به اون صورتی که در سی++ هست در سی قابل شبیه سازی نیست.
بفرمایید اینم تاپیک مقایسه که پیداش کردم (استارترش خودم هستم):
http://www.technotux.org/html/PNphpBB2-viewtopic-t-17606-postdays-0-postorder-asc.html
کدهاش رو قشنگ بخونید ببینید آخه با Qt و سی++ از نظر حجم و ساختار چه فرقی میکنه.
حالا بحث امکانات جداست. من دقیقا نمیدونم امکانات GTK بیشتره یا Qt. ولی Qt خیلی مجهز و مدرن هست.


یه ابهامی که تو ذهن من هست اینه که تو vC++‎‎‎ ما مستقیما میتونیم از توابع api بدون واسط استفاده کنیم ...

حالا فریم ورکهایی مثل qt ایا تمام این توابع و خاصیت ها رو پشتیبانی میکنند؟ که به هر دلیلی برنامه نویس با اطمینان کامل از vc دست بکشه؟یک برنامهء Qt هم یک برنامهء سی++ هست و میتونه از هر کتابخانهء تحت سی++ استفاده کنه و کدهای هردو با هم ترکیب بشن. منتها باید اول خود Qt رو با VC کامپایل کنید؛ اونی که دانلود میکنید با MinGW کامپایل شده و کار میکنه و بنابراین نمیشه با بیشتر کتابخانه های تحت ویندوز که با VC کامپایل میشن ترکیبش کرد.


و سوال دیگه اینکه مشابه visual C++‎‎‎ در لینوکس چیه؟ که خالص بتونیم از توابع محلی سیستم عامل استفاده کنیم؟ gcc ؟G++ یعنی میشه خارج از محیط ide و با یک ادیتور و کامپایل برنامه تحت کنسول خروجی یک gui پیچیده رو گرفت؟بله چرا نمیشه. منتها چون اینکار خیلی سخت تر هست فریمورک هایی مثل Qt که ضمنا مزیت دیگری دارن که مستقل از پلتفرم هم هستن بوجود آمدن و ابزارهای ویژوال هم برای طراحی دارن. وگرنه برنامه نویسی روی لینوکس بیشتر به همین صورتی که میگید بوده و هست. تمام سیستم عاملها و ساختار تمام کتابخانه ها و کامپایلرها نهایتا به همین صورت هست و چیزهای دیگه ای که شما میبینید صرفا فریمورک ها و ابزارهای ویژوال برای راحتتر و سریعتر کردن برنامه نویسی هستن.


توابع سیستم عامل چطور ایجاد میشه؟ مثلا در زمانی ویندوز 1.0 ما 400 تا بیشتر تابع نداشتیم و حالا بیشمار...
با برنامه نویسی مستقیم سطح پایین سی، اسمبلی و سی++.


میخوام بدونم چطور مایکروسافت این توابع رو ارائه میده برای برنامه نویس؟ مثل توابع gdi ...یعنی چی چطور؟ خب کتابخانه هستن و اینترفیس دارن دیگه!
از نظر اصول همونطور که شما یک تابع یا کلاس طراحی میکنید و میتونید بعدا اونو بصورت آماده در کد یا از طریق فایل dll استفاده کنید.


خروجی این تابع ها در درون سیستم عامل قرار داره؟ ؟


مثلا وقتی یه برنامه تحت کنسول نوشته میشه--تقریبا توابع و کلاس ها مشخص هستند و تو یه صفحه سیاه خروجی میدن
؟؟

ولی وقتی یه تابع api نوشته میشه میخوام بدونم بعد از اینکه خروجی exe داد ...وقتی اجرا میشه به کجا رجوع میکنه که gui ما نمایش داده میشه....خروجی این همه توابع کجا قرار داره و در چه سطحی از بستر سیستم عامل اجرا میشه؟

برنامهء شما با توابع API که در فایلهای dll کتابخانه و فریمورک مورد استفادهء شما تعریف شدن ارتباط برقرار میکنن و کد اصلی که با سخت افزار و سرویسهای داخلی سیستم عامل ارتباط برقرار میکنه در داخل این فایلهای dll هست. البته اغلب بیش از یک سطح و لایه وجود داره. یعنی این فایلها خودشون باز کتابخانه ها و سرویسهای دیگری از سیستم عامل رو فراخوانی میکنن. نهایتا کدهایی که اجرا میشن کدهای تحت کنترل سیستم عامل هستن که مستقیما با سخت افزار ارتباط برقرار میکنن. البته بعضی برنامه ها بعضی یا تمام لایه ها رو دور میزنن و بصورت مستقیم با سخت افزار ارتباط برقرار میکنن؛ ولی اینطور کد نوشتن مسلما سخت و حجیم و پیچیده هست و تنها در موارد خاص به علت نیازهای خاص بکار میره.

[PC2st]

این که شد کل کل،دوستان سوال من رو انگار بی خیال شدن رفتن وارد جزییات شده،پس سوالم رو دوباره مطرح می کنم و جوابم هم خیلی کوتاه می تونه داده بشه (با دلیل)(البته از دوستانی که نظر دادن ممنونم)

سی شارپ برای یادگیری و مهاجرت از Vb بهتره یا ++C?

(در ضمن من رشته ام برنامه نویسی نیست که بخوام از بازار کارش بترسم فقط از روی علاقه کار می کنم پس بحث بازار داخل مطرح نیست...)

با تشکر


با هر دو کار کنید و ببینید که کدامیک برای شما بهتر است. اگر برای شما مهم است که برنامهٔ شما در همهٔ سیستم‌عامل‌ها اجرا شود (البته در صورت رعایت استانداردها و استفاده از کتابخانه‌های cross platform)، اگر برای شما مهم است که برنامهٔ شما در همهٔ سیستم‌عامل‌ها بومی (native) باشد، اگر برای شما مهم است که برنامهٔ شما چیزی اضافه‌تر از آنچه که شما می‌خواهید انجام ندهد (شما یک نوع عدد ساده می‌خواهید نه یک شیئ که به عنوان یک عدد عمل کند)، اگر شما از سر و کله‌زدن با مفاهیم نزدیک‌تر به سخت‌افزار واهمه‌ای ندارید (برای استفاده از اشاره‌گرها و گاهی موارد شاید بهتر باشد بدانید که کامپایلر چگونه کار می‌کند تنها برای اینکه بهتر کد بزنید)، اگر دوست دارید همه چیز آن طور باشد که شما می‌گوئید، من زبان ++C را پیشنهاد می‌کنم.

اگر موارد قبل برای شما مهم نیست، اگر شما به توسعهٔ سریع برنامه‌ها بیشتر اهمیت می‌دهید، اگر به ویزاردها و ابزارهای آماده و در کنار هم قراردادن آنها علاقه‌مند هستید، اگر کاهش سرعت برنامهٔ شما زیاد مهم نیست، اگر علاقه به سر و کله‌زدن با تکنولوژی‌های خاص مایکروسافت را دارید، اگر بیشتر برنامه‌هایی که می‌نویسید در مورد بانک اطلاعاتی است، من زبان سی‌شارپ را پیشنهاد می‌کنم.

البته زبان‌های دیگری همچون جاوا و پایتون هم هستند که برخلاف سی‌شاپ مستقل از سکو (platform independent) عمل می‌کنند. همهٔ این زبان‌ها می‌توانند برای نوشتن برنامه‌های تجاری استفاده شوند. بهترین حالت این است که شما در مورد زبان‌ها و بخصوص روش و شرایط برنامه‌نویسی در آنها اطلاعات بیشتری کسب کنید (آموزش‌های کوچکی که درباره تک تک آنها آمده است را بخوانید).

[PC2st]

سختی در اینجا بنظرم یعنی نیاز به یادگیری و سر و کله زدن با یکسری چیزهای جدید که بدرد اپلیکیشن نویسی روزمره هم نمیخوره.
اینا برنامه نویسیهای سطح پایین تر از اپلیکیشن نویسی محسوب میشن. درست نیست که نقص کتابخانه رو با ادعای شدنی بودن ایجاد فلان widget و غیره توجیه کنیم.
البته فکر نکن من نمیتونم یا میترسم از این کارا؛ اتفاقا برعکس چون زیاد با این چیزا سر و کله زدم و مفاهیم و بینش پایه ای رو که میخواستم بدست آوردم دیگه حال و حوصله ندارم کارای تکراری ملالت بار انجام بدم و وقت و انرژی ارزشمندم رو تلف بکنم. اگر یکی پول خوب بده واسه این کارا یه حرفی!! ولی من فکر میکنم راحتترین کار روتین استاندارد برای پول درآوردن همون اپلیکیشن نویسی باشه.
البته که ++C به عنوان یک زبان برای نوشتن برنامه‌های از نوع application و system است. اگر شک دارید که ++C بطور خاص برای نوشتن برنامه‌های کاربردی طراحی شده، می‌توانید در ویکی‌پدیا یا گوگل جستجو کنید. شاید به نظر شما نوشتن برنامه‌های application در آن سخت باشد، ولی ببینید که تا کنون چه مقدار از برنامه‌های کاربردی توسط آن نوشته شده است. زبان سی‌شارپ برای نوشتن برنامه‌های از نوع application و web به کار گرفته می‌شود. پس به لحاظ نوشتن برنامه‌های کاربردی (application) زبان‌های ++C و سی‌شارپ مشترک هستند (به لحاظ کاربرد البته).


چرا gtk دز مقابل qt عددی نیست؟
به لحاظ تنوع در امکانات کلی (فارق از GUI). چون Qt یک framework هست ولی Gtk یک تولکیت.


من نمونه کدهای GTK رو که از دوستان در مقابل کدهای Qt که خودم برای برنامه های کوچک نمونه نوشتم مطالعه کردم. در کدهای GTK مثلا تابعهای جداگانه و خارج از کلاس خاصی، یعنی در فضای گلوبال، برای تعریف اعمالی که مثلا برای پاسخ به فشرده شدن یک دکمه لازم هست تعریف و استفاده شده بودن. تمام امکانات شیء گرایی به اون صورتی که در سی++ هست در سی قابل شبیه سازی نیست.
این حرف متاسفانه قابل قبول نیست. همین ++C اولش C with Classes بوده :چشمک:

[eshpilen]

البته که ++C به عنوان یک زبان برای نوشتن برنامه‌های از نوع application و system است. اگر شک دارید که ++C بطور خاص برای نوشتن برنامه‌های کاربردی طراحی شده، می‌توانید در ویکی‌پدیا یا گوگل جستجو کنید. شاید به نظر شما نوشتن برنامه‌های application در آن سخت باشد، ولی ببینید که تا کنون چه مقدار از برنامه‌های کاربردی توسط آن نوشته شده است. زبان سی‌شارپ برای نوشتن برنامه‌های از نوع application و web به کار گرفته می‌شود. پس به لحاظ نوشتن برنامه‌های کاربردی (application) زبان‌های ++C و سی‌شارپ مشترک هستند (به لحاظ کاربرد البته).

بحث سی شارپ و سی++ نبود اصلا.
بحث این بود که کتابخانه های بومی ویندوز، حالا چه با سی شارپ و تحت دات نت کار کنید و چه با Win32 یا MFC و تحت سی++ بصورت Native، کاملتر از کتابخانه های Qt هستن.
اما شما میاید میگید فلان امکان رو که کتابخانه های Qt ندارن خودت با کتابخانه های سطح پایینتر درست کن! پس مسلما این یک برنامه نویسی سطح پایین تر از اپلیکیشن نویسی محسوب میشه (حداقل درمقابل کتابخانه های بومی ویندوز که امکانات حاضر و آماده برای اینطور چیزا دارن احتمالا) و از Qt هم خارج شدیم و دیگه مستقل از پلتفرم هم نیستیم (اگر بخوایم مستقل از پلتفرم باشیم باید حداقل یکی هم برای لینوکس بنویسیم). اینکار جزو تعریف و وظایف و احتمالا دانش و مهارت یک برنامه نویس اپلیکیشن عادی نیست. حتی اگر طرف بتونه خودتون هم میدونید که برنامه نویسی سطح پایین و سیستمی چقدر اذیت میکنه و وقت و انرژی زیادی میطلبه.


این حرف متاسفانه قابل قبول نیست. همین ++C اولش C with Classes بوده :چشمک:اون نام فقط یک اشاره به شباهت و ارتباط خانوادگی و سازگاری این زبانها بوده. وگرنه سی++ یک زبان کاملا جدا هست.
ضمنا سی++ حتی در اوایل توسط یک برنامهء پیش پردازنده برای کامپایل به کدهای سی تبدیل میشد چون هنوز کامپایلر اختصاصی براش درست نشده بود (درست کردن یک کامپایلر بهینه و کامل و قابل اعتماد کار سختی هست، اونم برای زبانی مثل سی++).
بطور کلی سی++ یک زبان مستقل هست و از اولش همینطور طراحی شده.
اما شما طوری میگید انگار سی قراره از این حد فراتر بره و زبان جدیدی ایجاد میشه توی سی!
سی محدودیت ذاتی داره در شیء گرایی و تاحدی، که البته بجای خودش خیلی خوب و چشمگیره و جواب خیلی کاربردها رو میده احتمالا، این امکان براش توسط فریمورک و کتابخانهء دیگری شبیه سازی (یا اگر دوست ندارید بگیم پیاده سازی) شده. بهرحال این امکان جزیی از زبان سی هم نیست و درمقابل کلاسهای سی++ نقصهای اساسی متعددی داره. سی++ یک زبان جداگانه هست و شیء گرایی جزو خود زبان هست. در سی ما نمیتونیم توابع رو با دیتا بصورت کامل پکیج کنیم که اثرش رو در همون برنامه های GTK میبینید و در ارث بری که بجای استفاده از چند کلمه سینتاکس باید کل کدهای یک بخش رو جای دیگه کپی کنیم. چون سی فقط Struct داره و نه کلاس. و Struct ها نمیتونن توابع رو بصورت مستقیم ذخیره کنن (فقط محتوی متغییر و دیتا هستن). این قابلیت رو تاحدی با استفاده از Function pointer ها شبیه سازی کردن فقط. پس ضعف های برطرف نشدنی GTK چی شدن؟ دوتا. یکی ارث بری و دیگری عدم امکان پکیج کردن کامل توابع همراه با دیتا.
اول و آخر نداره. سی و GTK همیشه در همین حد در زمینهء شیء گرایی میمونن چون نمیشه شیء گرایی کامل رو در زبانی که ذاتا شیء گرا نیست و امکانات پایهء لازم رو نداره پیاده سازی کرد.
سی++ کلاس واقعی و تمام قابلیت های مطلوبش رو داره. نه یه چیزی شبیه سازی شده به زور و ناقص.

[eshpilen]

من الان هر کلاس و widget کیوت رو که بخوام میتونم با ارث بری ترکیب و دستکاری کنم، اما با GTK چیکار میکنید؟ خوبه که مقالهء ویکیپدیا رو خوندم و فهمیدم که برای اینکار باید تمام کدهای اون قطعه رو گیر بیاری و کپی و پیست کنی! وگرنه کسی لو نمیداد!! بعدشم یه کامپایل مجدد باید بکنی اون قطعه از GTK رو به سلامتی!
ضمنا توی سی، شما توی بقیهء کدها هم امکانات شیء گرایی سی++ رو در دست ندارید.
پس اصولا برنامهء شما هرگز نمیتونه درحد سی++ سطح بالا و شیءگرا بشه.
نه ارث بری واقعی داری نه میتونی تابعی رو واقعا کنار دیتا و توی یه پکیج به اسم کلاس بذاری!
هرچند درکل من قابلیت های چشمگیر GTK و اون فریمورک شبیه سازی شیء گرایی که ازش استفاده کرده (اسمش GLib (http://en.wikipedia.org/wiki/GLib) Object System هست) رو منکر نیستم، اما قبول کنید این قابلیت ها نمیتونن به پای سی++ و فریمورک هایی که بر اساس سی++ ساخته میشن، برسن. نمونهء عملیش رو هم که دیدید! ندیدید؟ کدهای Qt حجمشون کلی کمتره، ساختارشون خواناتر و منسجم تره. یک علت اصلیش همیناست دیگه!

[eshpilen]

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

[PC2st]

بحث سی شارپ و سی++ نبود اصلا.چون در گفتگوی «مقایسه ++C با C#‎‎‎» هستیم، من هی قاطی می‌کنم در این مورد :شیطان:


اون نام فقط یک اشاره به شباهت و ارتباط خانوادگی و سازگاری این زبانها بوده. وگرنه سی++ یک زبان کاملا جدا هست.من نگفتم ++C زبان جدایی از C with Classes بوده، منظورم این بود که در ابتدا کدهای نوشته شده به زبان ++C به کدهای C تبدیل می‌شده (همانطور که گفتید) و سپس توسط C کامپایل می‌شده... پس نمی‌توان گفت که پیاده‌سازی شیئ‌گرایی در C غیر ممکن است.


اما شما میاید میگید فلان امکان رو که کتابخانه های Qt ندارن خودت با کتابخانه های سطح پایینتر درست کن! پس مسلما این یک برنامه نویسی سطح پایین تر از اپلیکیشن نویسی محسوب میشه (حداقل درمقابل کتابخانه های بومی ویندوز که امکانات حاضر و آماده برای اینطور چیزا دارن احتمالا) و از Qt هم خارج شدیم و دیگه مستقل از پلتفرم هم نیستیم (اگر بخوایم مستقل از پلتفرم باشیم باید حداقل یکی هم برای لینوکس بنویسیم). اینکار جزو تعریف و وظایف و احتمالا دانش و مهارت یک برنامه نویس اپلیکیشن عادی نیست. حتی اگر طرف بتونه خودتون هم میدونید که برنامه نویسی سطح پایین و سیستمی چقدر اذیت میکنه و وقت و انرژی زیادی میطلبه.
در سی‌شارپ و زبان‌های تحت دات‌نت هم اینطور است، اگر فلان کلاس برای فلان کار وجود نداشته باشه، باید به دنبال سایر کتابخانه‌های کمکی بود و اگر چنین کتابخانه‌ای وجود نداشت، برنامه‌نویس خودش باید دست به کار بشه :چشمک:
در ضمن کار با APIهای سیستم‌عامل جزء برنامه‌نویسی Application به حساب می‌آید و جزء برنامه‌نویسی سیستمی نیست. هر چند با این حرف شما موافقم که نسبت به استفاده از کتابخانه‌های آماده، این کار سطح پایین‌تر است.


اول و آخر نداره. سی و GTK همیشه در همین حد در زمینهء شیء گرایی میمونن چون نمیشه شیء گرایی کامل رو در زبانی که ذاتا شیء گرا نیست و امکانات پایهء لازم رو نداره پیاده سازی کرد.چیزی به نام شیئ‌گرائی کامل نداریم. در واقع هر زبانی با توجه به طرز تفکر خودش، شیئ‌گرائی را تعریف و پیاده‌سازی کرده...


من الان هر کلاس و widget کیوت رو که بخوام میتونم با ارث بری ترکیب و دستکاری کنم، اما با GTK چیکار میکنید؟ خوبه که مقالهء ویکیپدیا رو خوندم و فهمیدم که برای اینکار باید تمام کدهای اون قطعه رو گیر بیاری و کپی و پیست کنی! وگرنه کسی لو نمیداد!! بعدشم یه کامپایل مجدد باید بکنی اون قطعه از GTK رو به سلامتی!
ضمنا توی سی، شما توی بقیهء کدها هم امکانات شیء گرایی سی++ رو در دست ندارید.
پس اصولا برنامهء شما هرگز نمیتونه درحد سی++ سطح بالا و شیءگرا بشه.
نه ارث بری واقعی داری نه میتونی تابعی رو واقعا کنار دیتا و توی یه پکیج به اسم کلاس بذاری!
هرچند درکل من قابلیت های چشمگیر GTK و اون فریمورک شبیه سازی شیء گرایی که ازش استفاده کرده (اسمش GLib (http://en.wikipedia.org/wiki/GLib) Object System هست) رو منکر نیستم، اما قبول کنید این قابلیت ها نمیتونن به پای سی++ و فریمورک هایی که بر اساس سی++ ساخته میشن، برسن. نمونهء عملیش رو هم که دیدید! ندیدید؟ کدهای Qt حجمشون کلی کمتره، ساختارشون خواناتر و منسجم تره. یک علت اصلیش همیناست دیگه! متاسفانه باید بگویم اصلا اینطور نیست. یا آن مقالهٔ موجود در ویکی‌پدیا اشتباه نوشته یا شما با عجله به این نتیجه رسیده‌اید. برای ارث‌بری از یک ویدجت یا کلاس در Gtk نیازی به کامپایل مجدد یا نیازی به کپی/پیست سورس‌کدهای کلاس والد (پدر یا base) نیست. تنها چیزی که تکراری است و باید کپی/پیست شود، ۵ عدد ماکروی ناچیز هستند که برنامه‌نویس آنها را تعریف می‌کند:

#define EAZ_TYPE_TIMELINE (eaz_timeline_get_type ())
#define EAZ_TIMELINE(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), EAZ_TYPE_TIMELINE, EazTimeline))
#define EAZ_TIMELINE_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), EAZ_TYPE_TIMELINE, EazTimelineClass))
#define EAZ_IS_TIMELINE(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), EAZ_TYPE_TIMELINE))
#define EAZ_IS_TIMELINE_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), EAZ_TYPE_TIMELINE))
#define EAZ_TIMELINE_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), EAZ_TYPE_TIMELINE, EazTimelineClass))این ماکروها تمام چیزهایی است که کاربر باید کپی/پیست کند، کدهای بالا را من از برنامه‌ای که در حال نوشتن آن هستم آورده‌ام که مربوط به ویدجت Timeline است که برای نمایش گرافیکی وضعیت فعلی زمان به کار می‌رود. Eaz هم در اینجا نام فضای نام است. بگذریم اگر برنامه‌نویس ماکروهای بالا را هم تعریف نکند، آسمان به زمین نمی‌آید. :شیطان:

Gobject که اساس Gtk را تشکیل می‌دهید، از ارث‌بری یگانه + ارث‌بری چندین اینترفیس (Interface) و توابع virtual و همچنین از signal و slotها پشتبانی می‌کند و جالب اینکه حتی مدیریت حافظه (memory management) را هم بر عهده خواهد گرفت.

در رابطه با اینکه در زبان C توابع درون struct قرار نمی‌گیرند، باید بگویم که این تناقضی با شی‌گرائی ندارد. اگر واقعیت را بخواهید بدانید، توابع عضو کلاس در ++C در واقع همان توابع معمولی هستند که آرگومان اول آنها از نوع خود کلاس است (this) و در زبان C با اینکه توابع خارج از ساختار قرار گرفته‌اند اما آنها نیز آرگومان اولشان از نوع structای است که به آن مربوط هستند. در واقع اینطور بگویم، شیئ‌گرایی به ظاهر نیست، به مفهوم و کاربرد آن است.


اولا که سی شارپ به سینتاکس خودش چیزهای جالب و مفیدی اضافه کرده و یکسری اصلاحات خوب داره که سی++ نداره.
شما اینا رو نادیده میگیرید و طوری برخورد میکنید که انگار سی شارپ تنها فرقش با سی++ اینه که تحت دات نت اجرا میشه و مقداری کندتره و غیره.
دوما، مزایای بزرگ Managed Code و مدیریت حافظهء خودکار و جلوگیری از خطاهای متداول برنامه نویسی که میتونن بصورت پنهان و باگ زمان اجرا و حتی حفره های امنیتی هم دربیان چی؟ به همهء اینا هم هیچ اشاره ای نمیکنید.مقایسه‌ای که من در چند پست قبل نوشته بودم، حتی‌المقدور فاقد مسائل فنی بود و فقط برای بیان‌کردن شرایط خاص هر زبان نوشته بودم. برای انجام مقایسه فنی که بحث بسیار است :شیطان: اما به طور کلی، چه کسی گفته وجود memory management در همه حال خوب است؟ آیا اصلا در همه حال به آن احتیاج است؟ (اینطور به شما بگویم، در ++C (نه در C) می‌توانید طوری برنامه بنویسید که نیازی به آن نباشد!).

آنطور از ++C صحبت می‌کنید که انگار برای شما یک جهنم بوده است!
در زبان ++C تا وقتی همهٔ زیر و بم‌ها و روش‌های برنامه‌نویسی در آن را به خوبی یاد نگیرید (بطور اصولی و می‌توانم بگویم در حد تسلط نه فقط در حد یادگیری)، همیشه در کلنجار و عذاب خواهید بود و احساس می‌کنید برنامه‌نویسی در آن طاقت‌فرسا است.


تعجب میکنم از حرفه ایها که هیچ به این مسائل اشاره نمیکنن. اگر بنظرتون اینا مزیت سی شارپ (و بطور کلی دات نت) نیستن، یا سی++ با چنین مسائلی روبرو نیست چرا با دلیل و سند نمیگید که چرا؟ فریمورک ها و متدها و ابزارهایی که هستن فقط تاحدی این مسائل رو حل میکنن و مسائل همواره بجای خودشون باقی هستن. اون کجا که تمام این موارد در خود زبان لحاظ شده باشه و سینتاکس امنتر و بدون نیاز به توجه به این مسائل فرعی و جزییات فنی داشته باشه و همهء کار در این زمینه ها رو کامپایلر و محیط اجرا انجام بده، و اون کجا که نیاز به آگاهی و حضور ذهن و استفاده از متدها و ابزارها و روشهای مختلف باشه برای کم کردن خطر و عوارض این خصیصه ها. طراحان زبان ++C می‌توانستند همهٔ خصائص را در خود زبان جا دهند. دسترسی به اعضای آرایه‌ها را تا اندازه‌شان محدود کنند. طول آرایه را به همراه خود آرایه ذخیره کنند. رشته‌ها را به عنوان یک نوع جدید معرفی کنند و ... اما این کار انجام نشد و نخواهد شد: چون: ۱) سازگاری با C و ۲) مناسب برای برنامه‌نویسی سیستمی ۳) کم حجم بودن و افزایش کارآیی زبان ۴) در ازایش کافی بود قابلیت مورد نظر را به عنوان یک کلاس یا تابع در کتابخانهٔ استاندارد (Standard Loibrary) قرار دهند.

[eshpilen]

من نگفتم ++C زبان جدایی از C with Classes بوده، منظورم این بود که در ابتدا کدهای نوشته شده به زبان ++C به کدهای C تبدیل می‌شده (همانطور که گفتید) و سپس توسط C کامپایل می‌شده... پس نمی‌توان گفت که پیاده‌سازی شیئ‌گرایی در C غیر ممکن است.

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


در سی‌شارپ و زبان‌های تحت دات‌نت هم اینطور است، اگر فلان کلاس برای فلان کار وجود نداشته باشه
مزیت برای برنامه نویسی اپلیکیشن همین آماده بودن هرچه بیشتر امکانات عمومی هست در سطح برنامه نویسی اپلیکیشن. هر کتابخانه و فریمورکی که کاملتر باشه مسلما برای اپلیکیشن نویسها مناسبتر بحساب میاد.


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


متاسفانه باید بگویم اصلا اینطور نیست. یا آن مقالهٔ موجود در ویکی‌پدیا اشتباه نوشته یا شما با عجله به این نتیجه رسیده‌اید. برای ارث‌بری از یک ویدجت یا کلاس در Gtk نیازی به کامپایل مجدد یا نیازی به کپی/پیست سورس‌کدهای کلاس والد (پدر یا base) نیست. تنها چیزی که تکراری است و باید کپی/پیست شود، ۵ عدد ماکروی ناچیز هستند که برنامه‌نویس آنها را تعریف می‌کند:

#define EAZ_TYPE_TIMELINE (eaz_timeline_get_type ())
#define EAZ_TIMELINE(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), EAZ_TYPE_TIMELINE, EazTimeline))
#define EAZ_TIMELINE_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), EAZ_TYPE_TIMELINE, EazTimelineClass))
#define EAZ_IS_TIMELINE(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), EAZ_TYPE_TIMELINE))
#define EAZ_IS_TIMELINE_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), EAZ_TYPE_TIMELINE))
#define EAZ_TIMELINE_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), EAZ_TYPE_TIMELINE, EazTimelineClass))این ماکروها تمام چیزهایی است که کاربر باید کپی/پیست کند، کدهای بالا را من از برنامه‌ای که در حال نوشتن آن هستم آورده‌ام که مربوط به ویدجت Timeline است که برای نمایش گرافیکی وضعیت فعلی زمان به کار می‌رود. Eaz هم در اینجا نام فضای نام است. بگذریم اگر برنامه‌نویس ماکروهای بالا را هم تعریف نکند، آسمان به زمین نمی‌آید. :شیطان:

Gobject که اساس Gtk را تشکیل می‌دهید، از ارث‌بری یگانه + ارث‌بری چندین اینترفیس (Interface) و توابع virtual و همچنین از signal و slotها پشتبانی می‌کند و جالب اینکه حتی مدیریت حافظه (memory management) را هم بر عهده خواهد گرفت.

من نمیدونم اون زمان در مقالهء ویکیپدیا اینطور نوشته بود:
For example, creating a non-trivial subclass (even just a subclass of GObject) can require writing and/or copying hundreds of lines of code. Nevertheless, adopting GObject can lead to a significant improvement of C code that is, or wants to be, object-oriented.
منبع: http://en.wikipedia.org/wiki/GObject
این متن هنوزم هست. بنابراین من فکر میکنم هنوزم مصداق داره وگرنه مقاله های ویکیپیدا اونم درمورد اینطور چیزها سریع آپدیت میشن.
ضمنا دقت کنید گفته میتونه اینطور باشه، نه اینکه همیشه اینطوره.


در رابطه با اینکه در زبان C توابع درون struct قرار نمی‌گیرند، باید بگویم که این تناقضی با شی‌گرائی ندارد. اگر واقعیت را بخواهید بدانید، توابع عضو کلاس در ++C در واقع همان توابع معمولی هستند که آرگومان اول آنها از نوع خود کلاس است (this) و در زبان C با اینکه توابع خارج از ساختار قرار گرفته‌اند اما آنها نیز آرگومان اولشان از نوع structای است که به آن مربوط هستند. در واقع اینطور بگویم، شیئ‌گرایی به ظاهر نیست، به مفهوم و کاربرد آن است.
اینا رو که میدونم عزیز برادر. بحث پیاده سازی داخلی نیست. وگرنه همهء زبانها نهایتا به اسمبلی و کد ماشین تبدیل میشن که شیء گرایی حالیش نمیشه!
مهم اینه که این جزییات در سطح برنامه نویس با انتزاع و راحتی مناسب پیاده شده باشن و بتونن در خوانایی و تجسم صحیح برنامه نویس در نوشتن برنامه های سطح بالا بکار برن.


مقایسه‌ای که من در چند پست قبل نوشته بودم، حتی‌المقدور فاقد مسائل فنی بود و فقط برای بیان‌کردن شرایط خاص هر زبان نوشته بودم. برای انجام مقایسه فنی که بحث بسیار است :شیطان: اما به طور کلی، چه کسی گفته وجود memory management در همه حال خوب است؟ آیا اصلا در همه حال به آن احتیاج است؟ (اینطور به شما بگویم، در ++C (نه در C) می‌توانید طوری برنامه بنویسید که نیازی به آن نباشد!).

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


آنطور از ++C صحبت می‌کنید که انگار برای شما یک جهنم بوده است!
در زبان ++C تا وقتی همهٔ زیر و بم‌ها و روش‌های برنامه‌نویسی در آن را به خوبی یاد نگیرید (بطور اصولی و می‌توانم بگویم در حد تسلط نه فقط در حد یادگیری)، همیشه در کلنجار و عذاب خواهید بود و احساس می‌کنید برنامه‌نویسی در آن طاقت‌فرسا است.
من صرفا واقعیت ها رو میگم. دلیل پیدایش زبانهای سطح بالا فکر میکنید چیه؟ دلیل پیدایش مدیریت خودکار حافظه چیه؟ دلیل ایجاد داینامیک تایپ چیه؟ آیا مثلا در برنامه نویسی وب کسی انتظار داره با سی++ برنامه بنویسه و حافظه رو خودش مدیریت کنه؟ چقدر اینکار معمول هست؟
بنابراین مناسب بودن یک زبان به کاربرد و نوع برنامه نویسی برمیگرده.
من جایی نگفتم سی++ بد و جهنم و ضعیف هست و نمیشه باهاش اپلیکیشن های خوبی نوشت. بلکه میگم سی شارپ و دات نت ایدهء خوب و مفیدی هست و Productivity رو در برنامه های اپلیکیشن عادی میتونه به مقدار قابل توجهی بالا ببره. بنابراین وقتی سی شارپ و دات نت هست دیگه سی++ در اون موارد انتخاب بهتری بحساب نمیاد. اما هنوزم سی++ کاربردهای خودش رو داره و شاید ضرورت چندانی نداشته باشه برنامه نویسان حرفه ای سی++ به سی شارپ مهاجرت کنن، اما کسی که از ابتدا میخواد شروع کنه یک زبان برای اپلیکیشن نویسی عادی تحت ویندوز رو، چرا سی شارپ بجای سی++ نه؟!


طراحان زبان ++C می‌توانستند همهٔ خصائص را در خود زبان جا دهند. دسترسی به اعضای آرایه‌ها را تا اندازه‌شان محدود کنند. طول آرایه را به همراه خود آرایه ذخیره کنند. رشته‌ها را به عنوان یک نوع جدید معرفی کنند و ... اما این کار انجام نشد و نخواهد شد: چون: ۱) سازگاری با C و ۲) مناسب برای برنامه‌نویسی سیستمی ۳) کم حجم بودن و افزایش کارآیی زبان ۴) در ازایش کافی بود قابلیت مورد نظر را به عنوان یک کلاس یا تابع در کتابخانهٔ استاندارد (Standard Loibrary) قرار دهند.
بله میدونم.
به همین دلیل وقتش رسید که زبانهای پیشرفته از سی++ برای اهداف سطح بالاتر هم بیان و وظیفهء این یادگیری و دقت و کدنویسی های اضافه گردن برنامه نویس اپلیکیشنهای عادی نباشه.
درواقع زبانهایی مثل سی شارپ و سی++ مکمل هستن. البته در موارد زیادی با هم درمورد کاربرد همپوشانی و تضاد پیدا میکنن ولی بطور کلی هرکدوم بخشی رو پوشش میدن و مزایا و معایبی دارن که در کاربردهای مختلف اهمیت اونها تفاوت میکنه؛ بنابراین اینطور نیست که بگیم یکی بهتر از دیگری هست. بستگی به کاربرد و شرایط داره. من میگم برای اپلیکیشن نویسی عادی روی ویندوز سی شارپ مگه چه اشکالی داره و چرا باید سی++ رو بهش ترجیح داد؟ تازه آینده سی شارپ در اثر سیاست های مایکروسافت روشنتر از سی++ بنظر میاد. سازگاری با استانداردهای جدید و تعداد زیاد برنامه نویسان و کدها و کتابخانه ها و پشتیبانی بروز و کامل و قوی هم مسلما میتونن یک مزیت دیگر در آینده برای سی شارپ باشن.

[PC2st]

اون دیگه سی نمیشه آخه. منظور پیاده سازی در سطح داخلی و سینتاکس زبان سی هست.مگر من گفتم C with Classes معادل C بوده!! نمی‌دانم شما چطور از جمله من چنین برداشتی کرده بودید. من منظورم این بود که رسیدن به اهداف شیئ‌گرایی به کمک زبان C غیر ممکن نیست.


این متن هنوزم هست. بنابراین من فکر میکنم هنوزم مصداق داره وگرنه مقاله های ویکیپیدا اونم درمورد اینطور چیزها سریع آپدیت میشن.
ضمنا دقت کنید گفته میتونه اینطور باشه، نه اینکه همیشه اینطوره.اگر با قوانین ویکی‌پدیا آشنا باشید، عباراتی که فاقد استناد هستند بصورت citation needed علامت خواهند خورد، آن جمله‌ای که شما از ویکی‌پدیا نقل قول کرده‌اید قابل استناد نیست زیرا بعنوان citation needed علامتگذاری شده است.


بهرحال اسمش هرچی باشه، یه زبانی که ارث بری و امکان پکیج کردن کامل توابع و دیتا رو با هم نداشته باشه بنظرم ضعیف تر از زبانی که همهء این امکانات مهم رو داشته باشه بحساب میاد در زمینهء شیء گرا بودن.ببینید... شیئ‌گرایی Gobject متفاوت از شیئ‌گرایی پشتیبانی‌شده توسط زبان ++C است. بحث شما نمی‌دانم برای چه است. بهرحال کتابخانهٔ Gtk مفهوم شیئ‌گرایی را تا همان حدی لازم دارد که توسط Gobject پیاده‌سازی شده است و برای Gtk مهم نیست که تا چه حد از شیئ‌گرایی ++C یا دیگر زبان‌ها فاصله دارد.

اگر بحث شما بر سر این است که با روش‌های پیاده‌سازی شده در C نمی‌توان به شیئ‌گرایی ++C رسید. به لحاظ مفهومی می‌توان اما به لحاظ ظاهری خیر. من استفاده از C را به استفاده از ++C توجیح نمی‌کنم. در واقع من با زبان برنامه‌نویسی ++C بطور مستقیم از Gtk استفاده می‌کنم. پس فکر نکنید که من می‌گویم نیازی به شیئ‌گرایی پشتیبانی‌شده در ++C نیست. بلکه من منظورم این است که اگر مفهوم شیئ‌گرایی مد نظر است، به خوبی در کتابخانهٔ Gtk لحاظ شده است (به لحاظ ظاهری هم طوری توسعه یافته که کسی با آن مشکلی نخواهد داشت).

در رابطه با روش شیئ‌گرایی به کار رفته توسط Gobject باید بگویم که نام توابع + نوع آرگومان‌های ورودی آن مشخص می‌کند که مربوط به چه کلاسی است و هیچگاه یک برنامه‌نویس مشکل قاطی‌شدن نام توابع از کلاس‌های مختلف را نخواهد داشت. بهتر است سری به مستنداتش بزنید.
بطور مثال تابع gtk_button_get_label ، نحوهٔ استفاده:

label = gtk_button_get_label (my_button);این تابع مربوط به کلاس GtkButton است. (ویدجت Button در فضای نام Gtk)
اولین آرگومان ورودی این تابع، یک نمونه شیئ از نوع GtkButton است.
اما اگر my_button را به عنوان نوعی از کلاس والدش (GtkWidget) ذخیره کرده باشیم باید توسط ماکروی پیش‌پردازندهٔ GTK_BUTTON به نوع کلاس فرزند تبدیل شود (ماکروهای این چنینی مثل GTK_IS_BUTTON در قبل از پیاده‌سازی توابع برای اطمینان از صحیح بودن نوع آرگومان‌ها، به کار گرفته می‌شود و Type Safety بصورت manual در سراسر توابع Gtk اعمال شده است):

label = gtk_button_get_label (GTK_BUTTON (my_button));معادل این روش در ++C چطوریست؟ (my_button از نوع Gtk::Button است)

label = my_button.get_label ();معادل این روش در سی‌شارپ چطوریست؟ (my_button از نوع Gtk.Button است)

label = my_button.Label;معادل این روش در پایتون چطوریست؟ (my_button از نوع gtk.Button است)

label = my_button.get_label ()
به همین دلیل وقتش رسید که زبانهای پیشرفته از سی++ برای اهداف سطح بالاتر هم بیان و وظیفهء این یادگیری و دقت و کدنویسی های اضافه گردن برنامه نویس اپلیکیشنهای عادی نباشه.این جملهٔ شما جای بحث دارد. در کلام آخر و باتوجه به کدهای بالا همانطور که ملاحظه می‌کنید، ++C هم جنبه‌های Cگونه دارد و هم جنبه‌های مفید سایر زبان‌های سطح بالا... مطمئنا زبان C هم آنقدر شبیه اسمبلی نیست که برنامه‌نویسی اپلیکیشن‌های عادی در آن خودکشی باشد.

ببینید شما تنها و فقط راحت‌ترین‌ها را می‌خواهید و این در تمام پست‌های شما مشخص است (حتی اگر این راحتی خیلی محسوس هم نباشد).
پس چرا بی‌خود این بحث را کش دهیم؟
به نظر شما نوشتن برنامه‌های کاربردی با زبان ++C وقت تلف‌کردن است چون تایپ چند کلمهٔ اضافه، بی‌معنی است!
به نظر من اینطور نیست.

[eshpilen]

به نظر شما نوشتن برنامه‌های کاربردی با زبان ++C وقت تلف‌کردن است چون تایپ چند کلمهٔ اضافه، بی‌معنی است!بنظر شما اختلاف حداقل 30% حجم کد در یک برنامهء بزرگ چقدر میتونه مهم باشه؟
ضمنا فقط حجم کد نیست، مسائل دیگه که گفتم پس چی شدن؟ مدیریت خودکار حافظه، حفاظت خودکار از بافرها و آرایه ها و اشاره گرها (هرچند در سی شارپ اصلا بصورت عادی اشاره گر هم نداره!) و ویژگیهای دیگری که تمام اینها در زبانهایی مثل سی و سی++ نیاز به یادگیری و تمهید و دقت و بکارگیری کدهای اضافه و روشها و امکانات کتابخانه های معین برای جلوگیری از ایجاد باگ و حفره های امنیتی در برنامه های بزرگ دارن، و تازه بازم تمام اینها تضمین نمیکنه که برنامه نویس مرتکب خطا نشه و جاهایی که حتی حرفه ای ترین و دقیق ترین برنامه نویسها هم نمیتونن چیزی رو پیشبینی بکنن یا از زیر دستشون در میره موجب ایجاد باگ و آسیب پذیری امنیتی در برنامه نشه. هرچند برنامه در کل الگوریتم اصلی و مسائل جانبی زیادی داره که یک برنامه نویس ضعیف مسلما نمیتونه اونها رو خوب پیاده کنه، اما قصد من توجیهی برای برنامه نویسهای غیرحرفه ای و بی دقت و کم سواد نیست، بلکه بعکس میگم وقت و انرژی یک برنامه نویس حرفه ای بیش از اون ارزش داره که روی مسائل جانبی و داخلی که میتونن خودکار بشن تلف بشه و بهتره روی حل مسائلی که رایانه و زبان خودش نمیتونه حل کنه متمرکز بشه. از طرف دیگه خطای انسانی پنهان حتی درمورد حرفه ای ترین افراد و حتی با وجود کاملترین تست ها چیز نامتداولی نیست و موجب ایجاد باگ و بخصوص حفره های امنیتی میشه. پس چه بهتر که زبان درجایی که مقدور هست و هزینهء سنگینی برای اون کاربرد (مثل اپلیکیشن نویسی) محسوب نمیشه خودش حداقل بخشی از مسائل بدوی و درونی فنی رو حل کنه و این بار رو از دوش برنامه نویس برداره و احتمال باگ و حفره در این زمینه ها رو خیلی کمتر بکنه. بخصوص توجه کنید که در برنامه های بزرگ همیشه باگ و حفرهء امنیتی و سختی برنامه نویسی در این موارد خیلی مشهودتر میشه که طبیعی هم هست. شاید در نوشتن یک اپلیکیشن کوچک فرق زیادی بین سی++ و سی شارپ نباشه، اما برای پروژه های بزرگ و پیچیده احتمالا این تفاوت در وقت و انرژی مورد نیاز برای برنامه نویسی و همینطور میزان باگ ها و حفره های نهایی خیلی ملموس تر میشه.
من نمیدونم شما سر چی بحث میکنید. چیزایی که من میگم بحث های روز متخصصان طراز اول این رشته هست و بیشتر زبانهای جدید اصولا بر این اساس طراحی میشن و مورد نیاز هستن. امروزه راحتی و سرعت کدنویسی و مدیریت خودکار جهت تضمین باگ ها و حفره های امنیتی کمتر مسئلهء کاملا مهم و دارای اولویت بالایی هست.

[PC2st]

عدد 30 عدد مطلق و جالبی بود :شیطان: خوشحال می‌شوم در ادامه، نظرات خود را با دلیل و برهان بیاورید.

امنیت یک برنامه به زبان برنامه‌نویسی آن وابسته نیست.
مهمترین دلیل برای داشتن یک برنامهٔ ایمن، طرز کار و روش‌های بکاربرده‌شده در برنامه است.

اگر مخالف این مورد هستید تا هم‌اکنون بر سر آن بحث کنیم :لبخند:. نداشتن bound checking برای آرایه‌ها در ++C یا نداشتن مدیریت حافظه، اینها به معنای ایجاد کنندهٔ مشکلات امنیتی نیست به عبارتی یک برنامه‌نویس ++C یا C کارش را خوب بلد است (در واقع ++C و بخصوص C اینطور انتظار دارد)، کنترل اینها هم ساده است و تقریبا هیچوقت یک برنامه‌نویس باتجربه آنها را فراموش نمی‌کند. ضمن اینکه یک برنامه‌نویس باتجربهٔ ++C در اکثر مواقع از استفادهٔ مستقیم از اشاره‌گرها برحذر می‌کند. بنابراین شما هم از آنها استفاده نکنید، چه کسی گفته که برای برنامه‌نویسی در ++C حتماُ باید کنترل مدیریت حافظه را بر عهده داشت (چرا باید بطور مستقیم از اشاره‌گر استفاده کنبد، لطفا قبل از اعتراض به این جملهٔ من، گوگل کنید :چشمک:)؟

مدیریت خودکار حافظه، آرایه‌های دینامیک به همراه اندازهٔ مشخص، نوع جدید برای رشته‌ها، برنامه‌نویسی reflective (که در سی‌شارپ و پایتون و جاوا ممکن‌پذیر است)، وجود خصوصیات و eventها و غیره، ایجاد محیطی امن برای برنامه‌نویسی و جلوگیری از انجام‌دادن برنامه‌نویسی خطرناک، اینها خوب هستند ولی نه به معنای مطلق. همهٔ این‌هایی که من نوشتم را می‌توانید با ++C کسب کنید در ظاهری متفاوت از آنچه در ++C و جاوا و ... وجود دارند و به روشی متفاوت.

اما یک تفاوت وجود دارد، ++C اجازه می‌دهد شما بصورت خطرناک هم برنامه بنویسید چونکه شما می‌دانید چه دارید می‌کنید. آرایه‌های C امن نیست؟ از vector استفاده کنید. از array (در tr1) استفاده کنید. اشاره‌گرها خوب نیستند؟ از آنها بطور غیر مستقیم استفاده کنید (این نکتته بسیار مهم است). مدیر حافظه می‌خواهید؟ ۱) طوری در ++C برنامه بنویسید که نیازی به مدیریت مستقیم حافظه نباشد (نگویید که اینکار ممکن نیست). ۲) از روش‌هایی که برای مدیریت حافظه وجود دارد استفاده کنید. یا اینکه ۲) از کلاس‌های shared_ptr و auto_ptr و ... یا از هر آنچه که می‌خواهید استفاده کنید یا اینکه خودتان یکی بنوسید. الان می‌دانم در ذهن خود می‌گویید «چطور بنویسم! این کار طاقت‌فرسایی است!» اما واقعیت این است که اگر بدانید چگونه اینکار امکان پذیر است، این حرف را نمی‌زنید.

متاسفانه خیلی‌ها فکر می‌کنند روش برنامه‌نویسی در ++C دقیقا همان C است! به عنوان یک نکته، ++C کاملا به C وابسته نیست. آرایه‌ها در ++C کلاس vector یا کلاس array یا list یا ... هستند. ++C روش برنامه‌نویسی مخصوص و خاص خود را دارد. نکته دیگر اینکه در ++C مدیریت حافظه بصورت خودکار نیست چون نیازی هم به آن نیست. شما از کلاس‌های تعریف شدهٔ استاندارد استفاده کنید اگر از استفادهٔ مستقیم از اشاره‌گرها برحذر کنید. آن وقت هیچوقت به یک memory management نیاز نخواهید داشت (مگر در شرایطی که احتیاج به اشتراک‌گذاری یک مقدار از حافظهٔ heap را داشته باشد).

به غیر از بحث امنیت و مدیریت حافظه و ... که گفتم، برنامه‌نویسی ++C با استفاده از ابزارها و کتابخانه‌های آماده درست است به اندازه سی‌شارپ سریع نیست ولی به اندازهٔ کافی rapid است، خوشبختانه هم Gtk هم Qt دارای برنامهٔ designer هستند. فکر می‌کنم MFC در ویندوز هم یک طراح دارد. قابلیت auto completion هم که اکثر ویرایشگرهای جدید دارند.

این چیزهایی که من در بالا گفتم (روش برنامه‌نویسی در ++C و وجود ابزارها برای توسعهٔ سریعتر)، در رد طاقت‌فرسا بودن کار با ++C بود.

[FastCode]

PC2st:........
واقعا" دفاعیه ی عالی ای بود.لذت بردم.چند وقت بود کسی اینجوری C++ رو تو سر C# نزده بود.

[Alireza_Salehi]

عدد 30 عدد مطلق و جالبی بود :شیطان: خوشحال می‌شوم در ادامه، نظرات خود را با دلیل و برهان بیاورید.

امنیت یک برنامه به زبان برنامه‌نویسی آن وابسته نیست.
مهمترین دلیل برای داشتن یک برنامهٔ ایمن، طرز کار و روش‌های بکاربرده‌شده در برنامه است.

اگر مخالف این مورد هستید تا هم‌اکنون بر سر آن بحث کنیم :لبخند:. نداشتن bound checking برای آرایه‌ها در ++C یا نداشتن مدیریت حافظه، اینها به معنای ایجاد کنندهٔ مشکلات امنیتی نیست به عبارتی یک برنامه‌نویس ++C یا C کارش را خوب بلد است (در واقع ++C و بخصوص C اینطور انتظار دارد)، کنترل اینها هم ساده است و تقریبا هیچوقت یک برنامه‌نویس باتجربه آنها را فراموش نمی‌کند. ضمن اینکه یک برنامه‌نویس باتجربهٔ ++C در اکثر مواقع از استفادهٔ مستقیم از اشاره‌گرها برحذر می‌کند. بنابراین شما هم از آنها استفاده نکنید، چه کسی گفته که برای برنامه‌نویسی در ++C حتماُ باید کنترل مدیریت حافظه را بر عهده داشت (چرا باید بطور مستقیم از اشاره‌گر استفاده کنبد، لطفا قبل از اعتراض به این جملهٔ من، گوگل کنید :چشمک:)؟

مدیریت خودکار حافظه، آرایه‌های دینامیک به همراه اندازهٔ مشخص، نوع جدید برای رشته‌ها، برنامه‌نویسی reflective (که در سی‌شارپ و پایتون و جاوا ممکن‌پذیر است)، وجود خصوصیات و eventها و غیره، ایجاد محیطی امن برای برنامه‌نویسی و جلوگیری از انجام‌دادن برنامه‌نویسی خطرناک، اینها خوب هستند ولی نه به معنای مطلق. همهٔ این‌هایی که من نوشتم را می‌توانید با ++C کسب کنید در ظاهری متفاوت از آنچه در ++C و جاوا و ... وجود دارند و به روشی متفاوت.

اما یک تفاوت وجود دارد، ++C اجازه می‌دهد شما بصورت خطرناک هم برنامه بنویسید چونکه شما می‌دانید چه دارید می‌کنید. آرایه‌های C امن نیست؟ از vector استفاده کنید. از array (در tr1) استفاده کنید. اشاره‌گرها خوب نیستند؟ از آنها بطور غیر مستقیم استفاده کنید (این نکتته بسیار مهم است). مدیر حافظه می‌خواهید؟ ۱) طوری در ++C برنامه بنویسید که نیازی به مدیریت مستقیم حافظه نباشد (نگویید که اینکار ممکن نیست). ۲) از روش‌هایی که برای مدیریت حافظه وجود دارد استفاده کنید. یا اینکه ۲) از کلاس‌های shared_ptr و auto_ptr و ... یا از هر آنچه که می‌خواهید استفاده کنید یا اینکه خودتان یکی بنوسید. الان می‌دانم در ذهن خود می‌گویید «چطور بنویسم! این کار طاقت‌فرسایی است!» اما واقعیت این است که اگر بدانید چگونه اینکار امکان پذیر است، این حرف را نمی‌زنید.

متاسفانه خیلی‌ها فکر می‌کنند روش برنامه‌نویسی در ++C دقیقا همان C است! به عنوان یک نکته، ++C کاملا به C وابسته نیست. آرایه‌ها در ++C کلاس vector یا کلاس array یا list یا ... هستند. ++C روش برنامه‌نویسی مخصوص و خاص خود را دارد. نکته دیگر اینکه در ++C مدیریت حافظه بصورت خودکار نیست چون نیازی هم به آن نیست. شما از کلاس‌های تعریف شدهٔ استاندارد استفاده کنید اگر از استفادهٔ مستقیم از اشاره‌گرها برحذر کنید. آن وقت هیچوقت به یک memory management نیاز نخواهید داشت (مگر در شرایطی که احتیاج به اشتراک‌گذاری یک مقدار از حافظهٔ heap را داشته باشد).

به غیر از بحث امنیت و مدیریت حافظه و ... که گفتم، برنامه‌نویسی ++C با استفاده از ابزارها و کتابخانه‌های آماده درست است به اندازه سی‌شارپ سریع نیست ولی به اندازهٔ کافی rapid است، خوشبختانه هم Gtk هم Qt دارای برنامهٔ designer هستند. فکر می‌کنم MFC در ویندوز هم یک طراح دارد. قابلیت auto completion هم که اکثر ویرایشگرهای جدید دارند.

این چیزهایی که من در بالا گفتم (روش برنامه‌نویسی در ++C و وجود ابزارها برای توسعهٔ سریعتر)، در رد طاقت‌فرسا بودن کار با ++C بود.
جالب بود، ولی هر چقدر از C++ تعریف کنی باز هم سی شارپ در خیلی کار ها زودتر و ساده تر به جواب می رسد. ور در واقع عقلانی نیست که در برخی کارها از CPP استفاده کنیم.

هر چند من خیلی CPP رو دوست دارم. ولی الان اکثرا سی شارپ کار میکنم ...

[eshpilen]

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


همهٔ این‌هایی که من نوشتم را می‌توانید با ++C کسب کنید در ظاهری متفاوت از آنچه در ++C و جاوا و ... وجود دارند و به روشی متفاوت.بله و بنظرم سخت تر و پیچیده تر.

نمیدونم چرا شما اصرار دارید بگید سی++ در تمام این موارد نزدیک سی شارپ هست. از طرف دیگه هرکس سی++ کار باشه میگه که این زبان مال حرفه ایهاست و نه تازه کارها. بنابراین میشه گفت یادگیری و استفاده از سی شارپ در کل ساده تره.


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

[eshpilen]

بطور مثال یه نگاه سرسری به مقالهء ویکیپدیا درمورد auto_ptr میکنیم تا یادمون بیاد چی بود و چه خواص و کاربردهایی داشت.
خب یه قطعه کد همین اولش:


int main(int argc, char **argv)
{
int *i = new int;
auto_ptr<int> x(i);
auto_ptr<int> y;

y = x;

cout << x.get() << endl; // Print NULL
cout << y.get() << endl; // Print non-NULL address i
}
فکر نمیکنم نیازی به توضیح باشه که برای یک کار ساده در اینجا چقدر کد و منطق مورد نیاز بوده. همینکار در سی شارپ چقدر کد میخواد و به چه آگاهی و تدابیری نیاز داره؟ هیچی! شما بسادگی شیء مورد نظر رو مستقیما ایجاد میکنید و استفاده میکنید و نیازی نیست نگران چیز دیگری هم باشید.
توضیحاتش رو هم نگاهی بکنیم:

The raw pointer i in the example should not be deleted, as it will be deleted by the auto_ptr that owns the reference.


خب اینجا میگه باید حواست هم باشه که متغییر i رو قبلا به auto_ptr دادی و دیگه نباید خودت دلیتش کنی.


Notice that the object pointed by an auto_ptr is destroyed using operator delete; this means that you should only use auto_ptr for pointers obtained with operator new. This excludes pointers returned by malloc/calloc/realloc (http://en.wikipedia.org/wiki/Malloc) and arrays, which are allocated by operator new[] (http://en.wikipedia.org/wiki/New_%28C%2B%2B%29) and must be deallocated by operator delete[].


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


Because of its copy semantics, auto_ptr may not be used in STL containers that may perform element copies in their operations.


باید حواست به این نکته هم باشه.

خلاصه در همین مثال کوچک میبینی که چقدر نکته برای دانستن و دقت لازمه و طرف باید از طرز کار تمام اجزاء بصورت مفهومی حداقل سردربیاره. حالا شما چطور میگی این کارها در سی++ در مقایسه با سی شارپ چندان سخت تر و حجیم تر نیست؟ در سی شارپ ما به چقدر از این کدها و دانسته ها و دنگ و فنگ ها نیاز داریم؟ برنامه نویس کدوم یکی از این موارد رو باید حضور ذهن و دقت داشته باشه؟ چه مقدار امکان بروز باگ و خطاهای متداول در این زمینه ها در سی شارپ هست؟

[eshpilen]

مورد دیگه هم که گفتید shared_ptr بود که البته جزو کتابخانهء استاندارد هم نیست (جزو boost هست).
این رفرنس مربوط بهش: http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/shared_ptr.htm

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

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

[eshpilen]

واقعا" دفاعیه ی عالی ای بود.لذت بردم.چند وقت بود کسی اینجوری C++‎‎ رو تو سر C#‎‎ نزده بود.
دوست عزیز بحث توی سر زدن به این شکل نیست و اگر شما دنبال اینطور چیزها هستید دارید وقت و انرژیتون رو تلف میکنید و از واقعیت ها غافل میمونید.
باید به کاربرد نگاه کنیم و اینکه در اون کاربردی که زبانی داره واقعا چقدر کار رو برای مردم راحت میکنه.
مثلا PHP رو همه زبان حقیری میدونن؛ ولی غیر از اینه که یکی از بهترین زبانها برای تامین نیازهای عمومی حیطهء اپلیکیشن نویسی وب در مقیاس کوچک نیازهای متداول بوده؟ چه زبانی برای این کاربردها مناسبتر بوده و اگر واقعا مناسبتر بوده چرا بجاش PHP فراگیر شده؟ بطور مثال چرا جاوا بجاش قرار نگرفت؟ اینکه یه زبانی راحت باشه و حتی آدمهای ناشی و مبتدی هم بتونن ازش استفاده کنن هیچ ضعفی نیست. چون زبان یک ابزاره و هرچقدر راحتتر باشه براش یه مزیته. حالا اگر کاری باشه که اون زبان بخاطر سادگی و محدودیت از پسش برنیاد آدم از یک زبان دیگه که قویتر و حرفه ای تر باشه بجاش استفاده میکنه. اما حتی یک آدم فوق حرفه ای هم احتمالا PHP رو برای کارهای کوچک معمولی کاملا کافی و راحتتر و سریعتر میبینه و مسئلهء دیگه کثرت هست که باعث میشه آدم بخاطر شغل و درآمد و کمک به عموم مردم هم که شده یک زبانی رو که اینقدر عمومی و محبوب هست یاد بگیره و استفاده کنه.
PHP جرمی مرتکب نشده که خیلی حرفه ای نیست و از پس یک کارهایی برنمیاد. PHP یک زبان هوشمندانه برای پاسخگویی بهینه به نیازهای بخش بزرگی از مردم بوده و باید بهش به چشم یک زبان موفق و کاربردی نگاه کرد. همونطور که اگر پراید نبود الان خیلی از مردم از داشتن اتومبیل محروم بودن یا محیط زیست بیشتر آلوده میشد و منابع زمین سریعتر تحلیل میرفت.
آیا ما میتونیم بطور مثال سی++ رو باوجود اینهمه امکانات و قدرت جایگزین مناسبی برای PHP بدونیم؟ آیا اینکه بیایم مقایسه کنیم و بقول شما سی++ رو توی سر PHP بزنیم که کار خیلی راحتی هم هست، کار معنا دار و مفیدی میتونه باشه؟
خلاصه بگم که من منکر قدرت و کاربردهای انحصاری سی++ نیستم. اما سی شارپ نیامده تمام کارهای سی++ رو انجام بده. بلکه اومده اول با تمرکز روی یک حیطهء خاص که اپلیکیشن نویسی عمومی روی ویندوز هست. در این حیطه با ویژگیهایی که داره انتخاب بهینه تری نسبت به سی++ بنظر میرسه. کاری که زبانهایی مثل PHP کردن هم همین بود. اومدن یک حیطه ای رو که قبلا با همین زبانهای عمومی مثل سی و سی++ انجام میشد رو تسخیر کردن بخاطر راحتی و سرعت برنامه نویسی بیشتری که داشتن.
ضمنا من تاحالا برنامه های جالب و مجهزی رو دیدم که تحت دات نت نوشته شدن و سرعت کافی هم دارن. فکر نمیکنم انتخاب سی شارپ و دات نت برای این کاربردها هیچ محدودیتی ایجاد بکنه.
شاید شما بگید سی++ کافی بوده و خلاء ای وجود نداشته و نیازی به بوجود آمدن زبانی مثل سی شارپ نبوده.
اما من به دلایلی که در بالا گفتم معتقدم و استدلال میکنم که اینطور نیست. یک خلاء وجود داشت و باید حداقل برنامه نویسی اپلیکیشن های عادی دسکتاپ هم مثل برنامه نویسی وب عادی که با آمدن زبانی مثل پی اچ پی راحت شد راحتتر میشد. هرچند زبانهایی مثل VB هم وجود داشتن، اما بنظرم از نظر امکانات سینتاکس بیش از حد ضعیف بودن و قابل مقایسه با منطق و توان و گستردگی کاربرد سی شارپ نیستن. و البته فریمورک دات نت در کل با هدف و خواصی که داره. هرچند من زیاد به کاربردهای دیگر و گستردگی هدف دات نت اعتقادی ندارم و بیشتر از سی شارپ و دات نت در کاربرد اپلیکیشن نویسی ویندوز دفاع میکنم. اصلا برام هم مهم نیست دات نت باشه یا Native. مهم اینه با سی شارپ بتونی اپلیکیشن ویندوزی بنویسی و خواص مطلوبی رو که ذکر کردیم داشته باشه.

[PC2st]

واقعا" دفاعیه ی عالی ای بود.لذت بردم.چند وقت بود کسی اینجوری C++‎ رو تو سر C#‎ نزده بود.
خوشحالم که دفاعیهٔ بدی از آب در نیامده :لبخند: ولی هدف من زدن در سر سی‌شارپ نبود.
نمی‌خواستم ++C به عنوان یک زبان طاقت‌فرسا در نوشتن برنامه‌های کاربردی تلقی شود (نمی‌گویم از سی‌شارپ راحت‌تر است اینکار).
سی‌شارپ و دات‌نت را سرکوب نمی‌کنم، اما واقعیت اینه که برای کاربردهای خاصی گرد هم آورده شده...


جالب بود، ولی هر چقدر از C++‎ تعریف کنی باز هم سی شارپ در خیلی کار ها زودتر و ساده تر به جواب می رسد. ور در واقع عقلانی نیست که در برخی کارها از CPP استفاده کنیم.

انصافا خود شما مقایسه کنید.
++C یک زبان برنامه‌نویسی برای نوشتن application بوده و می‌توان برنامه‌های cross platform را با آن نوشت. حال آیا این توجیه‌پذیر است که برای نوشتن application از سی‌شارپ استفاده کرده و خود را محصور در یک پلت‌فرم خاص به نام ویندوز کنیم. در واقع هرآنچه در سی‌شارپ یادگرفته‌ایم را با ترک ویندوز به زباله‌دان خواهیم ریخت. به نظر من یک بار آموختن و همه‌جا استفاده کردن بهتر است. منظور من گنو/لینوکس نیست منظور من همهٔ ابزارها و سیستم‌عامل‌هایی است که وجود دارند. مهمترین و تنها ایرادی که من از این زبان می‌گیریم همین است. پروژهٔ مونو هم که حرفش را نزنید چون واقعاً جای خالی NET Framework. را در سایر پلت‌فرم‌ها پر نمی‌کند (و نمی‌تواند).


نمیدونم چرا شما اصرار دارید بگید سی++ در تمام این موارد نزدیک سی شارپ هست. از طرف دیگه هرکس سی++ کار باشه میگه که این زبان مال حرفه ایهاست و نه تازه کارها. بنابراین میشه گفت یادگیری و استفاده از سی شارپ در کل ساده تره.
من سالها پیش که بدجور خودم را درگیر سی‌شارپ کرده بودم. می‌خواستم یک برنامهٔ بسیار ساده برای نواختن نت‌های MIDI بنویسم (چیزی شبیه به پیانو). جالب این بود که هیچ کلاس یا تابعی در دات نت برای اینکار وجود نداشت (طبیعی بود و هست). باید از توابع API ویندوز استفاده می‌کردم. خوب چرا خودم را عذاب بدهم؟ مستقیم از ++C استفاده کنم. تفکر شما در رابطه با کامل بودن NET Framework. بعد از مدتی از بین خواهد رفت. دات‌نت فریم‌ورک برای اهداف خاصی توسعه‌داده شده.




ابتدا باید بدانیم برای چکاری نمی‌خواهیم از اشاره‌گر استفاده کنیم:
۱) برای کار با آرایه‌ها، از STL استفاده کنیم روش‌های کار با آرایه در C را فراموش کنیم (در صورت نیاز بطور مستقیم از آرایه استفاده کنیم).
۲) برای کار با ورودی، خروجی، رشته‌ها و ... از STL و کتابخانهٔ استاندارد استفاده کنیم.
۳) برای موارد خاصی که واقعا نیاز به اشاره‌گر است:


از کلاس auto_ptr استفاده کنید و در صورت نیاز سایر روش‌های موجود در فایل سرآیند smart_ptr برای استفاده غیر مستقیم از اشاره‌گر (روش دوم (بعدی) معمولا کاربردی‌تر و رایج‌تر است).
برای کاری که نیاز است با اشاره‌گر سر و کله بزند، یک کلاس تعریف کنیم. همهٔ کارهای مورد نیاز را از طریق آن کلاس و توابع موجود در آن، انجام خواهیم داد. هم کدها تمیز خوانا خواهد شد هم design بهتری برای برنامه به کار گرفته شده است و اصول شیئ‌گرایی هم رعایت شده. بطور مثال:



typedef unsigned int uint;

class IndirectPtr
{
SomeType* data;

public:

A ()
{
data = new SomeType ("A", 1);
}

uint get_number_of_attempts ();
void set_length (uint value);
void set_charge_value (int value);
void try_and_make ();

~A ()
{
delete data;
}
};

uint func ()
{
IndirectPtr hidden_ptr;
hidden_ptr.set_length (14);
hidden_ptr.set_charge_value (8);
hidden_ptr.try_and_make ();
return hidden_ptr.get_number_of_attempts ();
}
در تابع func پس از ایجاد hidden_ptr نیازی به حذف نیست، چونکه اشاره‌گر نیست و اشاره‌گر واقعی درون خود کلاس مدیریت شده... (دات‌نت هم به همین روش با اشاره‌گرها یا کدهای unsafe کار می‌کند و آنها را درون کلاس قرار داده...)

[PC2st]

خب اینجا میگه باید حواست هم باشه که متغییر i رو قبلا به auto_ptr دادی و دیگه نباید خودت دلیتش کنی.

Notice that the object pointed by an auto_ptr is destroyed using operator delete; this means that you should only use auto_ptr for pointers obtained with operator new. This excludes pointers returned by malloc/calloc/realloc (http://en.wikipedia.org/wiki/Malloc) and arrays, which are allocated by operator new[] (http://en.wikipedia.org/wiki/New_%28C%2B%2B%29) and must be deallocated by operator delete[].

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

Because of its copy semantics, auto_ptr may not be used in STL containers that may perform element copies in their operations.

باید حواست به این نکته هم باشه.

خلاصه در همین مثال کوچک میبینی که چقدر نکته برای دانستن و دقت لازمه و طرف باید از طرز کار تمام اجزاء بصورت مفهومی حداقل سردربیاره. حالا شما چطور میگی این کارها در سی++ در مقایسه با سی شارپ چندان سخت تر و حجیم تر نیست؟ در سی شارپ ما به چقدر از این کدها و دانسته ها و دنگ و فنگ ها نیاز داریم؟ برنامه نویس کدوم یکی از این موارد رو باید حضور ذهن و دقت داشته باشه؟ چه مقدار امکان بروز باگ و خطاهای متداول در این زمینه ها در سی شارپ هست؟
دوست عزیز، در جواب زیاد عجله می‌کنید :لبخند: این که نیاز به گفتن نبود و نکته‌ای وجود ندارد که بخواهیم نگران به یاد داشتن آن باشیم. متغیرهای x و y در اینجا اشاره‌گر نیستند که بعدا بخواهیم آنها را حذف کنیم! و اشتباه شما در همینجا بود.


auto_ptr<int> x(i);
auto_ptr<int> y;

x و y در جایی که استفاده می‌شوند، به عنوان یک اشاره‌گر نیستند، بلکه مثل یک متغیر عادی عمل می‌کنند و نیازی نیست که آنها را delete کنیم، (اصلا شما خبری از وجود علامت * در آنها می‌بینید که بخواهید آنها را delete کنید؟) به نظر من هیچ نکتهٔ عجیبی در اینجا وجود ندارد که چرا نباید آنها را delete کرد و این یک قانون محض و اولیه در ++C است.

تفاوت متغیرهای به ظاهر عادی x و y در این است که از نوع auto_ptr هستند و در باطن همانند یک اشاره‌گر هستند و در حافظه heap قرار دارند (در واقع هم در heap هستند و هم در stack و حافظه‌ای که در stack اشغال می‌کنند بسیار کم است و همواره عدد ثابتی مثلا ۴ بایت است).

[PC2st]

ببینید دوست عزیز یعنی رفتن به سی‌شارپ و کار کردن با آن یعنی تمام!؟ همه چیز بهشت می‌شود؟ خیر. تازه شما باید با framework دات نت کار کنید و با زیر و بم آن آشنا شوید. متاسفانه شما فکر می‌کنید که وجود چیزهایی مثل auto_ptr و غیره و ظاهر شدن این کلاس‌ها و مستندات این‌ها فقط مربوط به ++C است! باور کنید که framework دات نت هم مستندات دارد، هم باید با کلاس‌های آن آشنا شوید. تنها تفاوت در این است که در مستندات ++C شما با vector و base_string و iostream و ... آشنا می‌شوید اما در سی‌شارپ شما با کلاس array (بله!‌ در واقع آرایه‌ها در سی‌شارپ همان کلاس array هستند :چشمک:) و string و کلاس‌های مشابه آشنا می‌شوید. به هر حال چه در ++C چه در سی‌شارپ شما باید مستندات را مطالعه کنید.

در رابطه با shared_ptr در استاندارد بعدی ++C قرار خواهد گرفت و هم اکنون خیلی وقت است که می‌توانید از آن استفاده کنید در فضای نام std::tr1 (البته اگر کامپایلر شما مال ۲ سال پیش نباشد). بحث استاندارد ++C شد... که تغییرات بسیار خوبی اعمال خواهد شد (و اکثر کامپایلرها از جمله GCC در افزودن زودهنگام این قابلیت‌ها اقدام کرده‌اند) و همچنین مایکروسافت هم همچنان نسخه‌های جدید و بروزشده‌اش از MFC را می‌دهد و پشتبانی از استاندارد آینده ++C را به سختی انجام می‌دهد.

آن امنیتی که شما به دنبال آن هستید، زبان برنامه‌نویسی نمی‌تواند برای شما تولید کند. ولی اگر منظور شما از امن بودن این است که زبان برنامه‌نویسی نگذارد شما اشتباه کنید. به نظر من برنامه‌نویسی که نمی‌داند چه می‌کند، مهم نیست که اشتباه بکند یا نکند چون در هر صورت خروجی کار جالب نخواهد بود.

[FastCode]

آن امنیتی که شما به دنبال آن هستید، زبان برنامه‌نویسی نمی‌تواند برای شما تولید کند.
آی گفتی.
من طبق تجربه ای که با دیدن سورسهای دیگران داشتم به وفور دیدم که کسایی که مثلا" با C++ مسلط اند به هیچ عنوان مشکل SQLInjection ندارند و به عکس مسانی که میگویند من فلان موقع که .Net 2 هنوز نیومده بود .Net کار میکردم کدهایی پر از vulnerability دارند.توی یکی از مجله های برنامه نویس که فکر میکنم همین شماره آخری بود آقای موسوی مطلب خیلی جالبی در این مورد داشتن.که خود بنده نمره 10 گرفتم==> پس نمیتونم خیلی در این مورد ادعا بکنم.
ناپلئون بناپارت:هر کس برای چیزی میجنگد که ندارد.

[eshpilen]

در تابع func پس از ایجاد hidden_ptr نیازی به حذف نیست، چونکه اشاره‌گر نیست و اشاره‌گر واقعی درون خود کلاس مدیریت شده... (دات‌نت هم به همین روش با اشاره‌گرها یا کدهای unsafe کار می‌کند و آنها را درون کلاس قرار داده...)
روش بدی نیست. ممنون از کد و صرف وقتتون. ولی به اینصورت ما باید هرچیزی رو که روی heap اختصاص داده میشه توی یه کلاس بذاریم. این خودش مقداری سربار ایجاد میکنه. یعنی مصرف منابع زیاد میشه و سرعت پایین میاد. پس مزایای سرعت و مصرف کمتر حافظه سی++ حداقل مقداری کمتر میشن. میدونیم که بخشی از بهینه بودن اینطور زبانها بخاطر نداشتن اینطور افزونگی های حجمی و اجرایی هست.


دوست عزیز، در جواب زیاد عجله می‌کنید :لبخند: این که نیاز به گفتن نبود و نکته‌ای وجود ندارد که بخواهیم نگران به یاد داشتن آن باشیم. متغیرهای x و y در اینجا اشاره‌گر نیستند که بعدا بخواهیم آنها را حذف کنیم! و اشتباه شما در همینجا بود.


auto_ptr<int> x(i);
auto_ptr<int> y;
x و y در جایی که استفاده می‌شوند، به عنوان یک اشاره‌گر نیستند، بلکه مثل یک متغیر عادی عمل می‌کنند و نیازی نیست که آنها را delete کنیم، (اصلا شما خبری از وجود علامت * در آنها می‌بینید که بخواهید آنها را delete کنید؟) به نظر من هیچ نکتهٔ عجیبی در اینجا وجود ندارد که چرا نباید آنها را delete کرد و این یک قانون محض و اولیه در ++C است.

بابا x و y رو نگفتم که. طبق متن نکته ای که خودش داده، منظورم i بوده.
البته بنظرم این مورد مهمی نیست چون میشه i رو به اینصورت تعریف کرد: auto_ptr<int> x(new int);
البته اینکه در مثال i رو خارجش تعریف کرده و بصورت مستقیم هم در دسترس هست شاید دلیلی داشته و کاربردهایی هم داریم که اینطور نیاز باشه.
بهرحال دست کم گرفتی. فکر میکنی بنده قبلا نمیدونستم auto_ptr چیه یا نمیتونم ساختار کد رو بفهمم؟ چرا قبلا خونده بودم اما چون کار عملی نداشتم حضور ذهن کافی نداشتم.

بهرحال همینطور که میبینی اینا چیزایی هست که برنامه نویس بالاخره باید آگاه باشه و دقت کنه و بکار ببره.


ببینید دوست عزیز یعنی رفتن به سی‌شارپ و کار کردن با آن یعنی تمام!؟ همه چیز بهشت می‌شود؟ خیر. تازه شما باید با framework دات نت کار کنید و با زیر و بم آن آشنا شوید. متاسفانه شما فکر می‌کنید که وجود چیزهایی مثل auto_ptr و غیره و ظاهر شدن این کلاس‌ها و مستندات این‌ها فقط مربوط به ++C است! باور کنید که framework دات نت هم مستندات دارد، هم باید با کلاس‌های آن آشنا شوید.
من تا حالا رفرنس زبان سی شارپ رو خوندم و بخش بزرگی از مزایا در سینتاکس و مفاهیم اون منعکس هست. رفرنس کلاسهاش رو تازه شروع کردم ولی تا اینجا که دیدم بیشتر پیچیدگی های فنی توسط کامپایلر و runtime دات نت مدیریت میشه و در نتیجه سینتاکس زبان و چگونگی کار کردن و اینترفیس کلاسها خیلی ساده تر شده. شما فکر میکنید مدیریت حافظه کم چیزی هست؟ خودتون برای یک متغییر heap مجبورید یک کلاس تعریف کنید.
نگید که در سی شارپ هم خیلی چیزها بصورت داخلی با همین روشها پیاده شده (که البته فکر میکنم قضیه جور دیگری و پیچیده تر و کاملتر باشه). ما میخوایم کار برنامه نویس راحت و سریع و برنامه هاش تاحد امکان الگوریتم و انتزاع محض برای مسئلهء اصلی باشه و چیزای اضافه نداشته باشه.


همچنین مایکروسافت هم همچنان نسخه‌های جدید و بروزشده‌اش از MFC را می‌دهد و پشتبانی از استاندارد آینده ++C را به سختی انجام می‌دهد.
من توی همین فروم از یک کاربر حرفه ای چیز دیگه ای خوندم. یادم نیست دقیقا کی بود و نمیدونم چطور پستش رو پیدا کنم. فکر میکنم نوشته بود میکروسافت در آینده دیگه win api رو داکیومنت نمیکنه. البته MFC احتمالا بحثش فرق میکنه ولی بهرحال اینکه فعلا یک سطح رو به اینصورت رها کرده زیاد با حرفهای شما در زمینهء لزوم پشتیبانی سخت در دراز مدت از فناوریهای قدیمی تر جور درنمیاد.


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

[eshpilen]

آی گفتی.
من طبق تجربه ای که با دیدن سورسهای دیگران داشتم به وفور دیدم که کسایی که مثلا" با C++‎ مسلط اند به هیچ عنوان مشکل SQLInjection ندارند و به عکس مسانی که میگویند من فلان موقع که .Net 2 هنوز نیومده بود .Net کار میکردم کدهایی پر از vulnerability دارند.توی یکی از مجله های برنامه نویس که فکر میکنم همین شماره آخری بود آقای موسوی مطلب خیلی جالبی در این مورد داشتن.که خود بنده نمره 10 گرفتم==> پس نمیتونم خیلی در این مورد ادعا بکنم.
ناپلئون بناپارت:هر کس برای چیزی میجنگد که ندارد.
اینکه بگیم کسانی که با سی++ حرفه ای کار کردن برنامه نویسان بهتری هستن اغلب درسته.
اما اینکه بگیم این ثابت میکنه برای برنامه نویسی اپلیکیشن از سی++ استفاده کرد، استدلال کاملا غلطی هست.
یک برنامه نویس حرفه ای سی++ با یاد گرفتن سی شارپ مسلما میتونه برنامه های بی نقصی بنویسه و در عین حال با راحتی و سرعت بیشتری اینکار رو انجام بده.
نهایتش میتونیم بگیم باید هر دو زبان رو آموخت و از پایه شروع کرد. اما بعدش میشه درهرموردی از زبانی که مناسبتره استفاده کرد.
ضمنا شاید بخاطر اینکه سی و سی++ زبانهای خیلی قدیمی تری و پرکاربرد و دارای انبوهی از برنامه نویسان در تمام سطوح هستن و انبوه مستندات و منابع و نمونه کدهای خوب دارن، مفاهیم مورد نیاز رو بیشتر با یادگیری و کار کردن عملی با این زبانها میشه بدست آورد.

[PC2st]

روش بدی نیست. ممنون از کد و صرف وقتتون. ولی به اینصورت ما باید هرچیزی رو که روی heap اختصاص داده میشه توی یه کلاس بذاریم. این خودش مقداری سربار ایجاد میکنه. یعنی مصرف منابع زیاد میشه و سرعت پایین میاد. پس مزایای سرعت و مصرف کمتر حافظه سی++ حداقل مقداری کمتر میشن. میدونیم که بخشی از بهینه بودن اینطور زبانها بخاطر نداشتن اینطور افزونگی های حجمی و اجرایی هست.این میزان سربار بسیار ناچیز و قابل صرف نظر است. در مقابل این سربار ناچیز (تقریبا هیچ) مزایای خوبی به ما تحویل داده خواهد شد.


بابا x و y رو نگفتم که. طبق متن نکته ای که خودش داده، منظورم i بوده.
البته بنظرم این مورد مهمی نیست چون میشه i رو به اینصورت تعریف کرد: auto_ptr<int> x(new int);
البته اینکه در مثال i رو خارجش تعریف کرده و بصورت مستقیم هم در دسترس هست شاید دلیلی داشته و کاربردهایی هم داریم که اینطور نیاز باشه.
بهرحال دست کم گرفتی. فکر میکنی بنده قبلا نمیدونستم auto_ptr چیه یا نمیتونم ساختار کد رو بفهمم؟ چرا قبلا خونده بودم اما چون کار عملی نداشتم حضور ذهن کافی نداشتم.عجله از من بود و زود قضاوت کردم.
بهرحال در این مورد، همانطور که گفتید بهتر است در استفاده از auto_ptr در لحظهٔ تعریف متغیر، آن را بطور مستقیم مقدار دهی کنیم و قاعدهٔ سختی نیست.
ضمن آنکه کسی که برنامه‌نویسی ++C می‌کند، خودش از قبل انتظار این رفتار را خواهد داشت و نکتهٔ متناقضی با سایر رفتارهای ++C نیست.


نگید که در سی شارپ هم خیلی چیزها بصورت داخلی با همین روشها پیاده شده (که البته فکر میکنم قضیه جور دیگری و پیچیده تر و کاملتر باشه). ما میخوایم کار برنامه نویس راحت و سریع و برنامه هاش تاحد امکان الگوریتم و انتزاع محض برای مسئلهء اصلی باشه و چیزای اضافه نداشته باشه.کتابخانهٔ NET Framework. را می‌توان به عنوان یک لایه بر روی APIهای ویندوز در نظر گرفت و معمولا کلاس‌ها به عنوان wrapper عمل می‌کنند.


من توی همین فروم از یک کاربر حرفه ای چیز دیگه ای خوندم. یادم نیست دقیقا کی بود و نمیدونم چطور پستش رو پیدا کنم. فکر میکنم نوشته بود میکروسافت در آینده دیگه win api رو داکیومنت نمیکنه. البته MFC احتمالا بحثش فرق میکنه ولی بهرحال اینکه فعلا یک سطح رو به اینصورت رها کرده زیاد با حرفهای شما در زمینهء لزوم پشتیبانی سخت در دراز مدت از فناوریهای قدیمی تر جور درنمیاد.یا آن کاربر حرفه‌ای نبوده یا اینکه می‌دانیم حرفه‌ای‌ها هم اشتباه می‌کنند. :چشمک:


زبان برنامه نویسی خوب جایی که امکان ضرورت و کاربرد مشروع و مفیدی نداره نباید اجازهء اشتباه رو به برنامه نویس بده. حتی حرفه ای ترین برنامه نویسها هم اشتباه میکنن (حتی اشتباهات پیش پا افتاده)؛ ضمنا اگر این مسئله بعهده زبان و محیط باشه دیگه برنامه نویس خیالش از اون بابت راحته و میتونه فکرش رو روی مسئلهء اصلی متمرکزتر کنه. این ربطی به حرفه ای نبودن برنامه نویس نداره. حتی یک برنامه نویس حرفه ای که سالها هم تجربه داره بدش نمیاد که بخش از نگرانی ها و دقت و تمرکز مورد نیاز روی مسائل فرعی رو برطرف بکنه.
یک اتومبیل اگر اجازه بده سیستم فرمان و اسکلت بندی چرخهای جلو بیش از حد بچرخه، دیگه امن نیست و حتی حرفه ای ترین راننده ها هم چنین چیزی رو منطقی نخواهند دونست. چرا؟ چون وقتی شما چرخهای جلو رو 90 درجه یا بیشتر بچرخونید هیچ مزیت و کاربردی که نداره هیچ، بلکه باعث تصادف یا صدمهء فیزیکی به اتومبیل میشه. هرچند این قابلیت شاید در پارک کردن بدرد بخوره :متفکر: اما بهرحال در حال حرکت نباید چنین امکانی وجود داشته باشه چون بسیار خطرناک و بدون کاربرد مفیدی هست.
البته درمورد سی++ این امکانها نقص زبان نیستن چون سی++ برای مثلا برنامه نویسی سیستمی هم بکار میره و با سی هم باید سازگاری داشته باشه.
اما سی شارپ دیگه تعهد و هدفی مبنی بر سازگاری با سی نداره و قرار نیست کسی باهاش برنامهء سیستمی بنویسه. خب من هم گفتم که زبان ++C کلاس‌ها و ابزارهایی در اختیار برنامه‌نویس قرار می‌ده که مشکلی مثل همان «فرمان اتومبیل با چرخش ۹۰ درجه» پیش نیاد. همچنین در زبان C این اجازه اشتباهی که داده می‌شود در مقابل انتخاب و انعطاف بیشتر و performance مبادله شده است.

[eshpilen]

راستی Mono ظاهرا پیشرفت خوبی داره از نظر فنی. هرچند چندان بروز نیست از نظر نسخه، ولی پیاده سازیهای چشمگیر و نسبتا کاملی داره تا اونجا که من در این مورد مطالبی دیدم.
بنظر من میاد که گسترش و پیاده سازی های آزاد/بازمتن دات نت و استقبال از اون در محیط GNU/Linux میتونه چشمگیر باشه. یعنی وقتی با جاوا با اونهمه عظمت و سابقه مقایسه میکنم بنظر میاد دات نت خیلی زود پذیرفته شد و خیلی سریع پیاده سازیهای آزاد اون رشد کردن. البته شایدم من اشتباه میکنم!
درحال حاضر یکی از موانع مهمی که در سر راه پذیرش دات نت در جامعهء نرم افزار آزاد و گنو/لینوکس وجود داره همون ابهامات و نقصهای قانونی قضیه هست که ریچارد استالمن در اینمورد صحبت کرده و اعلام کرده بهتره تاحد ممکن از استفاده از دات نت در نرم افزارهای آزاد و گنو/لینوکس پرهیز بشه؛ بنظر من نظر ایشون مسلما روی رشد استفاده از دات نت تاثیر منفی مشهودی میذاره. البته اینهم اگر میکروسافت با نرم افزار آزاد همکاری بیشتری بکنه و ابهامات رو برطرف بکنه و پشتوانه های قانونی لازمه رو بده برطرف میشه. هرچند فعالیتی در این زمینه بنظر نمیرسه انجام بشه!!
بهرحال بعید نیست دات نت همینطور کم کم جای پای خودش رو در دنیای لینوکس هم باز بکنه.
نمیشه گفت دات نت مستقل از پلتفرم نیست. بهرحال بیشتر مشکل قانونی هست و عدم اعتماد به میکروسافت (که کاملا منطقی هم هست).
الان چیزی زیاد معلوم نیست. بهرحال ما جاوا رو هم داریم که خیلی با سابقه هست و اونم در این قضیه نقش ایفا میکنه. یعنی بنظرم برنامه نویسان برای خیلی کارها، بجای دات نت میتونن از جاوا استفاده کنن که فکر میکنم این مشکلات قانونی و ابهامات رو نداشته باشه و در گنو/لینوکس بتونه پایگاه خوبی پیدا کنه (الان وضعش چطور؟ مثلا بصورت پیشفرض روی توزیعهای اصلی گنو/لینوکس نصب هست؟)

[PC2st]

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

[eshpilen]

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

نمونهء منابعی هم که میتونم برای این قضایا معرفی کنم اینهاست:
http://barnamenevis.org/forum/showthread.php?t=222367
http://en.wikipedia.org/wiki/Microsoft_Community_Promise
http://en.wikipedia.org/wiki/Mono_%28software%29

مثلا از منبع آخر این قسمت رو نقل میکنم:

The core components include the C# grammars and semantics and the Common Language Infrastructure. These components are based on the Ecma-334 and Ecma-335 standards,[20] allowing Mono to provide a standards compliant, free and open source CLI virtual machine. Microsoft issued a statement that covers both standards under their Community Promise license.

[مرتضی پیروزی]

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

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

[PC2st]

من الان این مطالب را خواندم، اطلاعات خوبی بود... منظور من همین بود.


الان کلا این قضیه در ابهام و بلاتکلیفی به سر میبره همچنان. در ظاهر میکروسافت تعهد قانونی داده و از گسترش دات نت اونم بصورت آزاد ابایی نداره، اما در باطن نیتش کاملا مشخص نیست یا اینکه در آینده نظرش عوض بشه و کار برعکسی بکنه. اگر این تعهد قانونی بقدر کافی محکم و فراگیر بود دیگه از این موارد هراسی نبود. ضمنا بله میکروسافت جاهای دیگه مثلا صریحا اعلام کرده که سی شارپ رو بخشی از دارایی خودشون میدونن و اینکه روی چیزی که هزینه و تحقیق و تولید میکنن قصد کسب درآمد دارن. بخاطر همین تناقضها و ابهامات، کسی نمیتونه به میکروسافت که دشمن سابقه دار و اثبات شده و ذاتی نرم افزار آزاد و بازمتن هست اعتماد کنه.
... همینطوره و متاسفانه نمی‌شه یک نرم‌افزار آزاد را بر مبنای پلت‌فرم patentشده توسعه داد. با توجه به اینکه مایکروسافت هم مدعی است نرم‌افزارهای آزاد حقوق پتنت‌هایش را نقض کردند! و طبیعی هست که نباید انتظار موفقیت مونو را در چنین فضایی داشته باشیم. مایکروسافت قسمت‌های مهم دات‌نت را هنوز برای استفاده آنها تضمین نکرده...


البته این یک حق عرفی و انسانی براش هست. هیچ کس نمیتونه از این بابت مورد سرزنش قرارش بده.
منظور پتنت‌های اعمال شده از سوی مایکروسافت هست که دست و پا گیر شده... یعنی هیچ‌کس بدون اجازهٔ مایکروسافت حق نداره یک نمونه از NET Framework. را برای سایر سیستم‌عامل‌ها و نیاز خودش تولید کنه... همین ناول که توسعهٔ مونو را بر عهده گرفته، قبلا جریمهٔ این کار را پرداخت کرده! البته میشه انتظار داشت که در ادامه روند توسعه، دوباره با چنین مشکلاتی روبرو شوند.

[مرتضی پیروزی]

همین ناول که توسعهٔ مونو را بر عهده گرفته، قبلا جریمهٔ این کار را پرداخت کرده! البته میشه انتظار داشت که در ادامه روند توسعه، دوباره با چنین مشکلاتی روبرو شوند.والا دوست من مونو رو که پشتیبانی رسمی نمیکنن و اگر بخوان بکنن باید لطف کنی 13000 دلار بهشون بدی!
والا بنده خدا مایکروسافت حق داره دیگه، بیای اموالش رو برداری مفت مفت ازش پول دربیاری!
راستی حتی فرمت MP3 هم تجاری هست و شما حق استفاده از اون توی نرم افزارتون رو به رایگان نداری!!
و باید لایسنس اون رو بخری.
دوستان جسارت نشه، ولی دیگه این نرم افزار آزادی هاهم شورش رو در آوردن! در بعضی مواقع همه چیز رو به مسخره میگیرن.......... وقتی توی بیزنس کم میارن شروع میکنن به مایکروسافت فحش دادن!
آقا من نه خودم مایکروسافتی هم نه فامیلام! ولی خوب دوست نداره محصولش رو توی جای دیگه بده، زوره مگه؟؟ خدایی خنده دار نیست؟؟ عین این بچه کلاس اولی ها که میگن: " آقا اجازه، فلانی به من بستنی نمیده" دارن غر میزنن که چرا مایکروسافت نمیذاره با ما دات نت برنامه بنویسیم!

[PC2st]

بحث سر این نیست که مایکروسافت حق دارد یا ندارد :چشمک:

بحث سر اینه که چرا مونو فراگیر نخواهد شد و چرا برنامه‌های دات‌نت مثل جاوا و پایتون و ... مستقل از سکو نیست (تا آن اندازه).

[مرتضی پیروزی]

بحث سر اینه که چرا مونو فراگیر نخواهد شد و چرا برنامه‌های دات‌نت مثل جاوا و پایتون و ... مستقل از سکو نیست (تا آن اندازه).
بحث نداره که قربونت برم:لبخند: یک کمپانی یک چیزی تولید کرده و نمیخواد توی سیستم های دیگه ازش استفاده بشه، و اگر استفاده کنی همه اجداد طرف رو میکشه دادگاه:لبخند:

[eshpilen]

مایکروسافت قسمت‌های مهم دات‌نت را هنوز برای استفاده آنها تضمین نکرده...

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

[eshpilen]

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

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



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

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

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

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

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

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

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