دانلود مقاله مقایسه زبان‌های برنامه‌نویسی # C و جاوا

بسیاری از زبان‌های برنامه‌نویسی امروزی از این قرارند: C++,C ، Javad , C# , COBOL , Microsoft Visual Basic و غیره.

با وجود این همه زبان، یک مهندس نرم‌افزار چگونه تصمیم می‌گیرد که کدامیک از آنها را برای یک پروژه استفاده کند.

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

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

در حالت ایده‌آل، یک زبان برنامه‌نویسی باید بر مبنای توانایی‌های آن جهت اجرای یک کار خاص انتخاب شود و حل یک مشکل باید تعیین کننده زبان باشد.

ما تنها به مقایسه زبان‌های C# و جاوا می‌پردازیم.

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

اگر در زبان قدیمی‌تر ضعف‌هایی وجود دارد و در زبان جدیدتر این ضعف‌ها دیده نمی‌شوند و یا از نظرها پنهان شده‌اند، این مسئله می‌تواند بیانگر انگیزه معماران در انجام برخی تغییرات در زبان جدیدتر باشد.

شناخت این انگیزه اغلب حائز اهمیت است،‌ چرا که در غیر اینصورت انتقاد هدف‌دار از یک زبان غیرممکن می‌شود.

مثلا، اگر ویژگی معروفی که در زبان قبلی وجود داشته از زبان جدیدتر حذف شود، یک تولید کننده برنامه کاربردی ممکن است احساس کند که زبان جدیدتر جایگزین با ارزشی برای زبان قبلی نیست، چرا که قدرت زبان قبلی را ندارد.

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

کاملا طبیعی است که C# در برگیرنده نقاط قوت و ضعف جاوا است، درست مانند جاوا که برگرفته از Objective – C بود و آن هم برگرفته از C و به همین ترتیب.
بنابراین، C# نباید متفاوت از جاوا باشد.

اگر جاوا کامل بود، دیگر دلیلی برای ایجاد C# وجود نداشت.

اگر C# کامل باشد، دیگری دلیلی برای ایجاد زبان برنامه‌نویسی جدیدتر وجود ندارد.

بهرحال، آینده نامشخص است، و هم اکنون C# و جاوا زبان‌های برنامه‌نویسی شی‌ءگرای خوبی هستند.

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

اما هنگام دستیابی به نمونه‌های داده‌ها در C++ است که در پشته ایجاد می‌شوند.

تمامی نمونه‌های کلاس با استفاده از اپراتور جدید در هیپ ایجاد می‌شوند، اما استفاده از delete مجاز نیست چرا که هر دو زبان از روش‌های garbage collection متعلق به خود استفاده می‌کنند.
Garbage Collection
طبیعتا، یاری نکردن حافظه مشکل بزرگی در زبان‌های نظیر C++ است.

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

C# و جاوا هر دو دارای garbage collection توکار هستند.

به عبارتی برای آزادسازی حافظه دیگر نیازی به فراخوانی delete نیست.

هیچ زبانی اجازه تسهیم کردن Object ای را که قابل مصرف است به شما نمی‌دهد.

اما ممکن است از شما خواسته شود تا new را حتی بیشتر از آنچه که دوست دارید، فرا بخوانید.

علت این مسئله آن است که در هر دو زبان تمامی Object ها در هیپ ایجاد می‌شوند، به این معنی که چنین چیزی در هر زبانی قابل قبول نیست.

Class BadaBing
{
Public BadaBing ( )
{
}
}
BadaBing badaBing ( ) ; // You can’t create
temporary data but You must use parens on
a constructor
کامپایلر پیغام کوتاهی را در این باره برای شما می‌فرستد، چرا که شما سعی می‌کنید ذخیره‌سازی موقتی را ایجاد کنید.

باید این کار را انجام دهید:
BadaBing badaBing = new BadaBing ( ) ;
حال badaBoom ساخته شد و دارای حداقل یک مرجع است.

بعد، ممکن است بخواهید تا از دست آن خلاص شوید.
delete BadaBoom; // illegal in C# and
Java – the compiler will complain
تا جائیکه می‌خواهید از badaBoom استفاده کنید، سپس زمانیکه تصمیم می‌گیرید مرجع خود را به دیگری بدهید، garbage colletor شما را از دست آن خلاص می‌کند.

بسیاری از تولید کنندگان برنامه‌های کاربردی از garbage collection شکایت دارند، شاید آنها کنترل می‌خواهند.

شاید با وجود این امکان احساس می‌کنند برنامه‌نویسان واقعی نیستند، چرا که نمی‌توانند Object ای را که ایجاد کرده‌اند، delete کنند.

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

بدون توجه به این دلایل garbage collection دارای مزایایی است که برخی از آنها از این قرارند:
1 عدم یاری حافظه.

این مزیت مشخصی است.

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

2ـ garbage collection تولید کنندگان را تشویق به نوشتن کدهای شی‌ءگرای بیشتر می‌کند.

این یک مزیت ظریف و دقیق است.

مثلا، در C++، تولیدکنندگانی که متدهای کلاس را ایجاد می‌کنند باید داده‌هایی را بازگردانند که معمولا مرجع non-const یا پارامترهای اشاره‌گر را در هنگام اجرای متد تنظیم می‌کنند، یا باید نمونه کلاسی از نوع دیگر را باز گردانند که ترکیبی از تمام داده‌های ضروری را نگاه می‌دارد.

به نظر می‌رسد مورد دوم بهتر از مورد اول باشد.

چه کسی می‌خواهد تابعی با10 پارامتر را فرا بخواند؟

و پارامترهای بیشتری که بین سرویس گیرنده و کد سرویس دهنده رد و بدل می‌شوند، درگیری بیشتری ایجاد می‌کند، که این اصلا خوب نیست.

مثلا، اگر بعدا مشخص شود که تابعی نیاز به بازگرداندن داده‌های بیشتری دارد، تنها لازم است این اجرای تابع با یک افزایش به کلاس مرکب، که ممکن است برای سرویس گیرنده تنها یک recompiler باشد، تغییر داده شود.

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

هنگامیکه آبجکت‌ها با این متد بهتر بازگردانده می‌شوند، معمولا تولید کننده تنها دو گزینش پیش رو دارد: بازگرداندن یک کپی از داده‌های موقت که در تابع ساخته و مقداردهی اولیه می‌شوند، یا ایجاد اشاره‌گر جدید آبجکت در تابع، side – effect کردن مقادیر derefrence شده آن، سپس بازگرداندن اشاره‌گر، که مطمئن است، چرا که کامپایلر، اشاره‌گرها یا داده‌های هیپ را در میان فراخوانی‌های توابع خراب نخواهد کرد.

با وجود اینکه بازگرداندن یک اشاره‌گر دارای مزایایی است (یک سازنده کپی نباید فراخوانی شود بنابراین ممکن است سریعتر باشد، خصوصا با داده‌های بزرگتر، زیر کلاسی از یک نوع اشاره‌گر می‌تواند برای گسترده شدن به فراخوانده بازگردانده شود)، اما در C++ از اشکالات جدی نیز برخوردار است: حال سرویس گیرنده باید با فراخوانی delete در اشاره‌گر بازگشتی، به مدیریت حافظه توجه کند.

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

Ms-help : //MS.

VSCC/MS.MSDNVS/vbcon/html/ Vbcon Reference Counting Garbage Collection Object Lifetime.

htm بهرحال، شمارش مرجع به دلیل نحوه گرامری الگو کاملا رضایت‌بخش نیست، و اگر زمانیکه طرح‌‌های garbage collection جاوا و C# کار می‌کنند، اجراهای شمارش چرخه‌ها را به درستی اداره نکند، وضعیت بدتر هم می‌شود (یک چرخه از شمارش مرجع ساده‌ای استفاده می‌کند: اگر دو آبجکت به یکدیگر ارجاع داشته باشند، و سپس تنها مرجعات بیرونی برای هر دو منتشر شود، هیچ کدام delete نمی‌شوند، زیرا هر کدام یک مرجع دیگر دارند، و هر Object تا زمانیکه شماره مرجع آن به صفر برسد delete نمی‌شود.

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

اما از آنجائیکه هر دو زبان C# و جاوا از garbage collection استفاده می‌کنند، تولید کنندگان تشویق می‌شوند هنگام نوشتن الگوسازی‌های تابع (بجای استفاده از پارامترهای داخلی / خارجی) ارجاع جدید به داده‌ها را باز گردانند، که در اینصورت نیز ترغیب می‌شوند در جائیکه فراخواننده نباید از نوع دقیق داده‌ها اطلاعی داشته باشد، زیر کلاسی از نوع بازگشتی تعریف شده، یا نمونه کلاسی که رابط‌ها را اجرا می‌کند، بازگردانند.

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

3ـ Garbage collection، به اشتراک گذاشتن داده‌ها را ساده‌تر می‌سازد.

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

مشکلاتی که در تعریف مسئولیت‌های clean up وجود دارد از این قرارند: اگر آبجکتA و آبجکتB، pointer C را به اشتراک بگذارند، آیا آبجکتA باید C delete کند یا آبجکتB ؟

مشکل همین حذف کردن است: B,A نباید (و یا نمی‌توانند) C را که از C# یا جاوا، استفاده می‌کند delete کنند.

آبجکت B,A تا زمانیکه لازم باشد از C استفاده می‌کنند، سپس زمانیکه دیگر ارجاعی صورت نمی‌گیرد، سیستم مسئول حذف کردنC است.

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

4 ـ برنامه‌ها باید بطور خودکارصحیح‌تر شوند.

تولید کنندگان برنامه کاربردی می‌توانند بجای مدیریت حافظه، به منطق برنامه و صحت آن توجه و تمرکز کنند تا کدی با اشکالات کمتر ایجاد شود.

این مسئله بسیار حائز اهمیت می‌باشد.

جاوا و C# هر دو زبان‌های Type – Safe هستند Saraswat در صفحه وب خود می‌گوید:یک زبان در صورتی Type–Safe است که تنها عملیات انجام شده بر روی داده‌های آن، از نوع عملیاتی باشد که توسط نوع داده‌ها تصویب می‌شوند.

بنابراین، نتیجه می‌گیریم که طبق این تعریف، C++ ، Type – Safe نیست، حداقل به این دلیل که یک تولید کننده ممکن است نمونه‌ای از برخی کلاس‌ها را به درگیری تبدیل نوع (cast) کند و داده‌های نمونه را با استفاده از تبدیل نوع غیر قانونی و متدها و اپراتورهای ناخواسته رونویسی نماید.

جاوا و C# طراحی شدند تا Type–Safe باشند.

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

بنابراین Type–Safe بودن حائز اهمیت است، زیرا نه تنها تولید کننده را مجبور به نوشتن کد صحیح‌تر می‌کند، بلکه به سیستم کمک می‌کند تا از دست افراد بی‌توجه در امان بماند.

جاوا و C# هر دو زبان‌های شی‌ءگرا هستند هر کلاسی در هر زبانی تلویحا (یا صریحا) یک Object را به زیر کلاس‌هایی تقسیم می‌کند.

این ایده بسیار خوبی است، چرا که در اینصورت یک کلاس پایه پیش فرض برای هر کلاس توکار (built-in) یا تعریف توسط کاربر ارائه می‌شود.

C++ می‌تواند تنها با استفاده از اشاره‌گرهای void این پشتیبانی را شبیه‌سازی کند، به دلایلی از جمله Type – Safe مسئله‌ساز هستند.

چرا این افزایش در زبان جاوا و C# خوب است؟

یک دلیل آن اینست که ایجاد محفظه‌های (container) بسیار عمومی مجاز می‌شود.

مثلا هر دو زبان دارای کلاس‌های پشته از پیش تعریف شده هستند، که به کد برنامه کاربردی اجازه می‌دهند تا هر Object را به یک نمونه پشته مقداردهی شده push کند، سپس pop را فرا بخواند تا مرجع بالایی Object را حذف و به فراخواننده بازگرداند ـ شبیه تعریف قدیمی پشته است.

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

در C++، اکثر تولیدکنندگان از تطبیق دهنده محفظه stack در Standard Template Library (STL) استفاده می‌کنند.

برای آنهایی که با STL آشنایی ندارند، Schildt می‌گوید که STL در اوایل سال 1990 توسط Alexander Stepanov طراحی شد و در سال (5) 1994 توسط انجمن ANSI C++ مورد تصویب واقع شده و در دسترس اکثر کامپایلرهای تجاری C++ و امروزه IDE ها، از جمله eMbdded Visual Tools.NET قرار گرفت.

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