Подтвердить что ты не робот

Как is_standard_layout полезно?

Из того, что я понимаю, стандартный макет позволяет три вещи:

  • Пустая оптимизация базового класса
  • Обратная совместимость с C с некоторыми указателями на указатели
  • Использование offsetof

Теперь в библиотеку входит метатекс предикатов is_standard_layout, но я не вижу в нем много пользы в общем коде, поскольку те функции C, которые я перечислял выше, кажутся крайне редкими, требуют проверки общего кода. Единственное, о чем я могу думать, это использовать его внутри static_assert, но это только для того, чтобы сделать код более надежным и не требуется.

Как is_standard_layout полезно? Есть ли какие-либо вещи, которые были бы невозможны без него, что потребовало бы его в стандартной библиотеке?

4b9b3361

Ответ 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 также есть много хороших деталей: Нестатические элементы данных