Чому std :: is_pod застарілий у C ++ 20?

std::is_podймовірно буде застарілою в C ++ 20.
У чому причина такого вибору? Що я повинен використовувати замість того, std::is_podщоб знати, чи тип насправді є POD?

c++ typetraits

— skypjack
джерело

Див. Також open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0767r1.html та US 101 у open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf

— Баум mit Augen

Чому ви хочете знати, чи є тип POD?

— Марк Глісс,

@MarcGlisse Питання про зміни стандарту або подібну рису не обов'язково означає, що я хочу використовувати цю функцію. Я знайшов застарілу записку під час гуглиння, і мені було просто цікаво дізнатися, чому вона була застарілою.

— skypjack

Моє запитання насправді було непрямою відповіддю: його було видалено, оскільки (приблизно) немає підстав запитувати, чи є тип POD.

— Марк Глісс,

Я б використав його для того, static_assertщоб переконатися, що ніхто не торкається конструкцій, якими слід ділитися з кодом C.

— Мірко

POD замінюється двома категоріями, які надають більше нюансів. C ++ стандарту зустрічі в листопаді 2017 року було це , щоб сказати про це:

Зниження поняття "простих старих даних" (POD). Його замінили ще двома нюансованими категоріями типів, «тривіальним» та «стандартним макетом». “POD” еквівалентно “тривіальній та стандартній компоновці”, але для багатьох шаблонів коду доцільне вужче обмеження лише на “тривіальну” або просто “стандартну компоновку”; щоб заохотити таку точність, поняття "POD" було відмовлено. Бібліотечна ознака is_pod також була припинена відповідно.

Для простих типів даних використовуйте is_standard_layoutфункцію, для тривіальних типів даних (наприклад, простих структур) використовуйте is_trivialфункцію.

— DJ Klomp
джерело

Отже, вони додають remove_cvrefз одного боку, що є складеною рисою, тоді як з іншого боку вони видаляють інші складені риси? Це здається божевільним. :-)

— skypjack

Це здається тривіальним І стандартним макетом І реченням, що включає рекурсивне POD. Чи зайве рекурсивне речення? Тобто, чи гарантовано це std::is_pod<T>{} == (std::is_trivial<T>{} && std::is_standard_layout<T>{})?

— Якк - Адам Неврамонт,

@skypjack: Суть видалення POD полягає в тому, що він більше не служить цілі. Склад "тривіального" та "стандартного макета" насправді нічого не означає в C ++, і немає жодної причини, чому ви обмежували інтерфейс POD, а не "тривіальний" або "стандартний макет", виходячи з того, що ви насправді робите з цим. Навпаки, вилучення "cvref" щось означає; результуючий тип - це тип об’єкта без будь-яких кваліфікаторів.

— Nicol Bolas

Я по-справжньому ціную цю зміну. Як програміст системного програмного забезпечення, «стандартний макет» насправді був тим, про що я постійно дбав, і вимога щодо POD, що не мають конструкторів, змусила їх не належним чином описувати мою загальну ідіому «конструкції з конструкторами». Раніше я був змушений називати ці "псевдо-POD". Мило, але це робить певних шанувальників аніме смішними на вас, коли ви говорите про наявність псевдоподів у своєму коді.

— ТЕД

Є std::is_pod, std::is_triviaі час std::is_standard_layoutкомпіляції? Оскільки в алгоритмах, можливо, ви хочете швидшого алгоритму, використовуючи memcpy () тощо, якщо C-макет сумісний.

— SJHowe