🗿 📝 🚶🏽 تمت الموافقة على C ++ 20! ما يمكن توقعه وما يجب الاستعداد له للمطورين في C ++ 23 👨‍💻 💒 👛

في اليوم الآخر في براغ ، تم عقد اجتماع للجنة التقييس الدولية C ++. And-and-and-and ...

C ++ 20 جاهز! يبقى وضع طابع من ISO ، ولكن هذه خطوة رسمية بحتة لا ينبغي أن تكون هناك مشاكل.

مبروك للجميع على هذا الحدث الرائع! المفاهيم ، Coroutines ، الوحدات النمطية ، النطاقات ، تنسيق std :: format ، constexpr الجديدة وخوارزميات constexpr + سلسلة المتجهات + ، التاريخ والوقت ، jthread ، span ، bit_cast والعديد من الابتكارات الصغيرة والكبيرة الأخرى.

ما تمكنوا من إضافته وإصلاحه في اللحظة الأخيرة ، وما اقترحوا كسره وما يريد الجميع رؤيته في C ++ 23 - حول كل هذا تحت الخفض.

الحيل من C إلى C ++ 20

في الآونة الأخيرة ، كان هناك تقليد في إخافة المطورين المبتدئين بسلوك غير محدد (UB) في C ++. حان الوقت لتغييره!

هنا ، على سبيل المثال ، هذا الرمز صالح تمامًا لـ C:

struct X { int a, b; };

X *make_x() {
  X *p = (X*)malloc(sizeof(struct X));
  p->a = 1;
  p->b = 2;
  return p;
}

ولكن في C ++ كانت هناك مشاكل كبيرة معها. يعمل C بالبايت ، ويعمل C ++ مع الكائنات. لكن الكائن له عمر ، وقبل C ++ 20 ، تم اعتبار بداية عمر الكائن من المكالمة الجديدة.

تشعر اللجنة بقلق بالغ إزاء العمل منخفض المستوى مع وحدات البايت والهياكل البسيطة. تبنوا التحسينات التي تقول أن مجموعة معينة من الوظائف (memcpy ، memmove ، malloc ، align_alloc ، calloc ، realloc ، bit_cast) تبدأ عمر الكائن. الآن مضمونة معظم الحيل C ذات المستوى المنخفض للعمل في C ++.

أصبحت bool أكثر موثوقية في C ++ 20

خمن ما هو الخطأ:

template <typename T, size_t N>
auto count_unique(const std::array<T, N>& v) {
    return std::unordered_set<T>{v.begin(), v.end()}.size();
}

إجابة

T bool v.begin() v.end() (, libc++ libstdc++) — count_unique 1.

- , std::unordered_set<bool>{v.begin(), v.end()} bool std::unordered_set<bool>{true, true}.

تعتبر التحولات في منطقية الآن تضييق التحولات. سمح لنا هذا بالعثور على مشاكل في العديد من ملفات التعليمات البرمجية (المزيد من الأمثلة في جملة P1957 نفسها ).

جعل C ++ 20 مفاهيم أسرع

حتى وقت قريب ، يمكنك كتابة مفهوم مثل هذا:

template <class T>
concept Reservable = requires(T v) {
    v.reserve(int{});
};

وندهش أنها ترجع نتائج مختلفة:

struct Test;

static_assert(!Reservable<Test>);

struct Test {
    void reserve(int);
};

static_assert(Reservable<Test>);

في المرة الأخيرة ، أرسلنا تعليقًا من البلد: "اجعل من المستحيل استخدام نوع غير مكتمل في المفاهيم ، وإلا فإنك تحصل على العديد من انتهاكات ODR". تم رفض تعليقنا ، ولكننا حصلنا جزئيًا على النتيجة المرجوة الآن مع الاقتراح P2104.

كمكافأة ، نحصل على تجميع أسرع ، حيث يحق للمجمعين الآن تخزين نتائج تطبيق المفاهيم على الأنواع مؤقتًا.

تعديلات طفيفة في C ++ 20

حصلت النطاقات على طريقة الحجم.
لم يعد الارتباط الداخلي للكيانات مرئيًا عند إنشاء كيانات ربط الوحدة النمطية (سيخبرك المترجم بما هو خطأ في مرحلة التجميع).
قمنا بلف قواعد الوحدات بحيث يسهل على أي أداة العمل معها.

ودعنا نكسر كل شيء في C ++ 23 أو C ++ 26؟

أثار النقاش المطول اقتراحًا لواجهة التطبيق الثنائية (ABI ، لا تخلط مع API). أثيرت أسئلة مثيرة للاهتمام:

1. يمكننا تغيير ABI بالكامل في C ++ 23 والحصول على مكاسب أداء 5-10٪.

علاوة على ذلك ، يجب إعادة بناء جميع مكتبات C ++ القديمة ، ولن تكون قادرة على الارتباط بالمكتبات مع ABI الجديد. لا يمكنك استخدام مكتبات تم إنشاؤها بواسطة إصدارات سابقة من C ++ في مشروع C ++ 23.

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

مع هامش طفيف من التصويت ، قررت ABI عدم اختراق C ++ 23.

2. لنمنح المستخدمين ضمانًا بأننا سنحاول عدم كسر / تغيير ABI.

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

ودعنا نضيف في كل مكان لا يوجد استثناء؟

تاريخيًا ، في الوظائف القياسية مع الشروط المسبقة ، لم يتم وضع علامة عليها على أنها لا توجد استثناء ، حتى لو لم ترمي استثناءات. هنا ، على سبيل المثال ، عامل التشغيل -> have std :: Optional:

constexpr const T* operator->() const;
constexpr T* operator->();
    Requires: *this contains a value.
    Returns: val.
    Throws: Nothing.

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

سيكون المستخدمون الذين ليس لديهم استثناء أكثر وضوحًا. فكرة جيدة في P1656 !

لا!

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

لكن هذه ليست أكبر مشكلة. هناك شوكات من المكتبات القياسية ، والتي أصبحت الآن بالفعل في بعض الحالات تُدرج صراحة عمليات التحقق من الشروط المسبقة. على سبيل المثال ، هل لديك مشروع حاسم ، يجب زيادة توافره إلى أقصى حد. يمكنك استخدام شوكة مماثلة ، وإذا أطلق شخص فجأة اسم std :: vector :: back () لناقل فارغ ، فسيتم طرح استثناء ، والذي تتم معالجته أعلى في التعليمات البرمجية ويبدأ استخدام الاحتياط. مع تعديلات من P1656 ، لم يعد من الممكن اعتبار هذه المكتبة قياسية.

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

مزايا RG21

كما هو الحال دائمًا ، عملنا في مجموعات فرعية مختلفة ، وتجربة تنفيذ مشتركة ، وقدمنا مقترحات ، ولم يتمكن مؤلفوها من الحضور.

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

لقد نجحنا في سحب الفكرة من خلال حالتين EWG-I و EWG بفضل التفصيل الممتاز للفكرة من قبل المؤلف نفسه. ظلت مرحلة CWG ، وبعد بضعة اجتماعات ، هناك كل فرصة لرؤية الكلمات الضرورية في المعيار ، والتطبيقات الأولى في المجمعين.

بالإضافة إلى هذه الفكرة ، قمنا بسحب فكرة P1990R0: إضافة عامل [] إلى std :: Initizer_list عبر LEWG-I ، وحصلنا على تعليقات مفيدة حول P1944R0: constexpr <cstring> و <cwchar> . كلتا فكرتي دانييل جونشاروف لديها كل فرصة لتكون في C ++ 23.

في مجال std :: hash ، انتظرنا فشل غير متوقع. مناقشة p1406r1: إضافة المزيد من تخصصات std :: hash تحولت فجأة إلى مناقشة حالات الحدود المتدهورة وإمكانيات C ++ 2 البعيدة. ونتيجة لذلك ، قررت اللجنة عدم تغيير أي شيء.

مع SG6 والأرقام لم تنمو معا. تتقاطع المناقشات الرئيسية للجنة الدراسات 6 مع مناقشات مؤشر كتلة المحرك ، وهذا هو سبب عدم تراكم النصاب القانوني في لجنة الدراسات 6. وبسبب هذا p1889: عمل أرقام C ++ قيد التقدم ، P2010: إزالة عوامل تشغيل iostream من P1889 وP1890: لم تتم مناقشة مشكلات العمل الرقمي في C ++ .

خطط C ++ 23

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

بالنسبة لـ C ++ 23 ، تمت الموافقة على هذه الخطة للتو في براغ. الأولويات الرئيسية لـ C ++ 23:

دعم Corutin في المكتبة القياسية
تحويل المكتبة القياسية إلى وحدات
المنفذون
التواصل

في الفقرة الأولى ، سيسترشد الجميع بمكتبة CppCoro . لذلك إذا كنت ترغب بالفعل في استخدام Coruteines C ++ 20 ، يجب أن تبدأ باستخدام هذه المكتبة.

مع الوحدات ، النقطة الثانية ، تحتاج فقط إلى الجلوس والقيام بذلك ، ولا يتوقع صعوبات خاصة.

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

كما وافقت اللجنة على تحديد أولويات المقترحات في المجالات التالية:

انعكاس
نمط مطابقة
انكماش

بدلا من المجاميع

C ++ 20 جاهز ، لقد حان الوقت للعمل على C ++ 23! سيكون اجتماع اللجنة التالي في الصيف ، لذلك إذا كانت لديك فكرة جيدة عن المعيار الجديد - فقم بمشاركتها على stdcpp.ru و ProCxx للدردشة عبر Telegram .

حسنًا ، كل من يريد الدردشة مع ممثلي اللجنة مباشرة - انظر إلى الاجتماعات ومؤتمرات C ++ *:

* الإختراق مدى الحياة: لا يتعين عليك دفع ثمن تذكرة المؤتمر إذا كنت متحدثًا.

تمت الموافقة على C ++ 20! ما يمكن توقعه وما يجب الاستعداد له للمطورين في C ++ 23