C#‎ یا ++C؟

[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) قرار دهند.