يرجى عدم قراءة مبرمجي C / C ++ المحترفين).
في المقال ، أعرب عن وجهة نظري ، إذا كنت لا توافق ، فتبرر التعليقات.
الغرض من هذه المقالة: الإشارة إلى عيوب C و C ++ التي لا أحبها حقًا وأشجعك على استخدام الإصدار الجديد من اللغة أو حتى تقديم بعض الأفكار لتحسين المعيار.
حسنا ، لقد حان الوقت لإحياء holivar.
أعتقد أن الجميع يدرك أنه في C ++ هناك خطوط فظيعة. خاصة إذا كنا نتحدث عن النوع القديم ، فقد تم إصلاح الكثير وتحسينه في السلسلة الجديدة ، ولكن لا يوجد حتى الآن دعم يونيكود (!).
في معيار C ++ 20 ، يشبه الذهاب إلى إدخال سلاسل يونيكود.
C ++ 20! وهذا على الرغم من وجود C ++
منذ عام 1983 .
افتح IDE المفضل لديك وحاول ترجمة التعليمات البرمجية التالية:
#include <iostream> #include <cstdio> int main() { char string [256]; std::cout << ": "; gets(string); std::cout << ": " << string; return 0; }
UPD1: يقول المعلق أن krakozyabry فقط على ويندوز. هذا بالتأكيد ، نسيت أن تكتب عنه.
ولكن لا يزال غير سارة.
جمعت في Dev Cpp ، المترجم الخليجي.
ترجمة وانظر:
إخراج شاشة جيدة ، هاه؟
الآن دعنا نستبدل سلسلة char [256] بسلسلة char *.
أنا لا أقول أن هذا يجب أن يعمل ، ولكن يجب أن يكون المترجم قد ألقى الخطأ بأعلى مستوى ممكن.
حصلنا على برنامج عمل معلق.
سيكون من الأفضل إذا ألقى المترجم خطأ.
والشيء كله هو أن المترجم ليس فقط جمعها ، لم يفعل ذلك بعد
التحذيرات الصادرة.
إليك مزحة أخرى:
#include <iostream> using namespace std; int main(){ int arr[100]={}; cout<<arr[101]<<endl; return 0; }
ماذا نتوقع؟ سيعلمنا المحول البرمجي بأنه لا يمكنك الوصول إلى 101 عنصر من الصفيف ، نظرًا لوجود 100 عنصر فقط ، لكننا نجمع ونشاهد ونرى ... 32765 (على الأقل على أجهزتي).
هم.
الآن دعونا نختبر هذا الرمز:
int i = 5; i = ++i + ++i; std::cout<<i;
ما رأيك انه سوف يجلب؟
الجواب الصحيح يعتمد على المترجم.
في دول مجلس التعاون الخليجي ، سيكون هذا 14 ، ولكن اعتمادًا على علامات التحسين.
وفي مترجم آخر يمكن أن يكون بسهولة 12 ...
أعتقد أن الجميع يعلم أن هناك مجموعة كبيرة من السكر النحوي في C وفي الإيجابيات ، وهو أمر بعيد عن الحاجة.
على سبيل المثال
std::cout<<4["string"]; هذا هو رمز صالح
يطبع n ، تمامًا مثل
std::cout<<"string"[4];عظيم ، هاه؟
والآن عن المريض.
C ++ والشبكة.
هذه هي 2 مفاهيم مطابقة سيئة للغاية.
فقط حاول تنزيل صورة القط من موقعك المفضل باستخدام مكتبة C ++ القياسية.
لم يكن ذلك ممكنًا قبل اعتماد معيار C ++ 17.
لا يمكنك العمل مع JSON في نفس المكتبة القياسية.
تعليق كبير على هذا.
بشكل عام ، العمل مع JSON في C ++ يشبه الكابوس.
المصدرهل تعتقد أن الحالة ستكون دائما خاطئة؟
if(sizeof ('a') != sizeof (char)){
لا ، أنت مخطئ.
إذا قمت بترجمته كمشروع C ++ ، فمن المرجح أن الشرط لم يتحقق.
لا ينبغي. [1]
وإذا كان مثل مشروع C ، ثم في هذه الحالة sizeof ('a') == sizeof (int).
هذه هي الأشياء.
[1] بشكل عام ، هناك أيضًا العديد من المترجمين C و C ++ المختلفين.
لأن العديد من الحلول ليست موحدة وأنها ستعمل فقط في بعض المجمعين.
على سبيل المثال ، أرقام 128 بت في C ++. هناك نوع __int128 في gcc و clang ، في حين أنه ليس في Visual Studio لأنه ليس معيارًا. أو ، على سبيل المثال ، سلاسل في Visual Studio.
String^ MyString3 = "Hello, world!";
أو ، على سبيل المثال ، في الرجل العجوز Borland C ++ Builder ، يمكنك كتابة التعليمات البرمجية المكتوبة في كائن Pascal.
وهناك العديد من هذه اللحظات.
ألم معين هو عدم وجود قائمة من الحزم C و C ++.
ما يلي من هذا؟ استخدم الإصدار الجديد من C ++ ، على سبيل المثال C ++ 17 وسيتم حل بعض المشكلات.
يجب أن أقول أنه في أقرب منافس C ++ - Rust لا توجد معظم المشاكل من هذه القائمة ، على سبيل المثال ، هناك شحنة رائعة ، لكنها بالطبع غير كاملة.
وما هي مشاكل C و C ++ هل تعلم؟
اكتب في التعليقات.
محدث: يبدو أن الكثير من الناس أسيء فهم مقالتي:
بأي حال من الأحوال أريد أن انتقد C / C ++ وأقول الكتابة على الصدأ.
أود فقط أن أوضح أوجه القصور في C / C ++ ، لأنهم حصلوا على القليل منها.
كل شيء له عيوبه ، لقد شاركت أفكاري.
UPD2:
في التعليقات ، يكتب الكثيرون أن الدبابير تعمل بهذه الطريقة وبصفة عامة هذه هي الميزات. أنتم مخطئون.
ينمو الدليل نفسه على أنه يمكنك إنشاء لغة برمجة النظام التي ليس من السهل إطلاق النار على قدمك.
إنه مجرد أن C / C ++ مليء بإرث من الحلول التي لن يقوم أحد بإصلاحها ، لأنه يمكن أن يكسر التوافق مع الإصدارات السابقة.
ونعم ، هذا رأيي ، إنه
شخصي .
إذا كنت لا توافق - أفضل تعليق ، بدلا من ناقص بغباء ، لأن رأي منا جميعا
ذاتي.