C ++ مقابل C #



يعلم الجميع أنه لا يوجد شيء أكثر غباءًا من المجادلة "أي لغة أفضل". على سبيل المثال ، أفضل لماذا؟ تنجح اللغات المختلفة في مجالات مختلفة - ومن غير المجدي استخلاص استنتاجات نهائية دون التفكير في ذلك.

ولكن ماذا يحدث إذا لجأنا إلى متخصصين ذوي خبرة يفهمون كل ذلك ويطلبون منهم ترتيب C ++ vs C # holivar؟ اتضح أنه يمكنك معرفة الكثير من التفاصيل المثيرة للاهتمام. يمكن تطبيق كلمة "عبر منصة" في كلا الاتجاهين على كلتا اللغتين ، ولكن ماذا يعني هذا في الممارسة؟ هل تتطور C ++ بنشاط الآن؟ هل كسر C # التوافق السابق؟ قد تكون الإجابات واضحة لأولئك الذين غمروا بالفعل في كلتا اللغتين في وقت واحد ، ولكن هناك عدد قليل من هؤلاء الناس - وسوف يتعلم الجميع شيء جديد.

من C ++ ، شارك سيرجى سربت بلاتونوف ، رئيس لجنة برنامج مؤتمر روسيا C ++ . ومثل الجانب C # أناتولي كولاكوف - تم تضمينه في جهاز الكمبيوتر لمؤتمر DotNext ، وبين قادة DotNetRu . وزعيم النقاش ، الذي تعايش فيه هذان العالمان ، كان ديمتري ميزاستل نيستيروك .




ديمتري: مساء الخير ، زملائي. مرحبًا بكم في التجمعات غير الرسمية حول موضوع لغات البرمجة. على الإنترنت ، يتم تذكيرنا باستمرار بأنه لا يمكن مقارنة اللغات. واليوم سنفعل بالضبط ما لا يمكنك فعله: مقارنة C ++ مع C # و .NET ، إيجابياتهما وسلبياتهما. عرف نفسك من فضلك.

Anatoly: اسمي Anatoly ، واليوم سوف أغرق في لغة C # ، لأنني كنت أدرس هذه اللغة من إصداراتها الأولى ، ويبدو أنني أعرف كل شيء عنها.

سيرجي: مرحبًا ، اسمي سيرجي ، سأغرق اليوم في برنامج C ++. قال ديما بشكل صحيح أننا سوف نقارن إيجابيات وسلبيات. الكل يسميها "إيجابيات" ، من المعروف أن C # في هذه المناقشة ستكون ناقصًا. هل هذا صحيح يا اناتولي؟

اناتولي: يحتوي جيم # اثنين من إيجابيات أخرى! لذلك ، أعتقد أن هذا تطور تطوري للمزايا التي عفا عليها الزمن بالفعل وغير قادرة على المنافسة في أي مكان تقريبًا.



تشكيل


ديمتري: لدي الموضوع الأول لمناقشتنا. تخيل أن الطلاب الجدد يأتون إلى الجامعة ، فهم بحاجة إلى اللغة الأولى. ما رأيك يجب أن تكون اللغة الأولى التي يحصل عليها الناس في عامهم الأول: C ++ أو C # أو المجمّع بشكل عام؟

سيرجي: لقد درست لبعض الوقت ، لذلك لدي رأي راسخ. أدرك أننا سنناقش هنا أي لغة أفضل ، وأنا أؤيد لغة C ++ ... ولكن لتعلم لغة C ++ ، فأنت بحاجة إلى فهم بنية الكمبيوتر. ومع ذلك ، فإن المشكلة الكبيرة المتمثلة في تدريس الطلاب (على الأقل في الجامعة التي درست فيها). ولتعليم الخوارزميات والأشياء ، ربما تحتاج إلى شيء لا يركز على البنية التحتية ، وباللغة نفسها. هنا كانت إيفل محاولة للقيام بذلك ، ولكن هناك أيضًا الكثير من السحر. لذلك ، أود أن أقول أن أيا من لغتين لدينا هو مناسب.

البرمجة مختلفة ، وليست "البرمجة" هي التي تعلم ، ولكن الخوارزميات ، هياكل البيانات ، وما إلى ذلك. من الممكن أن يكون من المنطقي اختيار الأداة الخاصة بك في كل موضوع. فهم نوع من بنية بيانات Lisp. وبناءً على ذلك ، يجب إعطاء C ++ بعد أن يفهم الطلاب شيئًا ما عن الهندسة المعمارية. وبعد ذلك سيكون من الممكن أن نفهم لماذا كل هذا الألم والمعاناة. أنا حتى لا أزعم أن الإيجابيات تدور حول الألم.

أناتولي: نعم ، أوافق تمامًا على أنك تحتاج إلى فصل الأشياء ، وليس وضعها في "برمجة" وتطويق كل شيء بلغة واحدة. ولكن إذا وصلت إلى النقطة التي تعلمت فيها الأساسيات والأساسيات والخوارزميات ، وبدأت في اختيار نوع من أنواع اللغة الصناعية ، فستكون C # بالطبع أفضل بكثير. لأنه لا يفرض عليك أن تتعلم كل هذا الثمالة على مستوى الأبنية ، بايت الذاكرة ، و "غروب الشمس باليد" الأخرى. إنه يوفر لغة مفهومة على الفور ، بناء جملة بسيط ، وبهذه اللغة من السنة الأولى أو الثانية يمكنك كسب المال المادي.

ديمتري: هناك حجة مفادها أن عدم إعطاء الطلاب المبتدئين بعض الأشياء مثل المؤشرات هو نوع من التضحية. سيكون لديهم فجوة كبيرة إذا كان الشخص لا يفهم ذلك ، على سبيل المثال ، الرابط هو في الواقع مجرد عنوان متغير في الذاكرة. ما رأيك في هذا؟

Anatoly: قبل 20 عامًا ، كان هذا صحيحًا عندما لم يكن لدى أجهزة الكمبيوتر ذاكرة كافية ، أو ما يكفي من الأقراص وأشياء أخرى. انظر الآن إلى هذه javascripts ، فهي تسحب 500 ميغابايت من المكتبات إلى كل "عالم مرحبا". كم يأخذون في الذاكرة؟ ما هو أدائها؟ ما هي الروابط هناك؟ نعم ، لا أحد يهتم. الشيء الرئيسي هو لفة بسرعة والإفراج عن شيء في الإنتاج. أنا لا أدعي أن هذه طريقة جيدة أو صحيحة ، فأنا أزعم أنه من الضروري التغيير إلى جانب الحقائق. ربما ليس من المهم الآن حجم ارتباطك.

سيرجي: ربما اعتمادا على أين. كان ديميتري ، بقدر ما أفهمه ، مهتمًا بالتداول الخوارزمي - يمكنني أن أتخيل بوضوح كيف يسحب المكتبات على JS لإرسال طلب إلى البورصة.

ديمتري: حسنًا ، نعم ، بالطبع ، من الناحية العملية ، لا أحد يستخدم لغات من هذا النوع هناك. على الرغم من أنه من الناحية النظرية ، قد يكون هذا ممكنًا: دعونا لا ننسى أن الأموال غير الضعيفة يتم طرحها في بنية JS الأساسية. المحركات التي تجعل تجميع JS في أي شيء وكل شيء. يعتبر الكثيرون هذه اللغة لغة من الدرجة الأولى لكل شيء بشكل عام.

بطبيعة الحال ، أصبح تداول algo الآن نظامًا بعيدًا عن هذا التخصص ، لكن تجارة algo والرياضيات المالية ككل هي عمومًا منطقة محددة. إنها تسود C ++ فقط. وهو يسود جزئياً بسبب القصور الذاتي ، وذلك ببساطة لأسباب تاريخية: في البداية كان الجميع في C ++ ، وهذه المنطقة محافظة.

سيرجي: لا أوافق. أنا الآن أعمل في شركة fintech ، ويتحدث زملاؤنا الذين كانوا هنا منذ بداية التداول الحسابي عن الشركات الكبيرة التي كتبت أولاً في Java. في البداية ، تعاملت Java مع التداول الخوارزمي ، ولكن عندما بدأ السوق في النمو وظهر المنافسون مع C ++ ، في مرحلة ما لم يتمكنوا من القيام بذلك ، لم يتمكنوا من فعل كل شيء بكفاءة ... لذلك لم يبدأ كل من تداول الخوارزميات مع C ++. فقط أولئك الذين لم يكتبوا عن ذلك ماتوا. هذا الاختيار الطبيعي.

ديمتري: في الواقع ، يمكنك أن تأخذها على نطاق أوسع. هناك العديد من الأمثلة حيث تحتفظ البنوك الكبيرة بخوارزمياتها في مستند Excel. ثم يستخدمون Excel أيضًا كخادم لحساب كل هذا. هناك الفرامل الجهنمية ، لكن كل هذا يتوقف على ما إذا كنت تقوم بتداول عالي التردد (أو بشكل عام شيء عالي التردد). إذا كنت صانع سوق - وبطبيعة الحال ، فأنت بحاجة إلى أداء عالٍ ، وهناك لا يقتصر العمل على C ++ ، فنحن نذهب إلى لغات الأجهزة و HDL.

لكن مناقشتنا لا تدور حول تداول الخوارزميات فحسب ، بل تدور حول أمور بسيطة أيضًا. هنا أعطي مثالا. فيما يتعلق بالبناء ، كنت بحاجة إلى كتابة العديد من التطبيقات الصغيرة التي تحسب أشياء مختلفة: على سبيل المثال ، كيفية وضع الطوب حول محيط المنزل. وبالكاد أستطيع أن أتخيل كيف أفعل مثل هذه الأشياء في C ++ ، لأن كل ما يتعلق بـ UI أضعف هناك. لا يوجد سوى إطار واحد ، كيو تي ، وحتى الكتابة عليه صعبة للغاية. وإذا جلست في C # ، لـ WinForms ، فعندئذٍ فقط أقدم الطلب على الفور.

اناتولي: حسنًا ، كان الجزء البصري دائمًا قوة C #. استثمرت Microsoft الكثير في القوالب ، وحتى في القوالب المشتركة ، وبشكل عام في التصور. لذلك ، إذا كنا نتحدث عن تطبيقات سطح المكتب المرئية ، فيبدو لي أن الإيجابيات بعيدة كل البعد عن الركب.

سيرجي: حسنًا ، هذا يعتمد ، كما هو الحال دائمًا. أنا حقا لا أحب واجهة المستخدم ، ولكن على الإيجابيات لدي باستمرار للقيام بذلك. يبدو أن جلب JS والتفاعل فقط مع الايجابيات. لكنني عملت مع جزءا لا يتجزأ ، وهناك من الصعب. اشترى الناس نوعًا من المحركات باهظة الثمن ، لكنه لا يزال غير قادر على التعامل مع العرض العادي لجهاز UI المكتوب بلغة JS. وبعد إعادة كتابة كل هذا على كيو تي ، اتضح أن فيركلوك. قصة عادية.



عبر منصة مقابل عبر منصة


سيرجي: أردت أن أوضح هنا. لا أعرف الكثير عن C # ، لقد لمسته بنفسي منذ وقت طويل جدًا ، في الإصدارات الأولى (في ذلك الوقت كنت قد تعطلت التوافق مع الإصدارات السابقة). لذا فإن السؤال هو: هل ما زال يجري تطويره بواسطة Microsoft فقط؟

Anatoly: لا ، لقد أصبح الآن نظامًا متقاطعًا ومفتوحًا والتحقق منه بموجب ISO (ECMA-334 و ISO / IEC 23270). بالمناسبة ، حسب علمي ، لا يزال لدى C ++ مواصفات ISO مفتوحة ، مدفوعة فقط. و C # ، على النقيض من ذلك ، مفتوح تماما. تم تطويره بواسطة العديد من الشركات (بما في ذلك Google و Amazon و Samsung) ، لدينا .NET Foundation . لا أعرف حتى الآن لغة أكثر انفتاحًا من C # ومنصة .NET الخاصة بها.

سيرجي: حسنًا ، هاسكل.

Anatoly: بالمناسبة ، يعمل مؤلف Haskell في Microsoft Research وبذل الكثير من الجهود لجعل كل أنواع الأشياء الرائعة تظهر في C # - على سبيل المثال ، فحص ثابت ، نوع من التفكير ، والذي ربما لا يمكنك حتى أن تحلم به.

سيرجي: يمكن أن يحلموا ، وحتى العمل مستمر في هذا الاتجاه. لكن من الواضح أن كل شيء له سعره الخاص. في C ++ ، يرفضون ببساطة دفع هذا السعر.

اناتولي: أي واحد؟ يتم تجميعها لمدة ساعتين ، ماذا يمكن أن يكون الثمن؟

سيرجي: في C ++ ، مبدأ تجريد التكلفة الصفرية. حسنا ، هذا هو ، الجهاز الظاهري ليس التجريد صفر التكلفة ، أليس كذلك؟ علينا أن نتحمل هذا.

ديمتري: حسنًا ، ولكن الآلة الافتراضية يمكنها ، على سبيل المثال ، إخفاء الشفرة الخاصة بهندسة معينة. بينما في C ++ ، إذا كنت تستخدم تعليمة AVX على جهاز كمبيوتر بدون AVX ، فإن عملي فقط يتوقف. أود أن أقول إن هذه الحجة غير صحيحة تمامًا ، لأنه من الناحية النظرية - أؤكد عليها نظريًا - يمكن لـ JIT القيام بما لا يتوفر C ++. وهي التحسين في وقت الاطلاق.

سيرجي: ولكن في C ++ ، أثناء التجميع ، يمكنك التحكم بالكامل في التعليمات التي تحتاجها. في هذه الحالة ، لا يمكنك التحكم في يديك ، لكنك تتخلى عن الأداة (مترجم). انظروا ، ما هي التعليمات الموجودة على هذا الهيكل ، ما مجموعة التعليمات ...

ديمتري: هذا أمر مفهوم. لكن يمكنك صياغته بهذه الطريقة: نظرًا لوجود مليون منصة ، لن نحصل أبدًا على أي نوع مثالي ، لأنه لا يمكننا إصدار مليون نسخة بأعلام تجميع مختلفة. أليس كذلك؟ نصدر عادة x86 و x64 ، لكن لا نقسمها كلها إلى بعض المجموعات الفرعية.

سيرجي: لماذا لا نستطيع؟ القرن الحادي والعشرين. عقد عامل الميناء مع معايير مختلفة ، هذا كل شيء.

ديمتري: عندما يكون لدينا عميل نهائي يقوم بتنزيل تطبيقنا ، يريد تنزيل ثنائي معين. وفي هذا الثنائي ، أفضل ما يمكننا فعله هو التمسك في كل مكان إذا. مثل "إذا كان cpuid هو كذا وكذا وكان دعم avx كذا وكذا ، فإننا نستخدم الخوارزمية الإصدار 25". نتيجة لذلك ، نحتاج إلى 25 إصدارًا مختلفًا من نفس الخوارزمية ، لأن التسارع يعتمد على الأنظمة الأساسية ، وهو يعتمد على النظام الأساسي.

سيرجي: ربما أوافق. هذا فقط ، لأكون صادقًا ، لم أقم أبدًا بإنشاء منتج غير داخلي. أنا أساسا في الشركات التي تستخدم نفسها منتجاتها.

ديمتري: حسنًا ، بالطبع ، الخيار الأفضل هو عندما تعرف الهندسة المعمارية بشكل متوقع. في هذه الحالة ، بالمعنى الدقيق للكلمة ، لا أحد يفرض عليك استخدام تعليمات x86 على الإطلاق. يمكنك أن تأخذ بطاقة معينة (على سبيل المثال ، Nvidia Tesla) وتفعل ما تريد. هذا هو النهج الذي أتبعه أيضًا ، أتحكم في بنائي. ولكن عند اتخاذ قرارات السوق الشامل للمستخدم ... إذا اتخذت بعض ReSharper المشروط ، فلن يتمكن من اتخاذ واستخدام تسريع GPU لأي مؤشرات تعسفية. لأن تسريع GPU ليس شيئًا محمولًا.

سيرجي: في الواقع ، هناك طرق (الآن ربما لا تحتاج إلى الدخول في التفاصيل) ، هناك أشخاص مثيرون للاهتمام (يبدو أن مؤلف النهج انتقل الآن إلى Microsoft). هنا في مؤتمرنا في العام السابق ، كان هناك تقرير حول كيفية كتابة مثل هذا البرنامج ، والذي سيفهم هو نفسه ما هو (حيث من السهل نسبيًا ، مرة أخرى ، تجريد التكلفة الصفرية). بحيث يمكنك الاختيار بسرعة ، وإذا كان أي شيء ، إعادة إنشاء الرمز بشكل صحيح في نمط CUDA ...

ديمتري: في الواقع ، تحاول CUDA نفسها حل هذه المشكلة ، لأنه في CUDA هناك طبقة وسيطة معينة من PTX تتعامل مع هذا. لكن هذا لا يزال صعبًا للغاية ، لأن الحديد يتغير جذريًا تطوريًا ، ومن الصعب للغاية مواكبة ذلك على الإطلاق. وإذا نظرنا إلى استخدام تسريع GPU ، على سبيل المثال ، في منتجات Adobe ، فإنهم يستخدمون قسمًا ضيقًا جدًا من التقنيات المتاحة. إذا كانت بطاقتك صحيحة - نعم ، فكل شيء سيكون كذلك. لكن إذا كانت غريبة بعض الشيء ، فلا شيء مضمون في هذا الصدد.

Anatoly: في هذه المناقشة ، تطرقنا إلى موضوع مهم إلى حد ما ، مثل هذه الأسطورة: تم إعلان C ++ منذ عدة سنوات على أنها لغة مشتركة بين الأنظمة الأساسية ، ولكن في الوقت الحالي ، أصبحت المنصة المشتركة أكبر بكثير في C #. يعمل ثنائي واحد فقط في كل مكان حيث يتم دعم .NET ، وهذا في كل مكان تقريبًا.

سيرجي: حسنًا ، هذا أيضًا لا أساس له من الصحة. باعتباري شخصًا قضى معظم حياتي في مضمن ، نادراً ما رأيت أن يكون .NET مدعومًا بواسطة سلسلة أدوات الشركة المصنعة للجهاز. الشركات التي تنتج الحديد تأخذ نفس G ++ أو Clang أو تجعلها تبدأ في إنشاء كود لمنصتها.

ديمتري: نعم ، لكن المشكلة هي أنه في كل مرة يقومون فيها بذلك ، يفقدون شيئًا ما من C ++. على سبيل المثال ، استخدمت نوكيا تنوعًا من C ++ ، لكن C ++ كانت مع تحولات مجنونة وواجهة برمجة تطبيقات مجنونة أثارت غضب الجميع. وهذا هو ، ليس فقط C ++ ، ولكن C ++ لأحد أو آخر منصة. ثم تبدأ المشاكل. على سبيل المثال ، خذ نفس CUDA. يبدو الأمر كما لو أنه ينبغي أن يدع المحترفين يجتازون نفسه ؛ إنه ليس مترجمًا على الإطلاق ، بل مجرد سائق. ولكن على الرغم من ذلك ، فإنها تعاني من حقيقة أنها لا تزال تستخدم نوعًا من الأطر لتمزيق ملفات CUDA إلى أجزاء وحدة معالجة الرسومات ووحدة المعالجة المركزية. وفي بعض الأحيان لم تنجح.

سيرجي: لم أقصد ذلك قليلاً. إنه عندما أسمع ".NET يعمل في كل مكان" ، فإن معظم سيرة العمل الخاصة بي تعود إلى الوراء. عندما تشتري قطعة من الأجهزة باستخدام معالج مخصص ، فإنها تأتي مرفقة مع توصيل G ++ فقط. وهناك C ++ عادية ، يمكن لـ G ++ تحويلها من toolchain إلى رمز الجهاز الذي يدعمه هذا المعالج المحدد.

ديمتري: ولكن مرة أخرى ، يجب إعادة تجميع هذا ...

سيرجي: بالطبع.

ديمتري: وفكرة أننا نأخذ رمزًا زائدًا وسحبه على قطعة من الحديد - هذه الفكرة أيضًا لا تعمل ، لأنك فجأة سحبت جهاز x86 العادي الخاص بك في مكان ما ، حيث لديك 8 غيغابايت من الذاكرة لكل شيء عن كل شيء ، وهي ليست كذلك توسيع: على سبيل المثال ، لا يوجد تبادل للقرص ، لأنه لا يوجد قرص والوصول إليه. هذا إذا كنا نتحدث عن قابلية. يعتمد على الأهداف ، بطبيعة الحال.

Anatoly: يعمل المحترفون على المزيد من الأجهزة ، وبالطبع ، يعد جزءًا من أقوى الأجزاء. ولكن عادةً ما يتعين عليك تكييف التعليمات البرمجية بطريقة ما مع النظام الأساسي. هذا سيء يمكنني تغطية عدد كبير من المنصات والبنى والنماذج برمز واحد. على الإيجابيات ، كان علي أن أفكر في كل منصة فردية: من أين ستبدأ هناك ، وتحت أي ظروف. إنه أمر سيء للغاية ، إنه يتراجع بشدة.



الاستقرار والتوافق وتطوير اللغة


ديمتري: تم ذكر تجريدات التكلفة الصفرية أيضًا ، ولكن المشكلة هي أن هذا له ثمن باهظ. على سبيل المثال ، في .NET يوجد مفهوم لنوع التعداد وواجهة IEnumerable. ولكل نوع ، على سبيل المثال ، صفيف ، يمكنك أن تأخذ وتكرار من خلال التكرار. ولكن في C ++ لا توجد فكرة من هذا القبيل. نظرًا لعدم تجريد التكلفة الصفرية ، وللتجول في المجموعة ، هناك بضعة البداية () والنهاية () ، وهناك قواعد لعملهما ، وكل هذا أكثر تعقيدًا (خاصة بالنسبة لأولئك الذين يبدأون البرنامج). هذه مشكلة مباشرة: كيفية الالتفاف على بعض الصفيف من A إلى Z.

سيرجي: إذا فهمت بشكل صحيح ما الذي تتحدث عنه ... إذا كنت بحاجة فقط للتجول في حاوية من البداية إلى النهاية ، فأنت الآن تكتب ، كما هو الحال في بعض بيثون.

ديمتري: هذا كل شيء رائع. لكنك ، على سبيل المثال ، لا تستخدم تعدد الأشكال لهذا الغرض. لا يمكنك القول أن لدي هنا وظيفة تتلقى قيمة معينة ، والتي تم تعدادها مسبقًا. لا يمكنك القول إن لديّ قيمة تنفذ الواجهة ، وهذه الواجهة بها مكرر ، على سبيل المثال.

سيرجي: نحن نتحدث عن C ++؟ حول C ++ بشكل عام ، C ++ للمستقبل ، C ++ ، والتي يتم قبولها الآن كمعيار؟

ديمتري: حسنًا ، إذا كان في إيجابيات المستقبل سيكون ...

سيرجي: في C ++ 20 ، هذا موجود بالفعل. يمكنك أن تقول بالفعل ، يمكنك حتى أن تعلن عن نفسك. هذه ليست واجهات ، ولكن ، كيف يمكنك أن تقول ذلك بشكل صحيح ... بشكل عام ، يمكنك التصريح بأن نوعك يجب أن يستوفي مثل هذه الشروط. على سبيل المثال ، يبدأ ونهاية ، ويعيد التكرار. والتكرار هو مثل هذا المفهوم المعد في المكتبة القياسية. يقول ما هو ، يصف. تكرارات مختلفة أيضا. بشكل عام ، نحاول أن نجعلها أكثر ملاءمة للناس.

ديميتري: يبدو لي أن هذا نبع من حقيقة أن الناس أدركوا للتو أنه من الصعب العيش بدون مفاهيم تكرارية لأي كائن. لأنه ليس من الواضح كيفية كتابة الأشياء المعممة. نعم ، يعني تجريد التكلفة الصفرية أننا لا نملك تكلفة التجول حول v-table عند البحث ... في .NET هناك طريقة محددة ، على سبيل المثال. ونحن ، من أجل العثور عليه ، بطبيعة الحال ، يجب أن نبذل الجهود ، والتي ترفض الإيجابيات. ولكن من وجهة نظر قابليتها للاستخدام ، فإن النتيجة النهائية ليست جيدة جدا ، وأود أن أقول.

سيرجي: بطبيعة الحال ، يجب أن يكون هناك توازن. لا يمكنك الحصول على كل شيء دفعة واحدة.

اناتولي: هذا يجعلك تتساءل كم سنة مرت. تتطور اللغات البديلة ، وتظهر فيها هذه الأشياء الأساسية من البداية. الآن هم اللحاق بشيء أكثر جوهرية ومثيرة للاهتمام. وتجلس الإيجابيات لمدة عشر سنوات بنفس بناء الجملة غير المفهومة ، والتجريدات الغامضة ، والعكازات غير المفهومة والمتخلفة. يمكنك وضع هذا كواحد من السلبيات.

سيرجي: هيا! ماذا يعني "تطوير ضعيف" يعني؟

لقد ذكرت لجنة - C ++ لديها أيضًا لجنة ISO تقوم بتطويرها. يوجد ممثلون هناك ، بمن فيهم Microsoft ، غرقوا بشدة لحقيقة "لا يمكنك القيام بذلك ، لأن لدينا الكثير من الإرث الذي نحتاج إلى دعمه." فقط C ++ هي اللغة الموجودة بالفعل. وبطبيعة الحال ، يمشي بعناية فائقة. إحدى المهام الرئيسية (التي أعلن عنها Straustrup بالفعل عند إنشاء) هي التوافق مع C. ولكن الآن C تطورت إلى حد بعيد ، عليك تعيين أي C متوافق مع.

وفي رأيي ، الآن C ++ تتطور بوتيرة هائلة. فيما يتعلق بالمفاهيم وما إلى ذلك - في الواقع ، كل شيء ينمو ، بالطبع ، وليس من التكرار. في الواقع ، يتبع التطور ما وصفه ألكساندر ستيبانوف أيضًا - أحد مؤلفي ما نسميه الآن "البرمجة المعممة" ، الشخص الذي قام بالفعل بسحب القوالب والأدوية وما إلى ذلك في C ++. لكي أكون أمينًا ، لا أعرف كم كانت اللجنة مستوحاة من هذه الأفكار ، لكن يبدو لي أن هناك بالتأكيد بعض التقاطع معها.

أناتولي: يبدو أن كل هذه المشابك ، التكرارات هي حقًا مصدر إلهام ، والتي كانت بالفعل منذ عدة عقود مضت. حتى لو كنت تأخذ metaprograming ، القوالب ، وحدات الماكرو - كل هؤلاء الأشخاص لديهم خبرة طويلة ، ويطحنون ، وهناك مفاهيم أكثر بساطة ووضوح ومفهوم. في لغات أخرى ، يتم كل هذا أفضل وأسرع بمليون مرة ، مع أمان النوع ، والتحقق من وقت الترجمة ، وما إلى ذلك.

سيرجي: انتظر ، أنت تتحدث بالفعل عن شيء ليس كل شخص على استعداد لدفع ثمنه. لا أريد أن يتحقق برنامجي من شيء ما في وقت تجميعي دون معرفتي. هل تفهمين

أناتولي: أعتقد أنه يمكن تكوين كل هذه الأعلام. قمت بتعيين مستوى التحسين ، وأنه إما يتحقق لك أم لا. هذه ليست مشكلة.

سيرجي: غالبًا ما تحتاج إلى التحكم في كل شيء بيديك. تعرف بالضبط ما يجري. لأن الأدوات - حسنا ، هذا.

ديمتري: الأمر لا يتعلق بالأدوات. يقول هنا حقيقة أن لغات مثل D و Rust ، قل: حسنًا ، نعم ، هناك شيء من هذا القبيل عندما تقوم بالوصول إلى عنصر الصفيف ، يمكنك التحقق منه ، لكن لا يمكنك التحقق منه. ويعطونها للمستخدم فقط ، وهذا يعني أنه يمكنك قول "ولكن دعونا نوقف تشغيل اختبارات الصفيف" ، "ولكن دعونا نفتحها". وهذا هو ، نوعا من السيطرة في هذا الصدد.

سيرجي: ليس واضحًا عندما تكون غير آمن وآمن ، كما هو الحال في Rust ، لا أرى الفرق مع C ، على سبيل المثال ، في هذه الحالة.

اناتولي: الفرق هو أنه يمكنك الكتابة بأمان ويمكنك الكتابة بسرعة. وفي جيم عليك أن تكتب بشكل خطير. حسنا ، نعم ، ربما بسرعة. الاستقرار هو في بعض الأحيان أكثر أهمية من السرعة.

ديمتري: في الواقع ، إذا بدأنا في حفر هذا الموضوع بلغات جديدة ، في لغة C ++ ، هناك أشياء يصعب جدًا نقلها للناس عمومًا. سؤال بسيط: ما هو حجم الباحث؟ في معظم اللغات ، تعرف إجابة هذا السؤال. أنت تقول: كثافة العمليات 32 بت. لكنك لا تعرف الايجابيات. أنت تعرف الحجم على جهاز الكمبيوتر الخاص بك لأنك تتذكره ، ولكن ، بالمعنى الدقيق للكلمة ، لا تريد حتى استخدام الأنواع الأساسية لأنها غير حتمية. ومثل هذه الأشياء تغضبني عندما يكون هناك مجموعة من الأساليب القديمة مثل int ستكون مختلفة على منصات مختلفة. والآن نحن نفهم بالفعل أنه لا يمكن القيام بذلك. لماذا لا نتخطى هذا الأمر ونحل هذه المشكلة بطريقة أو بأخرى؟

سيرجي: حسنًا ، لقد تقرر ذلك. هناك الأمراض المنقولة جنسيا ، والأنواع المطلوبة مع طول ثابت. الآن يقوم ممثل روسيا في اللجنة بسحب عدد كبير من الطول المتغير (جيدًا ، مرة أخرى ، مع تجريد التكلفة صفر).

Anatoly: هل أتذكر بشكل صحيح أنه يوجد حتى حجم غير محدد لمؤشر إلى طريقة ما؟ هذا هو ، تحت المجمعين مختلفة ومنصات مختلفة ، المؤشرات مختلفة؟

سيرجي: بطبيعة الحال ، هذا هو العمارة. عندما تكون قريبًا من الأجهزة ، كيف يمكنك ضمان حجم المؤشر ، إذا كنت تعمل على 8 بت ، ثم على 64 بت؟

اناتولي: وكيف يمكن للمرء القيام بحساب على المؤشرات بعد ذلك؟ هذا جنون.

سيرجي: يعني؟ حسنا ، بعناية.

اناتولي: فهمت. النهج واضح في كل مكان ، والسيطرة بعناية كل شيء مع مقابض.

سيرجي: حسنًا ، نعم. مرة أخرى ، وفقًا لمعايير C ++ الحديثة ، يتم تطوير الأساليب ... إذا تحدثنا عن الخيار ، ثم في الميزات الحديثة ، في الواقع ، هناك خيار ما إذا كنت تريد استخدام أداة تجميع مجمعي البيانات المهملة. انها مجرد أن GC بنيت هناك على العدادات المرجعية.

بشكل عام ، وبكلماتك ، يا زملائي ، أشعر ، آسف ، أنك لم تقم بتحديث معرفتك بالإيجابيات الحديثة لفترة طويلة.

الآن ، يأتي أشخاص مثل Straustrup ، الذين هم جزء من آلهة آلهة الزائدين ، مع الكثير من الدعوات لمعرفة كيفية تدريس لغة C ++ الحديثة. المشكلة هي ما يفكر به الناس في فئات C ++ 2003 ، والتدريس في نفس الفئات. وفي هذا الصدد ، هناك مشاريع وأساليب جديدة ومثيرة للاهتمام ، وهناك دورات حديثة - دعنا نقول أن شباب ياندكس قاموا بعمل دورة رائعة. والآن في الإيجابيات يعتبر سلوكًا سيئًا ، على سبيل المثال ، استخدام نقية جديدة وحذفها.

ديميتري: بالنسبة لتعليقك حول تحديث المعرفة ... فإن الفارق البسيط هو أن مقاربي ، على سبيل المثال ، هي استخدام دلتا C ++ الصغيرة ، والتي يضمن العمل بها بالنسبة لي والتي أنا "أصدقاء". ترى ، C ++ واسعة النطاق. هناك مخطط metaprograming ، وكل شيء سيكون على ما يرام ، هناك الكثير من السحر ، ولكن للأسف ، هذا السحر غير قابل للقراءة. هذا رمز لا يمكن لأي شخص غير مؤلف إدراكه دون أي معرفة خاصة ، بمعنى أنه صندوق أسود. وهناك الكثير من هذه الصناديق السوداء في الايجابيات ، ومناطق الظلام التي لا يمكن هضمها ... أود ، لا أعرف ، خيارك أن يتم حسابه بشكل متوقع ، وأيضًا ودون أي حيل.

أبسط مثال هو الحديث عن النطاقات ( range-v3 وهذا الموضوع بأكمله). من ناحية ، كل هذا رائع: هناك أشياء موجودة في C # لعدة سنوات ، على سبيل المثال ، تسمح بإنشاء تقويم عن طريق أي تحويل للمجموعة القياسية. من ناحية أخرى ، الطريقة التي يتم تنفيذها بها في C ++ هي ببساطة غير سارة مقارنة بـ C #: إنها ثقيلة ، غير قابلة للقراءة.

سيرجي: هذا توابل. أنا ، على العكس ، أحب ذلك. كما أفهمها ، أنت على تقرير Nibler وعرضه ...

ديمتري: كما ترى ، عند استخدام عامل التشغيل "أو" لتصفية مجموعة ، لدي على الفور أسئلة حول هذا الموضوع. فعل كل من C # و Java كل شيء من خلال النقطة ، من خلال الطرق المعتادة.

سيرجي: ويبدو لي أن هذا مستوحى من باش. وهذا هو ، مجرد أنبوب.

ديمتري: حسنًا ، نعم ، ربما هذا ما يفسر شيئًا ما في هذا النهج.

سيرجي: إنه يفسر الكثير! دعونا نتحدث عن PowerShell ، لأننا نتحدث عن Bash. من رأى PowerShell؟

اناتولي: أنا أكتب في PowerShell ، وهي لغة رائعة. لكن مرة أخرى ، يجب إدخال الأنبوب في مكانه ، حيث تتخلل كل العمارة به. ليس في المكان الذي تحتاج فيه إلى القيام بعمل واحد ، وهو هنا بناء جملة سيئ المصطلح.

سيرجي: من مجموعة الأنابيب ، إنه ...

ديمتري: في المدى ، يتم استخدامها ، في رأيي ، للسبب التالي ... سأقول هذا: إذا كان في C ++ هناك طرق تمديد أو وظائف ملحق ، فستستخدمها بالطبع. لأن الشيء الأكثر طبيعية إذا كنت بحاجة إلى فرز مجموعة هو كتابة "مجموعة. filter ()". وليس "جمع | عرض :: filter () ".

اناتولي: لدي انطباع أيضًا بأنك قد أصبت بالرصاص في الساقين لمدة 20 عامًا ، وضُربت في وجهك ، وضربت رأسك على الحائط ، ثم أخيرًا تقول: "حسنًا ، لقد فعلنا كل شيء بشكل جميل في المعيار العشرين ، والآن دعنا نعلم الايجابيات على حق ". نعم ، لا أحد يريد أن يعلمهم بشكل صحيح! وهذا هو ، ألم طويل الأجل.

سيرجي: من فضلك لا تعلم. ما هي المشكلة؟ الكتابة في C # - التجارة على ذلك ، والكتابة المدمجة. أنا لا أمانع.

اناتولي: حسنًا ، هناك منافذ ضيقة حيث لا تزال هناك إيجابيات.

سيرجي: جزءا لا يتجزأ من "مكان ضيق" ... في الوقت الحالي ، وأنا أنظر حولي في مطبخي ، أرى مجموعة من أجهزة الكمبيوتر.

ديمتري: في كل مرة أسافر فيها بالطائرة ، أعتقد: "لعنة ، آمل أن تكون هذه الإيجابيات قد كتبت كل شيء جيدًا هناك."

سيرجي: حسنًا ، بالمناسبة ، هناك أدا بشكل أساسي ، بقدر ما أتذكر.

ديمتري: أدا يهيمن على هناك ، نعم.

Anatoly: بالمناسبة ، صادفت مؤخرًا مقالة ممتازة كتب فيها المؤلف بلغات مختلفة (حوالي 10) برنامج تشغيل منخفض المستوى - برنامج تشغيل شبكة للحصول على بطاقة Intel 10 جيجابت. من C إلى Swift و JS و Python و C # بشكل طبيعي. إذا نظرنا إلى هذه الرسوم البيانية ، التي حصل عليها ، فإن C # على دفعات كبيرة (عندما يتم ضبط تكاليف الإطلاق) يتماشى مع C و Rust.



وهذا هو ، إذا كنا نتحدث عن الأداء ، فقد يكون من المفهوم الخاطئ أن C # أدنى بكثير في مكان ما. هناك أيضًا تقرير غير تقليدي من Federico Luis Scratched Metal ، حيث أوضح كيف قام بتحسين رمز C # لملفي المعالج.

سيرجي: حسنًا ، يبدأ من جديد. الشيء هو أنه عندما تبدأ في تحسين ذلك Java ، ذلك C # ، يصبح من غير الواضح لماذا لا تكتب على الإيجابيات. لأنك بحاجة إلى معرفة محددة. وكما يبدو لي ، فإن ميزة لغات مثل C # و Java مستوية - ليست عتبة إدخال عالية جدًا. بقدر ما أفهم ، بالضبط ما كان يتحدث عنه ديمتري: قراءة التعليمات البرمجية ، والتعلم الكثير ، من الصعب شرح بعض المفاهيم ، وهلم جرا.

اناتولي: أعمل 99 ٪ من وقتي في الكتابة "العادية" C # - آمنة ومستقرة وتعمل في كل وقت. و 1 ٪ من الوقت أريد أن أكتب نوعا من رمز سريع منخفض المستوى. وهذا C # يسمح لي أيضا. لكن أداتي الرئيسية لا تزال مستقرة وقابلة للقراءة ، دون أخطاء ...

دميتري: توليا ، دعني أعطيك مثالاً بسيطاً: الموجه. مع vectorization في .NET ، كل شيء سيء للغاية ، على الرغم من حقيقة أن System.Numerics.Vectors يجري ببطء المنشار. وما الذي يؤدي إليه ، من جانبي ، على سبيل المثال؟ إلى حقيقة أنه إذا كنت تتسوق في السوق وتشتري مكتبة رياضية لـ .NET ، يتم كتابتها على المحترفين (مع غلاف كامل). لأنه في .NET لا يوجد عملياً أي وصول إلى تسريع الأجهزة (AVX ، إلخ) ، فقد وصل الآن إلى مرحلة الجنين.

Anatoly: يتم إصدار Intrinsics في .NET Core 3 حيث يمكنك الوصول مباشرة إلى AVX. إنها موجودة بالفعل في مهدها ، ولكن هناك أشياء أساسية ، والباقي يتحرك تمامًا.

ديمتري: أنت تفهم ، لدينا 2019 في الفناء. كمستخدم لكل هذا الخير الرياضي المتسارع ، أنا لم أنتظر هذا. ونتيجة لذلك ، بالنسبة لي ، إذا أردت التفكير سريعًا في شيء ما ، فلن يعد C # مرشحًا. لأن مكتبات C ++ موجودة بالفعل. ربما تم بالفعل ضياع الوقت لهذا الغرض.

أناتولي: يبدو لي أن C # تتحرك في اتجاه الإيجابيات ، إنها تحاول الفوز بسوقها. لكن الإيجابيات لم تعد تتحرك في أي مكان.

سيرجي: من أين يأتي هذا؟ ماذا تعني عبارة "الإيجابيات لا تذهب إلى أي مكان"؟

أناتولي: عندما يخبرونني في عام 2019 أنه سيكون هناك متكررون في المعيار ، سيكون هناك بعض التقدم حول لامبدا ، يبدو لي أنه ...

سيرجي: لا أعرف لماذا تتحدث عن التكرارات ولامدات ، لا أفهم الطريقة التي كان بها الحجر ...

اناتولي: ليس عن التكرارات ، لقد أخطأت ، قصدت الحاويات الكثيرة التي ناقشناها من قبل. وفي الوقت نفسه ، حصلنا على مطابقة الأنماط.

سيرجي: كل هذا يتوقف على ما إذا كان ضروريًا أم لا. نحن نناقش مطابقة النمط. ولكن حتى الآن لا توجد حجج حول ما إذا كانت هناك حاجة في الايجابيات.

ديمتري: أسمع الكثير من التعليقات المشابهة من الإيجابيات ، والتي تقول "على الرغم من وجود وجود واضح لهذا النهج أو ذاك في لغات أخرى ، فقد تم إعداده بالفعل ، والناس يحبونه ويبنون حلولاً عليه ، ما زلنا لا نريد ذلك في إيجابيات ، لأنها ليست إيجابيات اصطلاحية ". ويبدو لي أن جافا سقطت في الحفرة نفسها. قال جافا "لا شباب ، ليس لدينا مندوبون". وفي Java لا يوجد حتى الآن مفهوم للمفوضين ، ولكن في .NET كل هذا يعمل بشكل جيد.

سيرجي: انظروا ، إيجابيات بسيطة للغاية. مرة أخرى ، والعودة إلى اللجنة. هناك نصيحة - هؤلاء هم الأشخاص الذين يقومون بتطوير المجمعين. وبالنسبة لهم ، فإن عبارة "صفر تكلفة تجريد" هي فقط ما يجب أن يسترشدوا به. وكلمة "إرث" ، لسوء الحظ.

ديمتري: حسنًا ، تجريد التكلفة الصفرية هو مجمع. إذا أردنا التجريد الصفري للتكلفة بشكل عام ، نحتاج إلى كتابة كل شيء في المجمع.

سيرجي: لا يوجد تجريد.

ديمتري: المجمع هو تجريد على الكود الثنائي. إنه مجرد الجيل الثاني ، وليس الجيل الثالث.

سيرجي: إذن ، فيما يتعلق بجميع أنواع "الأشياء المريحة" ، اتضح أنه ليس من الواضح كيفية جعلها تعمل بسرعة.

ديمتري: دعهم يعملون أبطأ. الفكرة مع التكرارات غير المتزامنة ، coroutines ، كل هذا - في .NET مع C # الكلمة الرئيسية ذات العائد لم تعد تعرف عدد الإصدارات التي تعمل بشكل رائع. نعم ، يتم بناء آلات الدولة الضخمة وراء الكواليس ، مجرد سحر. لكن المزامنة / تنتظر أيضًا تبني السحر والتكرارات. لكن الجميع يستخدمه ، وهو مناسب حقًا.

سيرجي: Coroutines إضافة إلى إيجابيات ، مرحبا.

ديمتري: حسنًا ، نعم ، يتم إحراز تقدم. لكن الكوريتين تظهر الآن ، وليس قبل 10 سنوات.

سيرجي: مرة أخرى. الإيجابيات أقدم ، وفي رأيي ، تنخفض سرعة التطوير مع تراكم قاعدة الشفرة. بوضوح ، كل هذا يتوقف على ما إذا كانت هناك رغبة في الحفاظ على الدعم القديم. بالنسبة للإيجابيات ، هذا موقف مبدئي. بمعنى ، يتم الآن ترجمة التعليمات البرمجية التي كتبتها في الثمانينات بواسطة مترجم حديث.

ديمتري: نعم ، لكنك قمت بترجمة الكود الذي كتبته في C # 1.0 مع مترجم حديث.

سيرجي: هذا غير صحيح. في بداية المناقشة ، قلت إن أحد التحديثات وصل إلى إصداراتي القديمة من .NET ، فجأة توقفت جميع البرامج عن العمل.

ديمتري: ربما تغيرت واجهات برمجة التطبيقات التي استخدمتها للتو. هنا تحتاج إلى فصل المكتبة ولغة البرمجة.

سيرجي: لم يكن لدي شيء ، فقط C #. كنت صغيرا ، كانت هذه هي السنوات الأولى.

ديمتري: أتذكر تغييرًا واحدًا مكسورًا ، في C # 4 - تغيير بسيط في سلوك foreach. بالطبع ، في الإصدارات 1.x يمكن أن يكون كل شيء أكثر اضطرابًا ، لكن الآن نحن لسنا بالتأكيد في المرحلة التي يكسر فيها شخص ما شيئًا ما فجأة.

أناتولي: حسنًا ، تلتزم Microsoft رسميًا بالموقف الذي يراقب بدقة التوافق الخلفي ، فهي تختبر إصدارات جديدة على عدد كبير من الآلات وقواعد الكود. ربما كان لديك خطأ أو شيء من هذا القبيل.

ديمتري: بشكل عام ، يراقب .NET أيضًا التوافق مع الإصدارات السابقة ، لكن سرعة التقدم قفزت C ++ و Java.

سيرجي: يبدو لي أنها لعبت دورًا كبيرًا ، حيث كان هذا في البداية مدفوعًا بشركة واحدة. لأن C ++ كان في الأصل في اللجنة - وهذه هي السياسة ، الجميع يحاولون دفع قرارهم ، وهذا يشبه اجتماع مجلس الشيوخ في حرب النجوم.

ديميتري: إذن حجتك هي أننا جميعًا رهائن في اللجان التي لا يقودها الابتكار؟

سيرجي: المشكلة هي أنك لا تختار حلاً يرضي الجميع. يتم توزيع الأداة على نطاق واسع بحيث يتم استخدامها من قبل الكثير من الشركات. لقد تذكرتم نفس coroutines: لماذا استقبلهم في وقت متأخر؟ لأن مايكروسوفت ، على ما يبدو ، لا يمكن أن تتفق مع جوجل. كان هناك تطبيقان - لا أتذكر من يقف وراء التكدس ومن يقف وراء التكدس ، لكن لا يمكنني الموافقة عليه. نظرًا لأن كلا الشركتين كبيرتان ، فلهما قواعد برمجية ضخمة تحتوي بالفعل على حل ، ويرفضان إعادة كتابته.

ديميتري: من وجهة نظر القارئ ، سيشعر المرء أنه بصق عليه من برج الجرس المرتفع ، لأن هناك مصالح مشتركة ، يشاركون في المتشابكين ، وكل هذا لا يبدو أنه يثير قلقك - اذهبوا ، أتباع ، "دعوهم يأكلون الكعك" .

سيرجي: العكس تماما. تحاول اللجنة الاختيار حتى لا يعاني الشخص العادي. وغالبًا ما يكون الأمر صعبًا.

ديمتري: حسنًا ، أستطيع أن أقول لنفسي إنني لن أعاني إذا كانت تكلفة الصفر تسير في مكان ما ، لكن سيكون هناك نوع من الفرص المرنة للسير على طول الشجرة الثنائية والتكرار بطرق مختلفة دون متغيرات زمنية. yield, - - — , , , , - .

: , , , , - .

: , Boost .

: , . Boost , , , … - . std::string, , . size(), length(), : , - ? - , , . , . , , , . , , , - .




: , , , . ?

: , , «», .

: .

: embedded-, include, ?

: . embedded -.

, , - ? , , . ?

: . 150 . - , . .

: , !

: , Steam, , , 64 . , 150 ?

: , , .

: , -. ? , , , — , zero cost abstractions . -?

: , , , , ?

: , . , , .

: , , , . — , . , . , , . , . -. C.

: . «». : , . , , , . . , .

: , . . , . proposal. .

: , proposal. , « »: , STL , . , - , .

: STL . STL . , , STL — , , .

: , — , ? , greenfield. brownfield development, . — , . — . ?

: , . , , . , . , , . G++ , Clang . .

: , , , . « , A, B». , .NET, . , , , , , ?

: , , . , C++ 2.0. ++C++. , C.

: , . , , . , , , , #include #import - — . , . , , , , .

. , . , , , C# C++, .

: , , 10 . , , , , , , . « », . , .

C# , C++. , C# . , , . , , , , JIT' — , , - ( int). , , , , .

: , , , C# — . , , C++ . , . ( , ) — cutting edge. , UI- C++, , . C# — . C++ , .

, . , , , C++ , , , . , .

, C# Microsoft. , .NET Foundation, , , Microsoft. , .



C++ Russia DotNext . : ?

Source: https://habr.com/ru/post/ar469467/


All Articles