Почему std :: is_pod устарел в C ++ 20?

std::is_podвероятно, будет устаревшим в C ++ 20.
В чем причина такого выбора? Что мне следует использовать вместо того, std::is_podчтобы знать, действительно ли тип является POD?

c++ typetraits

— скайпджек
источник

См. Также 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?

— Marc Glisse

@MarcGlisse Вопрос об изменениях в стандарте или подобной особенности не обязательно означает, что я хочу использовать эту функцию. Я нашел устаревшую заметку во время поиска в Google, и мне просто было любопытно узнать, почему она устарела.

— skypjack

На самом деле мой вопрос был косвенным ответом: он был удален, потому что (примерно) нет причин спрашивать, является ли тип POD.

— Marc Glisse

Я бы использовал его для 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>{})?

— Yakk - Adam Nevraumont

@skypjack: Смысл удаления POD в том, что он больше не служит цели. Комбинация «тривиального» и «стандартного макета» на самом деле ничего не означает в C ++, и нет причин, по которым вы ограничиваете интерфейс только POD, а не «тривиальным» или «стандартным макетом» в зависимости от того, что вы действительно делаете с этим. Напротив, удаление "cvref" что-то означает; результирующий тип является типом объекта без квалификаторов.

— Никол Болас

Я лично очень ценю это изменение. Как системный программист, я действительно все время интересовался «стандартной компоновкой», и требование, чтобы POD не имели конструкторов, не позволяло им должным образом описывать мою общую идиому «структуры с конструкторами». Раньше я был вынужден называть их «псевдо-POD». Симпатично, но это заставляет некоторых фанатов аниме смотреть на вас забавно, когда вы говорите о псевдоподах в вашем коде.

— TED

Есть std::is_pod, std::is_triviaи std::is_standard_layoutвремя компиляции? Потому что в алгоритмах вы можете пожелать более быстрый алгоритм с использованием memcpy () и т.д., если совместим с C-layout.

— SJHowe