Ответ 1
Общий ответ
Это способ проверки допущений. Вы не хотели бы писать код, который предполагает стандартный макет, если это не так.
С++ 11 предоставляет множество утилит вроде этого. Они особенно ценны для написания родового кода (шаблонов), где в противном случае вы должны доверять клиентскому коду, чтобы не допускать ошибок.
Примечания, относящиеся к is_standard_layout
Мне кажется, что определение (псевдокод) is_pod
будет примерно...
// note: applied recursively to all members
bool is_pod(T) { return is_standard_layout(T) && is_trivial(T); }
Итак, вам нужно знать is_standard_layout
, чтобы реализовать is_pod
. Учитывая это, мы могли бы также показать is_standard_layout
как инструмент, доступный разработчикам библиотеки. Также обратите внимание: если у вас есть прецедент для is_pod
, вы можете подумать о возможности того, что is_standard_layout
может быть лучшим (более точным) выбором в этом случае, поскольку POD по существу является подмножеством стандартного макета.
У меня возникает ощущение, что они добавили каждый мыслимый вариант оценки типа, независимо от какого-либо очевидного значения, на случай, если кто-то столкнется с необходимостью когда-нибудь, прежде чем выйдет следующий стандарт. Я сомневаюсь, что наложение на эти свойства "дополнительного" типа добавляет дополнительную дополнительную нагрузку разработчикам компилятора.
Здесь есть приятное обсуждение стандартного макета: Почему С++ 11 POD "стандартная компоновка" определение, как оно выглядит? На cppreference.com также есть много хороших деталей: Нестатические элементы данных