مسودة الأسئلة الشائعة: لماذا تظهر معايير C ++ كل ثلاث سنوات؟

لدى WG21 جدول زمني صارم (انظر P1000 ) للإصدار القياسي كل ثلاث سنوات. ولا تأخير.

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

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

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

هناك أخطاء في المعيار ، يجب عليك تأجيل C ++ 20؟

بالطبع نعم ولا.

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

إذا كان لدينا اجتماع أو اجتماعان آخران ، فيمكننا إضافة <اسم ميزة> ، وهو جاهز تقريبًا ، فهل يجب عليك تأجيل C ++ 20؟

بالطبع نعم ولا.

انتظر حتى يتم عقد اجتماعين آخرين (بعد براغ) ، وسيتم فتح C ++ 23 للعمل ، وقبل كل شيء سنصوت لإضافة <اسم الميزة> إلى مسودة العمل لـ C ++ 23. هذا ما فعلناه بالمفاهيم: لم تكن جاهزة للانتقال من TS مباشرة إلى C ++ 17. لذلك ، في الاجتماع الأول حول C ++ 20 (في تورونتو) ، صوتوا لنقل الوظيفة الأساسية للمفاهيم إلى مسودة C ++ 20 ، والتي أعطت الكثير من الوقت لتحسين وتنقيح الجزء المتبقي من TS (بناء جملة غير "قالب") ، والذي تم تقديمه العام المقبل (سان دييغو). الآن جميع وظائف جاهزة.

يبدو أن هذا صارم للغاية. لماذا تطلق إصدارات IS على فترات زمنية محددة (ثلاث سنوات)؟

لأنه في حالة إصدار C ++ IS ، يعد هذا أحد الخيارين الرئيسيين لإدارة المشروع ، وتُظهر التجربة أن هذا الخيار أفضل من الخيار الثاني.

ما الخياران لإدارة المشروع لإصدار C ++ IS؟

سعيد سألت.

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


أشرح:

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

لذلك كان مع C ++ 98 (كان من المتوقع حوالي عام 1994 ، وقال بيورن أنه إذا لم يخرج الإصدار بحلول ذلك الوقت سيكون فاشلا) مع C ++ 11 (كان يطلق عليه 0x لأن x كان متوقعا بحلول عام 2007 ). هذا هو نهج "ترك المريض دون حماية" لفترة غير محددة ، مما أدى إلى تأخير في اختبار الاندماج والإفراج عنه. وهذا بدوره أدى إلى حالة عدم يقين كبيرة في السوق فيما يتعلق بتوقيت المعيار التالي ، وما إذا كان سيتم إصداره على الإطلاق (نعم ، لن يظهر المشاركون في التنمية فحسب ، بل حتى بعض أعضاء اللجنة المشكوك فيهم بشكل خطير في عامي 1996 و 2009 ، هل هناك أي الإصدارات ذات الصلة). لسنوات عديدة ، لم يستوف معظم المترجمين المعيار ، لأنه لا أحد يعرف عدد التغييرات غير المتوافقة التي ستطرحها اللجنة في الإصدار الجديد ، أو متى سيكون متوقعًا على الإطلاق؟ وقد أدى ذلك إلى مجموعة واسعة من تجزئة ودعم C ++ في المجمعين المتاحة للمجتمع.

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

لحسن الحظ ، لقد تغير كل شيء بفضل الخيار (2).

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

لقد تم التمسك بهذا النهج منذ عام 2012 ولا نريد التخلي عنه. هذا هو نهج "ترقيع المريض بانتظام" ، والذي يؤدي إلى توقع جودة أعلى بسبب الدمج المنتظم القسري ورفض إضافة العمل إلى مسودة IS حتى يصل إلى مستوى معين من الاستقرار ، عادة داخل فرع الميزة. كما أنه يخلق دورة إطلاق يمكن التنبؤ بها يمكن للسوق الاعتماد عليها. على مر السنين ، بدأ مؤلفو المجمعين في وقت مبكر وقبل ذلك ، بعد الإصدار التالي ، بإصدار إصدارات من منتجاتهم مطابقة للمعايير ، والتي لم تحدث من قبل. وفي عام 2020 ، نتوقع إصدار تطبيقات متوافقة تمامًا في عام واحد مع إصدار المعيار ، والذي لم يحدث أيضًا من قبل. هذا هو فقط لصالح السوق بأكمله - المطورين والمستخدمين والمعلمين.

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

ما مدى جادتك في المنهج (2)؟ إذا ، وفقًا لعضو موثوق به في اللجنة ، فإن بعض الميزات الكبيرة "جاهزة تقريبًا" ، فعندئذٍ ستغري الانتظار قليلاً ، أليس كذلك؟

على محمل الجد ، ولا.

لدينا إحصاءات: في عام 2016 في جاكسونفيل ، عندما قررنا أخيرًا ميزات C ++ 17 ، تحدث بيورن ستراوستروب في جلسة عامة باقتراح تضمين مفاهيم في C ++ 17. عندما لم يتم التوصل إلى توافق في الآراء ، سُئل Straustrup مباشرة عما إذا كان يريد تأخير إصدار C ++ 17 لمدة عام من أجل تضمين المفاهيم فيه. أجاب بيورن "لا" دون أي تردد أو تهرب ، وأضاف أن C ++ 17 بدون مفاهيم كان أكثر أهمية من C ++ 18 أو C ++ 19 مع المفاهيم ، على الرغم من أن Straustrup كان يعمل عليها لمدة 15 عامًا تقريبًا. كان الخيار هو هذا: (2) نصدر C ++ 17 بدون مفاهيم ، ثم C ++ 20 مع المفاهيم (التي فعلناها) ، أو (1) نعيد تسمية C ++ 17 إلى C ++ 20 ، وهو متماثل (2) باستثناء تخطي C ++ 17 ورفض إصدار ما كان جاهزًا بالفعل لـ C ++ 17.

ماذا عن المفاضلة بين (1) و (2)؟ قل ، نحن نلتزم عادةً بـ (2) ، ولكن مع مرونة "قليلة" من حيث الحصول على وقت إضافي "قليل" ، إذا كنت بحاجة إلى تحسين الميزة؟

لا ، لأنه اتضح (1).

أوضح فريد بروكس في The Manthical Man-Month شعبيا "التحول الصغير الأسطوري" وخلص إلى: " لا تسمح بأي عمليات نقل صغيرة ".

تخيل أننا استدار C ++ 20. سيتعين علينا العودة من (2) إلى (1) ، بغض النظر عن مدى صعوبة محاولة تجنبه ، وفي نفس الوقت لن نتلقى أي فوائد. إذا قررنا تأجيل C ++ 20 لتلميعها ، فسنؤجل المعيار لمدة عامين على الأقل. لا توجد مفاهيم مثل نقل اجتماع واحد أو ثلاثة اجتماعات ، لأنه خلال هذا الوقت ستستمر اجتماعات أخرى (إلى حد ما) في القول: "حسنًا ، تحتاج مقالي إلى اجتماع آخر فقط ، وما زلنا نعيد جدولته ، فلننقل اجتماعًا آخر". وإذا نقلنا عامين على الأقل ، فهذا يعني أن C ++ 20 تصبح C ++ 22 ، وعلى الأرجح C ++ 23 ... لكننا سنقوم بالفعل بشحن C ++ 23! - على أي حال ، سوف نقوم بشحن C ++ 23 ، والفرق الوحيد هو أننا لا ننقل C ++ 20 مع قدر كبير من العمل المنجز ، وعلى استعداد للنشر ، ولا نجعل العالم كله ينتظر ثلاث سنوات أخرى. التأخير لن يستفيد من هذه الميزات ، معظمها أو جميعها معًا.

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

لكن الميزة X مقطوعة / يستغرق الأمر وقتًا أطول مما تركنا لإصلاح الخلل في C ++ 20!

لا سؤال! يمكننا قطع فقط.

في هذه الحالة ، سيحتاج شخص ما إلى كتابة خطاب في EWG أو LEWG (اعتمادًا على الموقف) مع وصف للوضع ، وعرض إزالة الميزة من مسودة العمل IS. ستنظر هذه المجموعات في الطعن ، وإذا قررت أن الميزة قد توقفت (وتوافق عليها الجلسة المكتملة) ، فسيتم تأجيلها حتى الإصدار C ++ التالي. لقد فعلنا هذا بالفعل باستخدام مفاهيم C ++ 0x.

لكن في حالة (1) ، سننقل ليس فقط هذه الميزة ، ولكن مجموعة كاملة من الميزات من C ++ 20 إلى C ++ 23! سيكون ذلك ... تمثال نصفي.

هل النهج (2) يعني الإصدارات "الرئيسية / الثانوية"؟

لا. في البداية قلنا هذا إلى أن أدركنا أن (2) يعني فقط أنك لست بحاجة إلى اختيار مجموعة من الميزات حتى من وجهة نظر الإصدار "الرئيسي / الثانوي".

النهج (2) يعني فقط "نحن نشحن ما هو جاهز". يتم الحصول على الإصدارات:

• يكون الحجم نفسه (أي المتوسط ​​عادة) للميزات "أصغر" لأنه يتم إنفاق وقت أقل على تطويرها (على سبيل المثال ، أقل من ثلاث سنوات لكل منهما) ، وبصفة عامة نحصل على نفس عدد الميزات المكتملة في الإصدار ؛
  
• وحجم متغير (ليس ضروريًا مرة واحدة أو مرتين) للميزات "الأكبر" ، والتي تستغرق وقتًا أطول (على سبيل المثال ، أكثر من ثلاث سنوات لكل منها) ، ويتضمن كل إصدار من إصدارات IS أكبر عدد ممكن من هذه الميزات أثناء إدارته لإكماله للإصدار. لذلك ، في بعض الإصدارات هناك أكثر ، في إصدارات أخرى أقل.
  

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

C ++ 20 هو إصدار رائع ...

نعم. يحتوي C ++ 20 على العديد من الميزات الرئيسية. ثلاثة من أكبر تبدأ بـ "ko" (مفاهيم ، عقود ، coroutines) ، لذلك يمكن أن نسميها co_cpp20. أو مترابطة.

... ولم يتم الكثير في دورة السنوات الثلاث لـ C ++ 20؟

لا ، انظر أعلاه "مرة واحدة في كل مرة ليست ضرورية."

C ++ 20 كبير ، ليس لأننا قمنا بالكثير في ثلاث سنوات ، ولكن لأن هناك الكثير من التطورات الطويلة (بما في ذلك تطوران على الأقل كنا نعمل عليهما في الشكل الحالي منذ عام 2012 في شكل جمل P- وفروع TS ) وصلت إلى مرحلة الاستعداد وقرروا إدراجها في مسودة IS الخاصة بالإصدار نفسه.

دائمًا تقريبًا ، يتم تطوير الميزات الرئيسية لسنوات عديدة. الفرق الرئيسي بين الأسلوب (1) لـ C ++ 98 و C ++ 11 والنهج (2) هو أنه في C ++ 98 و C ++ 11 تأخر الإصدار حتى أصبحت جميع هذه الميزات جاهزة ، والآن نقوم بشحن كبير حالما تصبح جاهزة ، ومعهم سنصدر المزيد.

مرت C ++ 20 بنفس دورة الثلاث سنوات مثل C ++ 14 و C ++ 17. لم نفعل الكثير في السنوات الثلاث الماضية أكثر من الدورتين السابقتين ، لقد أضفنا المزيد إلى الميزات الرئيسية. إذا لم يكن أي منهم جاهزًا ، فعندئذٍ كنا نرميها وننهيها بالفعل لـ C ++ 23. إذا حدث هذا ، فسوف نُبلغ عن ذلك في اقتراح التنفيذ ونوضح الأسباب.

شكلت C ++ 14 + 17 + 20 الدورة الثالثة من تسع سنوات (2011-2020) بعد C ++ 98 (1989-1998) و C ++ 11 (2002-2011). لكن بما أننا التزمنا بالاقتراب (2) ، فقد أصدرنا أيضًا تطورات كانت جاهزة لنهاية ثلاث سنوات ودورات مدتها ست سنوات.

أليس من الأفضل التقاط الأخطاء عندما يكون المنتج قيد التطوير ، وليس بعد إصداره؟

بالطبع هذا أفضل.

ولكن إذا كنا نتحدث عن أسباب التأخير في إصدار معيار C ++ ، فإن هذا السؤال ينطوي على افتراضين كاذبين:

• قبل إصدار المعيار ، لم تخرج الميزات ولم تستخدم (بالنسبة للكثيرين ، هناك بالفعل خبرة في الإنتاج) ؛
  
• وأنه يمكن استخدام جميع الميزات معًا حتى يتم إصدار المعيار (غير مسموح به).
  

أشرح:

1. تم تطبيق معظم الميزات الرئيسية لـ C ++ 20 بالشكل الذي تنعكس فيه في المسودة الحالية للمعيار في مترجم واحد على الأقل ، وفي معظم الحالات تم استخدامها بالفعل في كود الإنتاج (أي ، أنها متاحة بالفعل للمستخدمين الذين يشعرون بالرضا الشديد) . على سبيل المثال ، تم استخدام coroutines (تم تقديمه قبل خمسة أشهر فقط من هذه المقالة) لمدة عامين في الإنتاج في MSVC وسنة واحدة في Clang ، والتي كانت مسرورة للغاية مع العملاء الكبار (على سبيل المثال ، Azure و Facebook).
2. لن نواجه العديد من مشكلات التفاعل بين الميزات حتى يبدأ المستخدمون في استخدامها ، أي قبل إصدار المعيار ، لأن العديد من المطورين سينتظرون إصداره من أجل تنفيذ مشاريع مختلفة. وإذا أظهرنا حالة من عدم اليقين بشأن توقيت الإصدار ، فسيتم أيضًا تأخير هذه التطبيقات. حسنًا ، ما زالوا ينفذون شيئًا ما ، لكن سيتم إيقاف الكثير حتى يتأكد المطورون من استعدادنا للإفراج عنهم. اسأل منشئي <اسم المترجم المفضل> عما حدث عندما قاموا بتطبيق <اسم ميزة كبيرة> قبل ظهوره في المعيار المنشور. في كثير من الحالات ، من الضروري أن تنفذ بشكل متكرر ، وقطع المستهلكين بشكل متكرر. لذلك ، يفضل المطورون انتظار موافقة اللجنة على بعض الميزات.

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

المعيار لن يكون مثاليًا ... ألا تطلق العنان؟

نعم.

إذا رأينا أن هذه الميزة غير جاهزة ، فعلينا إزالتها من الإصدار.

إذا رأينا أن الميزة يمكن أن تكون أفضل ، ونعلم أن التغيير قد يكون متوافقًا مع الإصدارات السابقة ، فهذا ليس سببًا لرفض إصداره الآن. يمكن إصداره كملحق في C ++ التالية.

نصدر عن عمد ميزات نعتزم تحسينها في المستقبل ، بينما نحن واثقون من أننا نستطيع الحفاظ على التوافق مع الإصدارات السابقة.

لكن ألا تحاول تقليل أخطاء الإطلاق؟

نعم. نحن نحاول.

لكننا لا نحاول تجنب كل المخاطر. هناك أيضًا خطر (ممكن) وسعر رفض الإفصاح عما يبدو جاهزًا لنا. وفي أكثر الأحيان ، نحن على صواب.

هل أنت متأكد من أن الجودة الآن أفضل من استخدام النهج (1)؟

نعم.

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

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

تم تطوير C ++ 98 و C ++ 11 لمدة 9 سنوات وكانت منتجات جيدة جدًا ...

نعم: 1989-1998 و 2002-2011.

... و C ++ 14 و C ++ 17 كانت إصدارات ثانوية. هل C ++ 20 إصدار رئيسي؟

أكرر ، أعتقد أنه من الصحيح مقارنة C ++ 14 + 17 + 20 ككل: هذه هي دورة مدتها تسع سنوات ، لكن بما أننا التزمنا بالاقتراب (2) ، فقد أصدرنا أيضًا تلك التطورات التي كانت جاهزة لإكمال دورات مدتها ثلاث سنوات وست سنوات .

المنهج (2) يسمح لك بتحقيق أهداف قائمة على الميزات مثل P0592 لـ C ++ التالية؟

بالطبع! على الرغم من عدم وجود كلمات فيه مثل "يجب أن تتضمن هذه الميزات" ، فحينئذٍ سيكون النهج (1).

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