Чем полезен is_standard_layout?

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

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

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

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

Источник

1 ответ

Общий ответ

Это способ проверки предположений. Вы не захотите писать код, который предполагает стандартную компоновку, если это не так.

C++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, по сути, является подмножеством стандартной компоновки.

У меня такое ощущение, что они добавили каждый возможный вариант оценки типа, независимо от какой-либо очевидной ценности, на тот случай, если кто-то может столкнуться с необходимостью за некоторое время до выхода следующего стандарта. Я сомневаюсь, что нагромождение этих "лишних" свойств типов добавляет значительную дополнительную нагрузку разработчикам компиляторов.

Здесь хорошо обсуждается стандартная раскладка: почему определение "стандартной компоновки" POD в C++11 таково, как оно есть? На cppreference.com также есть много хороших деталей: нестатические члены данных

Источник
Другие вопросы по тегам