أنماط بناء جملة C++ المصبوبة

Question

سؤال يتعلق ب طاقم الممثلين العاديين مقابل.static_cast مقابل.Dynamic_cast:

ما هو نمط بناء الجملة الذي تفضله في C++؟

• بناء الجملة على النمط C: (int)foo
• بناء جملة نمط C++: static_cast<int>(foo)
• بناء جملة المنشئ: int(foo)

قد لا تترجم إلى نفس التعليمات بالضبط (هل هي كذلك؟) ولكن تأثيرها يجب أن يكون هو نفسه (أليس كذلك؟).

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

ماذا تعتقد؟

Answer 1

إنها أفضل الممارسات أبداً لاستخدام قوالب النمط C لثلاثة أسباب رئيسية:

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

كما لاحظ palm3D:

أجد أن بناء جملة نمط C++ مطول للغاية.

وهذا مقصود للأسباب المذكورة أعلاه.

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

void f(auto_ptr<int> x);

f(static_cast<auto_ptr<int> >(new int(5))); // GOOD
f(auto_ptr<int>(new int(5));                // BAD

ال static_cast هنا سوف ندعو في الواقع auto_ptr البناء.

Answer 2

وفق ستروستروب:

تم تقديم "الممثلين على الطراز الجديد" لمنح المبرمجين فرصة لتوضيح نواياهم بشكل أكثر وضوحًا وللترجم لالتقاط المزيد من الأخطاء.

لذا، فهو من أجل السلامة لأنه يقوم بفحص إضافي لوقت الترجمة.

Answer 3

وفيما يتعلق بهذا الموضوع، فأنا أتبع التوصيات التي قدمها سكوت مايرز (أكثر فعالية C++, البند 2 :تفضل القوالب بأسلوب C++).

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

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

Answer 4

أستخدم static_cast لسببين.

1. من الواضح تمامًا ما يحدث.لا أستطيع قراءة ذلك دون أن أدرك أن هناك طاقمًا يحدث.باستخدام القوالب ذات النمط C، يمكنك المرور فوقها مباشرة دون توقف.
2. من السهل البحث عن كل مكان في الكود الخاص بي حيث أقوم بالإرسال.

Answer 5

بالتأكيد أسلوب C++.ستساعدك الكتابة الإضافية على منعك من الإرسال عندما لا ينبغي لك ذلك :-)

Answer 6

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

Answer 7

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

Answer 8

نحن نستخدم حاليًا قوالب على طراز C في كل مكان.سألت الآخر سؤال الصب, ، وأرى الآن ميزة استخدام static_cast بدلاً من ذلك، إذا لم يكن هناك سبب آخر غير أنه "قابل للتأثر" (يعجبني هذا المصطلح).ربما سأبدأ في استخدام ذلك.

أنا لا أحب أسلوب C++؛يبدو كثيرًا مثل استدعاء دالة.

Answer 9

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

Answer 10

بناء جملة المنشئ.C++ هو OO، المنشئات موجودة، وأنا أستخدمها.إذا شعرت بالحاجة إلى إضافة تعليقات توضيحية إلى عوامل التحويل هذه، فيجب عليك القيام بذلك لكل نوع، وليس فقط الأنواع المضمنة.ربما تستخدم الكلمة الأساسية "الصريحة" لموجهات التحويل ولكن بناء جملة العميل يحاكي تمامًا ما يفعله بناء جملة الموجه للأنواع المضمنة.قد يكون هذا صحيحًا، ولكن يا لها من مفاجأة كبيرة أن كتابة المزيد من الأحرف يجعل عمليات البحث سهلة.لماذا التعامل مع هؤلاء على أنهم مميزون؟إذا كنت تكتب صيغًا رياضية تحتوي على الكثير من الأحرف int/unsigned/...من وإلى double/float - الرسومات - وتحتاج إلى كتابة static_cast في كل مرة، يصبح مظهر الصيغة مزدحمًا وغير قابل للقراءة إلى حد كبير.وهي معركة شاقة على أي حال، ففي كثير من الأحيان سوف تقوم بالتحول دون أن تلاحظ ذلك.بالنسبة لمؤشرات البث الهابط، أستخدم static_cast لأنه بالطبع لا يوجد ctor افتراضيًا من شأنه أن يفعل ذلك.