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

92

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
3
Почему вы хотите знать, является ли тип POD?
Marc Glisse
8
@MarcGlisse Вопрос об изменениях в стандарте или подобной особенности не обязательно означает, что я хочу использовать эту функцию. Я нашел устаревшую заметку во время поиска в Google, и мне просто было любопытно узнать, почему она устарела.
skypjack
На самом деле мой вопрос был косвенным ответом: он был удален, потому что (примерно) нет причин спрашивать, является ли тип POD.
Marc Glisse
3
Я бы использовал его для static_assertтого, чтобы никто не трогал структуры, которые должны использоваться совместно с кодом C.
Мирко

Ответы:

70

POD заменяется двумя категориями, которые дают больше нюансов. На стандартном собрании C ++ в ноябре 2017 года об этом говорилось следующее:

Отказ от понятия «старые простые данные» (POD). Он был заменен на две более тонкие категории типов: «тривиальный» и «стандартный макет». «POD» эквивалентен «тривиальному и стандартному макету», но для многих шаблонов кода уместно более узкое ограничение до «тривиального» или просто «стандартного макета»; Поэтому для поощрения такой точности понятие «POD» было объявлено устаревшим. Библиотечный трейт is_pod также устарел.

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

DJ Klomp
источник
4
Итак, они добавляют remove_cvrefс одной стороны, что это составная черта, а с другой стороны они удаляют другие составные черты? Это кажется безумным. :-)
skypjack
6
Это кажется тривиальным И стандартным макетом И предложением, включающим рекурсивный POD. Является ли рекурсивное предложение избыточным? Т.е. это гарантировано std::is_pod<T>{} == (std::is_trivial<T>{} && std::is_standard_layout<T>{})?
Yakk - Adam Nevraumont
3
@skypjack: Смысл удаления POD в том, что он больше не служит цели. Комбинация «тривиального» и «стандартного макета» на самом деле ничего не означает в C ++, и нет причин, по которым вы ограничиваете интерфейс только POD, а не «тривиальным» или «стандартным макетом» в зависимости от того, что вы действительно делаете с этим. Напротив, удаление "cvref" что-то означает; результирующий тип является типом объекта без квалификаторов.
Никол Болас
5
Я лично очень ценю это изменение. Как системный программист, я действительно все время интересовался «стандартной компоновкой», и требование, чтобы POD не имели конструкторов, не позволяло им должным образом описывать мою общую идиому «структуры с конструкторами». Раньше я был вынужден называть их «псевдо-POD». Симпатично, но это заставляет некоторых фанатов аниме смотреть на вас забавно, когда вы говорите о псевдоподах в вашем коде.
TED
2
Есть std::is_pod, std::is_triviaи std::is_standard_layoutвремя компиляции? Потому что в алгоритмах вы можете пожелать более быстрый алгоритм с использованием memcpy () и т.д., если совместим с C-layout.
SJHowe