المفاهيم التي تظهر في C ++ 20 هي موضوع طويل ومناقش على نطاق واسع. على الرغم من فائض المواد المتراكمة على مر السنين (بما في ذلك خطب الخبراء من الطراز العالمي) ، لا يزال هناك خلط بين المبرمجين التطبيقيين (الذين لا ينامون يوميًا مع المعيار) ما هي مفاهيم C ++ 20 وما هي نحتاج إذا كان هناك enable_if محددًا على مر السنين. يكمن الخطأ جزئيًا في كيفية تطور المفاهيم على مدار 15 عامًا تقريبًا (Concepts Full + Concept Map -> Concepts Lite) ، ويرجع ذلك جزئيًا إلى أن المفاهيم اتضح أنها تختلف عن الأدوات المماثلة في لغات أخرى (Java / C # bounds generounds ، Rust Rust ،. ..).

تحت مقطع الفيديو ونسخة لتقرير أعده أندريه دافيدوف من فريق ReSharper C ++ من مؤتمر C ++ Russia 2019 . قام أندري بمراجعة مختصرة للابتكارات المتعلقة بمفهوم C ++ 20 ، وبعد ذلك درس تنفيذ بعض فئات ووظائف STL ، مقارنة بين C ++ 17 و C ++ 20. كذلك القصة هي نيابة عنه.

نتحدث عن المفاهيم. هذا موضوع معقد وشامل إلى حد ما ، لذلك عند الإعداد للتقرير ، كنت في بعض الصعوبات. قررت أن أنتقل إلى تجربة أحد أفضل المتحدثين في مجتمع C ++ Andrei Alexandrescu .

في نوفمبر 2018 ، أثناء حديثه في افتتاح الاجتماع C ++ ، سأل Andrei الجمهور عما ستكون عليه الميزة الكبيرة التالية لـ C ++:

• المفاهيم
• metaclasses
• أو التأمل؟

لنبدأ بهذا السؤال. هل تعتقد أن الميزة الكبيرة التالية في C ++ ستكون مفاهيم؟

وفقا ل Alexandrescu ، المفاهيم مملة. هذا هو الشيء الممل الذي أقترحه عليك. علاوة على ذلك ، ما زلت غير قادر على الحديث المثير للاهتمام والحار عن المشابك ، مثل Herb Sutter ، أو حول التأمل ، مثل Alexandrescu.

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

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

 template <typename T> concept NoThrowDefaultConstructible = noexept(T{}); template <typename From, typename To> concept Assignable = std::is_assignable_v<From, To> 

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

 template<int I> concept Even = I % 2 == 0; 

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

 template<typename T, size_t MaxSize, size_t MaxAlign> concept Small = sizeof(T) <= MaxSize && alignof(T) <= MaxAlign; 

ربما ، لم يتضح بعد سبب حاجتنا إلى سياج كيان جديد في اللغة ، ولماذا هذا المفهوم ليس مجرد متغير constexpr bool .

 //  `concept`    ? #define concept constexpr bool 

كيف يتم استخدام المفاهيم؟

لفهم ، دعونا نرى كيف يتم استخدام المفاهيم.

أولاً ، تمامًا مثل متغيرات constexpr bool ، يمكن استخدامها أينما كنت بحاجة إلى تعبير منطقي في وقت الترجمة. على سبيل المثال ، داخل static_assert أو داخل noexcept
المواصفات:

 // bool expression evaluated in compile-time static_assert(Assignable<float, int>); template<typename T> void test() noexcept(NothrowDefaultConstructible<T>) { T t; ... } 

ثانياً ، يمكن استخدام المفاهيم بدلاً من الكلمات الأساسية class أو class عند تحديد معلمات القالب. حدد فئة optional بسيطة من شأنها ببساطة تخزين زوج من العلامة المنطقية التي تمت initialized والقيم. وبطبيعة الحال ، ينطبق هذا optional فقط على أنواع تافهة. لذلك ، نكتب Trivial هنا وعندما نحاول إنشاء مثيل من شيء غير تافه ، على سبيل المثال ، من std::string ، سيكون لدينا خطأ في الترجمة:

 //  type-parameter-key (class, typename) template<Trivial T> class simple_optional { T value; bool initialized = false; ... }; 

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

 //   class any { struct SB { static constexpr size_t Size = ...; static constexpr size_t Alignment = ...; aligned_storage_t<Size, Alignment> storage; }; union { SB sb; void* handle; }; template<Small<SB::Size, SB::Alignment> T> any(T const & t) : sb(...) ... }; 

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

 // Terse syntax (  auto) class any { struct SB { static constexpr size_t Size = ...; static constexpr size_t Alignment = ...; aligned_storage_t<Size, Alignment> storage; }; union { SB sb; void* handle; }; any(Small<SB::Size, SB::Alignment> auto const & t) : sb(...) ... }; 

ربما ، في أي مكان نكتب فيه auto ، يمكنك الآن كتابة اسم المفهوم أمامه.

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

 //Terse syntax (  auto) template<typename T> concept LEPtr = Small<T, sizeof(void *), alignof(void *)>; template<typename T> auto get_handle(T& object) { if constexpr (LEPtr<T>) return object; else return &object; } 

في C ++ 20 ، سيكون من الممكن الكتابة قبل أن تكون ليست auto فقط ، بل هي محدودة auto :

 // Terse syntax (  auto) template<typename T> concept LEPtr = Small<T, sizeof(void *), alignof(void *)>; template<typename T> LEPtr auto get_handle(T &object) { if constexpr (LEPtr<T>) return object; else return &object; } 

يتطلب التعبير

يتطلب التعبير عبارة عن عائلة كاملة من التعبير ، وكلها من النوع bool وتحسب في وقت الترجمة. يتم استخدامها لاختبار عبارات حول التعبيرات والأنواع. يتطلب التعبير مفيدًا جدًا لتحديد المفاهيم.

مثال Constructible . أولئك الذين كانوا في تقريري السابق رأوه بالفعل:

 template<typename T, typename... Args> concept Constructible = requires(Args... args) { T{args...} }; 

ومثال مع Comparable . دعنا نقول أن النوع T قابل Comparable إذا كان يمكن Comparable كائنين من النوع T باستخدام عامل التشغيل "الأقل" ويتم تحويل النتيجة إلى bool . هذا السهم والنوع بعده يعني أن تعبير الكتابة يتم تحويله إلى bool ، وليس مساوياً لـ bool :

 template<typename T> concept Comparable = requires(T const & a, T const & b) { {a < b} -> bool; }; 

ما درسناه بالفعل كافٍ لإظهار مثال كامل لاستخدام المفاهيم.

لدينا بالفعل مفهوم قابل Comparable ، دعونا نحدد مفاهيم التكرارات. دعنا نقول RandomAccessIterator هو RandomAccessIterator وبعض الخصائص الأخرى. مع هذا ، نحدد مفهوم Sortable . يسمى Range RandomAccess إذا كان يمكن مقارنة مكرر RandomAccess وعناصره. والآن يمكننا كتابة وظيفة sort لا تقبل ذلك فحسب ، ولكن يمكن Sortable Range :

 // concepts,    ++20 template<typename Iterator> concept RandomAccessIterator = BidirectionalIterator<Iterator> && ...; template<typename R> concept Sortable = RandomAccessIterator<Iterator<R>> && Comparable<ValueType<R>>; template<Sortable Range> void sort(Range &) {...} 

الآن ، إذا حاولنا استدعاء هذه الوظيفة من شيء لا يفي بمفهوم Sortable ، فسنحصل على خطأ جيد وصديق لـ SFINAE من المترجم برسالة واضحة. دعنا نحاول إنشاء مثيل std::list 'أو متجه العناصر التي لا يمكن مقارنتها:

 //concepts,    ++20,  struct X {}; void test() { vector<int> vi; sort(vi); // OK list <int> li; sort(li); // Fail, list<int>::iterator is not random access vector< X > vx; sort(vx); // Fail, X is not Comparable } 

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

 //concepts,    ++17 #define concept constexpr bool template<typename T> concept Comparable = is_convertible_v< decltype(declval<T const &>() < declval<T const &>()), bool >; template<typename Iterator> concept RandomAccessIterator = BidirectionalIterator<Iterator> && ...; template<typename R> concept Sortable = RandomAccessIterator<Iterator<R>> && Comparable<ValueType<R>>; template<typename Range, typename = enable_if_t<Sortable<Range>>> void sort(Range &) { ... } 

لقد أدخلت concept الكلمات الرئيسية concept ماكرو ، Comparable إعادة كتابة Comparable بهذه الطريقة. لقد أصبح أقبح قليلاً ، وهذا تلميحات لنا التي تتطلب التعبير هو حقًا شيء مفيد وملائم. لذلك حددنا مفهوم enable_if وباستخدام enable_if إلى أن دالة sort تقبل Sortable Range .

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

المثال أعلاه يبدو أنه مكتوب من خلال المفاهيم. لدي فرضية: هذا المثال غير حاسم ، لأنه لا يستخدم الميزة الرئيسية للمفاهيم - يتطلب فقرة.

يتطلب جملة

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

 // requires-clause template<typename R> concept Sortable = RandomAccessIterator<Iterator<R>> && Comparable<ValueType<R>>; template<Sortable Range> void sort(Range &) { ... } 

حيث في مثالنا المصنف يمكن أن نستخدمه يتطلب جملة؟ بدلاً من بناء جملة مختصر لتطبيق المفاهيم ، نكتب هذا:

 template<typename R> concept Sortable = RandomAccessIterator<Iterator<R>> && Comparable<ValueType<R>>; template<typename Range> requires Sortable<Range> void sort(Range &) { ... } 

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

 //template<typename R> concept Sortable // = RandomAccessIterator<Iterator<R>> && Comparable<ValueType<R>>; template<typename Range> requires RandomAccessIterator<Iterator<Range>> && Comparable<ValueType<Range>>; void sort(Range &) { ... } 

قائمة ملخص بالميزات المتعلقة بالمفهوم

تبدو قائمة الابتكارات المتعلقة بالمفهوم في C ++ 20 هكذا. يتم فرز العناصر الموجودة في هذه القائمة عن طريق زيادة فائدة الميزة من وجهة نظري الشخصية:

• concept كيان جديد. يبدو لي أنه سيكون من الممكن الاستغناء عن جوهر concept عن طريق منح متغيرات constexpr bool مع دلالات إضافية.
• بناء جملة خاص لتطبيق المفاهيم. بالطبع ، إنه ممتع ، لكن هذا مجرد بناء جملة. إذا كان مبرمجو C ++ يخشون بناء الجملة السيئ ، لكانوا قد ماتوا خوفًا منذ فترة طويلة.
• يتطلب التعبير تعبيرًا رائعًا ، وهو مفيد ليس فقط لتحديد المفاهيم.
• تتطلب جملة هي أكبر قيمة للمفاهيم ، فهي تتيح لك نسيان SFINAE وغيرها من الأهوال الأسطورية لقوالب C ++.

أكثر على يتطلب التعبير

قبل الدخول في مناقشة يتطلب جملة ، بضع كلمات حول يتطلب التعبير.

أولاً ، يمكن استخدامها ليس فقط لتحديد المفاهيم. منذ زمن سحيق ، يحتوي برنامج التحويل البرمجي لـ Microsoft على ملحق __if_exists - __if_not_exists . فهو يتيح وقت الترجمة للتحقق من وجود اسم ، وبناءً على ذلك ، قم بتمكين أو تعطيل تجميع كتلة التعليمات البرمجية. وفي قاعدة الشفرات ، التي عملت بها منذ عدة سنوات ، كان الأمر مثل هذا. هناك دالة f() ، تأخذ نقطة من نوع القالب وتستغرق الارتفاع من هذه النقطة. يمكن إنشاء مثيل له بنقطة ثلاثية الأبعاد أو ثنائية الأبعاد. بالنسبة للثلاثي الأبعاد ، فإننا نعتبر أن الإحداثي z هو الارتفاع ، أما بالنسبة للثنائي الأبعاد ، فإننا ننتقل إلى مستشعر خاص للسطح. يبدو مثل هذا:

 struct Point2 { float x, y; }; struct Point3 { float x, y, z; }; template<typename Point> void f(Point const & p) { float h; __if_exists(Point::z) { h = pz; } __if_not_exists(Point::z) { h = sensor.get_height(p); } } 

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

 struct Point2 { float x, y; }; struct Point3 { float x, y, z; }; template<typename Point> void f(Point const & p) { float h; if constexpr(requires { Point::z; }) h = pz; else h = sensor.get_height(p); } 

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

دعنا نعرّف مفهوم Sizable الذي يتحقق من أن الحاوية لها size طريقة ثابت يُرجع size_t . من الطبيعي أن نتوقع أن يكون vector<int> ، ومع ذلك static_assert هذا static_assert . هل تفهم لماذا لدينا خطأ؟ لماذا لا يتم تجميع هذا الرمز؟

 template<typename Container> concept Sizable = requires(Container const & c) { c.size() -> size_t; }; static_assert(Sizable<vector<int>>); // Fail 

اسمحوا لي أن أريك الرمز الذي يجمع. فئة X هذه ترضي مفهوم Sizable . الآن أنت تفهم ما لدينا مشكلة؟

 struct X { struct Inner { int size_t; }; Inner* size() const; }; static_assert(Sizable<X>); // OK 

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

انظر ، لون size_t ، يقف بعد السهم ، قد تغير؟ كنت أرغب في أن يكون نوعًا ما ، لكنه مجرد مجال نصل إليه. كل ما لدينا يتطلب التعبير هو تعبير واحد كبير ، ونحن نتحقق من صحته. بالنسبة للنوع X ، نعم ، هذا تعبير صحيح ؛ بالنسبة vector<int> ، لا. لتحقيق ما كنا نريد ، نحتاج إلى أخذ التعبير في الأقواس:

 template<typename Container> concept Sizable = requires(Container const & c) { {c.size()} -> size_t; }; static_assert(Sizable<vector<int>>); // OK struct X { struct Inner { int size_t; }; Inner* size() const; }; static_assert(Sizable<X>); // Fail 

ولكن هذا مجرد مثال ممتع. بشكل عام ، تحتاج فقط إلى توخي الحذر.

أمثلة على استخدام المفاهيم

تنفيذ فئة الزوج

علاوة على ذلك ، سأعرض بعض أجزاء STL التي يمكن تنفيذها في C ++ 17 ، ولكن مرهقة إلى حد ما.
ثم سنرى كيف يمكننا تحسين التطبيق في C ++ 20.

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

 template<typename F, typename S> struct pair { F f; S s; ... }; 

ولكن ، وفقًا cppreference ، يوجد لدى pair المصممين 8 قطع فقط.
وإذا نظرت إلى التطبيق الحقيقي ، على سبيل المثال ، في Microsoft STL ، سيكون هناك ما يصل إلى 15 pair للفئة pair . لن ننظر إلى كل هذه القوة ونقتصر على المُنشئ الافتراضي.

يبدو أنه شيء معقد؟ بادئ ذي بدء ، نحن نفهم سبب الحاجة إليها. نريد إذا كانت إحدى وسائط فئة pair من نوع تافه ، على سبيل المثال int ، ثم بعد تكوين فئة pair تم تهيئتها إلى الصفر ، ولم تظل غير مهيأة. للقيام بذلك ، نريد كتابة مُنشئ يستدعي تهيئة القيمة للحقول f (أولاً) و s (الثانية).

 template<typename F, typename S> struct pair { F f; S s; pair() : f() , s() {} }; 

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

 struct A { A(int); }; pair<int, A> a2; // must fail pair<int, A> a1; { 1, 2 }; // must be OK 

للقيام بذلك ، اجعل المُنشئ الافتراضي قالبًا وحصره في SFINAE.
الفكرة الأولى التي تتبادر إلى الذهن هي دعنا نكتب بحيث لا يُسمح بهذا المنشئ إلا إذا كانت f و s غير قابلة is_default_constructable :

 template<typename F, typename S> struct pair { F f; S s; template<typename = enable_if_t<conjunction_v< is_default_constructible<F>, // not dependent is_default_constructible<S> >>> pair() : f(), s() {} }; 

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

للتغلب على ذلك ، دعنا نضيف المزيد من معلمات القالب إلى هذا المُنشئ ونجعل الشرط enable_if_t يعتمد على معلمات القوالب هذه:

 template<typename F, typename S> struct pair { F f; S s; template<typename T = F, typename U = S, typename = enable_if_t<conjunction_v< is_default_constructible<T>, is_default_constructible<U> >>> pair() : f(), s() {} }; 

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

لقد حللنا مشكلتنا الأولى ، لكننا نواجه مشكلة ثانية أكثر دقة. افترض أن لدينا فئة B مع مُنشئ افتراضي صريح ، ونريد إنشاء pair<int, B> ضمنيًا:

 struct B { explicit B(); }; pair<int, B> p = {}; 

يمكننا القيام بذلك ، ولكن وفقًا للمعايير ، يجب ألا ينجح الأمر. وفقًا للمعايير ، يجب أن يكون الزوج افتراضيًا ضمنيًا ليتم إنشاؤه فقط إذا كان كلا من عنصريه مفترضين ضمنيًا ليتم تكوينهما.

سؤال: هل نحتاج إلى كتابة مُنشئ الزوج الصريح أم لا؟ في C ++ 17 ، لدينا حل سليمان: دعنا نكتب كذا وكذا.

 template<typename F, typename S> struct pair { F f; S s; template<typename T = F, typename U = S, typename = enable_if_t<conjunction_v< is_default_constructible<T>, is_default_constructible<U>, is_implicity_default_constructible<T>, is_implicity_default_constructible<U> >>> pair() : f(), s() {} template<...> explicit pair() : f(), s() {} }; 

الآن لدينا اثنين من الصانعين الافتراضية:

• سنقوم بقطع أحدها وفقًا لـ SFINAE للحالة عندما تكون العناصر قابلة للتضمين افتراضيًا ؛
• والثاني للحالة المعاكسة.

بالمناسبة ، لتطبيق نوع الكتابة is_implicitly_default_constructible في C ++ 17 ، أعرف هذا الحل ، لكنني لا أعرف الحل دون SFINAE:

 template<typrname T> true_type test(T, int); template<typrname T> false_type test(int, ...); template<typrname T> using is_implicity_default_constructible = decltype(test<T>({}, 0)); 

إذا حاولنا الآن إنشاء pair <int, B> ضمنيًا pair <int, B> على خطأ في الترجمة ، كما أردنا:

 template<..., typename = enable_if_t<conjuction_v< is_default_constructible<T>, is_default_constructible<U>, is_implicity_default_constructible<T>, is_implicity_default_constructible<U> >>> ... pair<int, B> p = {}; ... candidate template ignored: requirement 'conjunction_v< is_default_constructible<int>, is_default_constructible<B>, is_implicity_default_constructible<int>, is_implicity_default_constructible<B> >' was not satisfied [with T=int, U=B] 

في المجمعين المختلفين ، سيكون هذا الخطأ بدرجات متفاوتة من الشمولية. على سبيل المثال ، يقول برنامج التحويل البرمجي لـ Microsoft في هذه الحالة: "لم يكن من الممكن إنشاء زوج <int, B> من الأقواس المعقوفة الفارغة." ستضيف دول مجلس التعاون الخليجي وكلانج إلى هذا: "لقد جربنا مثل هذا المنشئ وكذا ، لم يأت أي منهما" ، وسيقولان سببًا لكل منهما.

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

تقول دول مجلس التعاون الخليجي: "فشل الاستبدال ، حاول العثور على نوع type داخل enable_if<false> - تعذر العثور عليه ، آسف."

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

في الوقت نفسه ، enable_if حياتنا بجعل الحالة المرهقة enable_if . نحن نرى أنها تحولت إلى false ، لكننا لا نرى لماذا بعد.

يمكن التغلب على هذا إذا قمنا بتقسيم enable_if إلى أربعة بهذه الطريقة:

 template<..., typename = enable_if_t<is_default_constructible<T>::value>>, typename = enable_if_t<is_default_constructible<U>::value>>, typename = enable_if_t<is_implicity_default_constructible<T>::value>>, typename = enable_if_t<is_implicity_default_constructible<U>::value>> > ... 

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

 pair<int, B> p = {}; // candidate template ignored: requirement 'is_implicity_default_constructible<B>::value' was not satisfied with... 

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

كيف سيساعدنا C ++ 20؟ أولاً ، تخلص من الأنماط بإعادة كتابة هذا يتطلب جملة. ما enable_if سابقًا داخل enable_if ، enable_if الآن داخل وسيطة جملة تتطلب:

 template<typename F, typename S> struct pair { F f; S s; pair() requires DefaultConstructible<F> && DefaultConstructible<S> && ImplicitlyDefaultConstructible<F> && ImplicitlyDefaultConstructible<S> : f(), s() {} explicit pair() ... }; 

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

 template<typename T> concept ImplicitlyDefaultConstructible = requires { [] (T) {} ({}); }; 

T ImplicitlyDefaultConstructible , , T . , , SFINAE.

C++20: (conditional) explicit ( noexcept ). explicit . , explicit .

 template<typename F, typename S> struct pair { F f; S s; explicit(!ImplicityDefaultConstructible<F> || !ImplicityDefaultConstructible<S>) pair() requires DefaultConstructible<F> && DefaultConstructible<S> : f(), s() {} }; 

, . , DefaultConstructible , explicit , explicit .

Optional C++17

Optional . , .

. ? , C++ :

 enum Option<T> { None, Some(t) } 

:

 class Optional<T> { final T value; Optional() {this.value = null; } Optional(T value) {this.value = value; } } 

C++: null , value-?

C++ . initialized storage , , . T , optional T , C++ memory model.

 template<typename T> class optional { bool initialized; aligned_storage_t<sizeof(T), alignof(T)> storage; ... 

, . : optional , optional . :

  ... T & get() & { return reinterpret_cast<T &>(storage); } T const & get() const & { return reinterpret_cast<T const &>(storage); } T && get() && { return move(get()); } optional() noexcept : initialized(false) {} optional(T const & value) noexcept(NothrowCopyConstructible<T>) : initialized(true) { new (&storage) T(value); } ~optional() : noexcept(NothrowDestructible<T>) { if (initialized) get().~T(); } }; 

optional ' . optional , optional , , optional . , copy move .

. : assignment . , . . copy constructor. :

 template<typename T> class optional { bool initialized; aligned_storage_t<sizeof(T), alignof(T)> storage; ... optional(optional const & other) noexcept(NothrowCopyConstructible<T>) : initialized(other.initialized) { if (initialized) new (&storage) T(other.get()); } optional& operator =(optional && other) noexcept(...) {...} }; 

move assignment. , :

• optional ' , .
• , .
• , — , , .

T : move constructor, move assignment :

 optional& operator =(optional && other) noexcept(...) { if (initialized) { if (other.initialized) { get() = move(other.get()); } else { initialized = false; other.initilized = true; new(&other.storage) T(move(get())); get().~T(); } } else if (other.initialized) { initialized = true; other.initialized = false; new(&storage) T(move(get())); other.get().~T(); } return *this; } 

noexcept :

 optional& operator =(optional && other) noexcept(NothrowAssignable<T> && NothrowMoveConstructible<T> && NothrowDestructible<T>) { if (initialized) { if (other.initialized) { get() = move(other.get()); } else { initialized = false; other.initialized = true; new (&other.storage) T(move(get())); get().~T(); } } ... } 

optional :

 template<typename T> class optional { ... optional(optional const &) noexcept(NothrowCopyConstructible<T>); optional(optional &&) noexcept(NothrowMoveConstructible<T>); optional& operator =(optional const &) noexcept(...); optional& operator =(optional &&) noexcept(...); }; 

, pair :
Optional -, (, deleted), compilation error.

 template class optional<unique_ptr<int>>; // compilation error 

, optional unique_ptr ,
copy constructor copy assignment deleted. , , SFINAE.
copy move assignment , — . - , copy , .

— . copy : deleted operation , , operation:

• deleted_copy_construct delete , — default ;
• copy_construct , copy_construct .

 template<class Base> struct deleted_copy_construct : Base { deleted_copy_construct(deleted_copy_construct const &) = delete; deleted_copy_construct(deleted_copy_construct &&) = default; deleted_copy_construct& operator =(deleted_copy_construct const &) = default; deleted_copy_construct& operator =(deleted_copy_construct &&) = default; }; template<class Base> struct copy_construct : Base { copy_construct(copy_construct const & other) noexcept(noexcept(Base::construct(other))) { Base::construct(other); } copy_construct(copy_construct &&) = default; copy_construct& operator =(copy_construct const &) = default; copy_construct& operator =(copy_construct &&) = default; }; 

select_copy_construct , , CopyConstrictuble , copy_construct , deleted_copy_construct :

 template<typename T, class Base> using select_copy_construct = conditional_t<CopyConstructible<T> copy_construct<Base> deleted_copy_construct<Base> >; 

, optional , optional_base , copy construct , optional
select_copy_construct<T, optional_base<T>> . copy :

 template<typename T> class optional_base { ... void construct(optional_base const & other) noexcept(NothrowCopyConstructible<T>) { if ((initialized = other.initialized)) new (&storage) t(other.get()); } }; template<typename T> class optional : select_copy_construct<T, optional_base<T>> { ... }; 

. , , copy_construct , move_construct copy_construct , copy_assign , , move_construct , , , :

 template<typename T, class Base> using select_move_construct = select_copy_construct<T, conditional_t<MoveConstructible<T>, move_construct<Base> > >; template<typename T, class Base> using select_copy_assign = select_move_construct<T, conditional_t<CopyAssignable<T> && CopyConstructible<T>, copy_assign<Base> delete_copy_assign<Base> > >; 

, move_assign copy_assign , optional_base , assignment construct assign , optional select_move_assign<T, optional_base<T>> .

 template<typename T, class Base> using select_move_assign = select_copy_assign<T, ...>; template<typename T> class optional_base { ... void construct(optional_base const&) noexcept(NothrowCopyConstructible<T>); void construct(optional_base &&) noexcept(NothrowMoveConstructible<T>); optional_base& assign(optional_base &&) noexcept(...); optional_base& assign(optional_base const &) noexcept(...); }; template<typename T> class optional : select_move_assign<T, optional_base<T>> { ... }; 

, :
optional<unique_ptr> deleted_copy_construct ,
move_construct . !

 optional<unique_ptr<int>> : deleted_copy_construct<...> : move_construct<...> : deleted_copy_assign<...> : move_assign<...> : optional_base<unique_ptr<int>> 

: optional TriviallyCopyable TriviallyCopyable .

TriviallyCopyable ? , T TriviallyCopyable ,
memcpy . , .

, , , . resize vector TriviallyCopyable , memcpy , , . , , .

TriviallyCopyable , , static_assert ', copy-move :

 template<typename T> class optional : select_move_assign<T, optional_base<T>> {...}; static_assert(TriviallyCopyable<optional<int>>); static_assert(TriviallyCopyConstructible<optional<int>>); static_assert(TriviallyMoveConstructible<optional<int>>); static_assert(TriviallyCopyAssignable <optional<int>>); static_assert(TriviallyMoveAssignable <optional<int>>); static_assert(TriviallyDestructible <optional<int>>); 

static_assert ' . , , . optional — aligned_storage , , , , TriviallyCopyable .

, . , TriviallyCopyable .

, . select_copy_construct :

 template<typename T, class Base> using select_copy_construct = conditional_t<CopyConstructible<T>, copy_construct<Base> deleted_copy_construct<Base> >; 

CopyContructible copy_construct , if compile-time: CopyContructible TriviallyCopyContructible , Base .

 template<typename T, class Base> using select_copy_construct = conditional_t<CopyConstructible<T>, conditional_t<TriviallyCopyConstructible<T>, Base, copy_construct<Base> >, deleted_copy_construct<Base> >; 

, copy . , select_destruct . int , - - , .

 template<typename T, class Base> using select_destruct = conditional_t<TriviallyDenstructible<T>, Base, destruct<Base> > >; 

, , . , , :

 optional<unique_ptr<int>> : deleted_copy_construct<...> : move_construct<...> : deleted_copy_assign<...> : move_assign<...> : destruct<optional_base<unique_ptr<int>>> : optional_base<unique_ptr<int>> 

, C++17 optional 7; : operation , deleted_operation select_operation ; construct assign . , .

- . . : deleted.

, noexcept .
, , , trivial , noexcept . , , trivial noexcept , noexcept , deleted . . , , .

type trait, , . , , copy : deleted , nothrow , ?

, - special member, , , , :

• , deleted , = delete deleted_copy_construct ;
• , copy_construct , c noexcept ;
• , , , .

.

optional C++20

C++20 optional copy ?
:

• T CopyConstructible , deleted ;
• TriviallyCopyConstructible , ;
• noexcept .

 template<typename T> class optional { ... optional(optional const &) requires(!CopyConstructible<T>) = delete; // #1 optional(optional const &) requires(TriviallyCopyConstructible<T>) = default; // #2 optional(optional const &) noexcept(NothrowCopyConstructible<T>) {...} // #3 ... ~optional() requires(TriviallyDestructible<T>) = default; ~optional() noexcept(NothroeDestructible<T>) {...} }; 

, . -, , T requires clause false . requires(false) , , overload resolution. , requires(true) , .
, .

requires clause = delete :

• = delete overload resolution, , , deleted .
• requires(false) overload resolution.

, copy , , requires clause. .

, . ! C++ , ? , , . , , , . , , , , , optional .

, , GCC internal compiler error, Clang . , . , .

, , optional C++20. , , C++17.

aligned_storage aligned_union

: aligned_storage reinterpret_cast , reinterpret_cast constexpr . , compile-time optional , compile-time. STL aligned_storage optional aligned_union variant . , , STL Boost optional variant . variant , :

 template<bool all_types_are_trivially_destructible, typename...> class _Variant_storage_; template<typename... _Types> using _Variant_storage = _Variant_storage_< conjunction_v<is_trivially_destructible<_Types>...>, _Types... >; template<typename _First, typename... _Rest> class _Variant_storage_<true, _First, _Rest...> { union { remove_const_t<First> _Head; _Variant_storage<_Rest...> _Tail; }; }; 

variant . _Variant_storage_ , , -, , variant , -, . , trivially_destructible ? type alias, . _Variant_storage_ , true false . , true , . trivially_destructible , union Variant ' .

, , , , . type alias _Variant_storage . :

 template<typename... _Types, bool = conjunction_v<is_trivially_destructible<_Types>...> > class _Variant_storage_; 

. , variadic template . , , , _Types . C++17 , .

C++20 ,
,
requires clause. C++20 requires clause:

 template<typename... _Types> class _Variant_storage_; template<typename _First, typename... _Rest> requires(TriviallyDestructible<_First> && ... && TriviallyDestuctible<_Rest>) class _Variant_storage_<_First, _Rest...> { union { remove_const_t<_First> _Head; _Variant_storage_<_Rest...> _Tail }; }; 

_Variant_storage_ , TriviallyDestructible . , requires clause , , .

requires clause template type alias

, requires clause template type alias. C++20 - enable_if , :

 template<bool condition, typename T = void> requires condition using enable_if_t = T; 

,

, . :

 // Equivalent, but functionally not equivalent template<typename T> enable_if_t<(sizeof(T) < 239)> f(); template<typename T> enable_if_t<(sizeof(T) > 239)> f(); // Not equivalent template<typename T> requires(sizeof(T) < 239) void f(); template<typename T> requires(sizeof(T) > 239) void f(); 

, enable_if . ? f() : enable_if , , 239, , , , 239. , :

• , , template type alias', «void f(); void f();
• , SFINAE, , , .

, enable_if , , size < 239 , size > 239 . , . , f() . requires clause. — , .

— , . C++ Russia 2019 Piter, «: core language» . , , : reachable entity visible, ADL, entities internal linkage . , C++ Russia (JetBrains) « ++20 — ?»