стандартная верстка c ++ 11 — с использованием того же контроля доступа
Я думал, что весь смысл POD (c ++ 11, тривиальный + стандартный макет) заключается в том, чтобы убедиться, что тип совместим с C.
Учитывая следующий код:
// that one is a standard layout, and trivial which makes it a c++11 POD
struct Bar
{
public:
int x;
public:
int y;
};
AFAIU, компилятор может изменить порядок х и у. Не нарушит ли это совместимость с C?
Почему это облегчение определения POD 98/03 в c ++ 11 считается хорошей идеей?
Решение
AFAIU, компилятор может изменить порядок х и у. Не нарушит ли это совместимость с C?
В C ++ 03 это возможно. В C ++ 11 это невозможно. Стандартные правила компоновки C ++ 11 только требуют, чтобы все участники имели одинаковый контроль доступа. Они не должны быть объявлены в одном и том же регионе контроля доступа.
Почему это облегчение определения POD 98/03 в c ++ 11 считается хорошей идеей?
Я думаю, что вы неправильно понимаете вещи. Правила C ++ 11 позволяют Больше типы должны быть стандартными (и, следовательно, потенциально совместимыми с типами Си), не менее. Таким образом, нет реального недостатка в расслаблении правил.
Другие решения
Я думал, что весь смысл POD (c ++ 11, тривиальный + стандартный макет) заключается в том, чтобы убедиться, что тип совместим с C.
Не совсем весь смысл, но да, это одно из свойств POD.
// that one is a standard layout, and trivial which makes it a c++11 POD
Правильный.
AFAIU, компилятор может изменить порядок х и у. Не нарушит ли это совместимость с C?
Мы уже установили, что это POD, что означает, что компилятор будет поддерживать совместимость с C. Сохранение совместимости с C не нарушает совместимость с C.
Почему это облегчение определения POD 98/03 в c ++ 11 считается хорошей идеей?
Потому что это ничего не сломает.
Смысл POD заключается не только в том, чтобы убедиться, что тип совместим с C — обратите внимание, что тип со спецификатором доступа (public, privateи т. д.) по определению не совместим с C, поскольку C не имеет спецификаторов доступа. Основное свойство типа POD заключается в том, что его можно использовать в memcpy.
Наличие более одного спецификатора доступа в типе C ++ позволяет компилятору не указывать тип неопределенным образом, и это было верно в течение некоторого времени (это не ново для C ++ 11):
Из С ++ 03 9.2 / 12
Нестатические члены данных (не объединяющего) класса, объявленного без
промежуточный спецификатор доступа распределяется так, чтобы более поздние члены имели
более высокие адреса в объекте класса. Порядок выделения
нестатические элементы данных, разделенные спецификатором доступа, не определены
(11.1).
Тем не менее, это не делает тип не POD — это все же может быть POD, но не тот, который переносимо выражается в C.