C#‎ یا ++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/PNphpB...order-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 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 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 and arrays, which are allocated by operator new[] 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...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 و کتابخانهٔ استاندارد استفاده کنیم.
۳) برای موارد خاصی که واقعا نیاز به اشاره‌گر است:

1. از کلاس auto_ptr استفاده کنید و در صورت نیاز سایر روش‌های موجود در فایل سرآیند smart_ptr برای استفاده غیر مستقیم از اشاره‌گر (روش دوم (بعدی) معمولا کاربردی‌تر و رایج‌تر است).
2. برای کاری که نیاز است با اشاره‌گر سر و کله بزند، یک کلاس تعریف کنیم. همهٔ کارهای مورد نیاز را از طریق آن کلاس و توابع موجود در آن، انجام خواهیم داد. هم کدها تمیز خوانا خواهد شد هم 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 and arrays, which are allocated by operator new[] 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]

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

نمونهء منابعی هم که میتونم برای این قضایا معرفی کنم اینهاست:
https://barnamenevis.org/showthread.php?t=222367
http://en.wikipedia.org/wiki/Microso...munity_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 هایی (پتنت همان ثبت رسمی اختراع است) که تاریخ انقضای آنها فرا رسیده و به حیطهء عمومی ملحق شده اند.
همچنین خیلی مواردی که اصولا به علل مختلف مثل مورد استفاده بودن توسط عموم و روشن نبودن منشاء آنها یا اینکه مخترع آنها را بنام خودش ثبت نکرده بوده است، جزو حیطهء عمومی قرار گرفته اند.
البته چیزهای بدیهی و نسبتا بدیهی که بعضا مورد نیاز اساسی برای کارهای عمومی هستند نیز قابل ثبت بصورت اختراع یا کپی رایت نیستند و بنابراین جزو حیطهء عمومی محسوب میشوند.

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