POD и наследование в С++ 11. Имеет ли адрес struct == адрес первого элемента?

Ответ 1

Вы не заботитесь о POD-ness, вы заботитесь о стандартном макете. Здесь определение из стандартного раздела 9 [class]:

Класс стандартного макета - это класс, который:

• не имеет нестатических членов данных типа нестандартного макета класса (или массива таких типов) или ссылки,
• не имеет виртуальных функций (10.3) и нет виртуальных базовых классов (10.1),
• имеет тот же контроль доступа (раздел 11) для всех нестатических членов данных,
• не имеет базовых классов нестандартной компоновки,
• либо не имеет нестатических членов данных в самом производном классе и не более одного базового класса с нестатическими членами данных, либо не имеет базовых классов с нестатическими членами данных, а
• не имеет базовых классов того же типа, что и первый нестатический элемент данных.

И свойство, которое вы хотите, затем гарантируется (раздел 9.2 [class.mem]):

Указатель на объект структуры стандартного макета, соответствующим образом преобразованный с помощью reinterpret_cast, указывает на его начальный член (или если этот элемент является битовым полем, а затем блоку, в котором он находится) и наоборот.

Это действительно лучше старого требования, поскольку возможность reinterpret_cast не теряется путем добавления нетривиальных конструкторов и/или деструктора.

Теперь перейдем к вашему второму вопросу. Ответ не в том, на что вы надеялись.

Base *b = new Derived;
delete b;

- это undefined поведение, если Base не имеет виртуального деструктора. См. Раздел 5.3.5 ([expr.delete])

В первом альтернативе (удалить объект), если статический тип подлежащего удалению объекта отличается от его динамического типа, статический тип должен быть базовым классом динамического типа объекта, подлежащего удалению, и статическим тип должен иметь виртуальный деструктор или поведение undefined.

Ваш предыдущий фрагмент с использованием malloc и free в основном верен. Это будет работать:

Base *b = new (malloc(sizeof(Derived))) Derived;
free(b);

поскольку значение указателя b совпадает с адресом, возвращаемым из нового места размещения, который, в свою очередь, является тем же адресом, который был возвращен из malloc.

Ответ 2

Предположительно, ваш последний бит кода предназначен для того, чтобы сказать:

Base *b = new Derived;
delete b;  // delete b, not d.

В этом случае короткий ответ заключается в том, что он остается undefined. Тот факт, что рассматриваемый класс или структура POD, стандартная компоновка или тривиально копируемая, ничего не меняет.

Да, вы передаете правильный адрес, и да, вы и я знаем, что в этом случае dtor в значительной степени ноль - тем не менее, указатель, который вы передаете на delete, имеет другой статический тип чем динамический тип, а у статического типа нет виртуального dtor. Стандарт совершенно ясен, что дает поведение undefined.

С практической точки зрения, вы, возможно, избегаете UB, если вы действительно настаиваете - вероятность того, что не будет никаких вредных побочных эффектов от того, что вы делаете, по крайней мере, с большинством типичных компиляторов. Остерегайтесь, однако, что даже в лучшем случае код чрезвычайно хрупок, поэтому казалось бы, тривиальные изменения могут сломать все - и даже перейти на компилятор с действительно тяжелой проверкой типов, и это тоже может сделать.

Что касается вашего аргумента, ситуация довольно проста: это в основном означает, что комитет, возможно, мог бы сделать это определенное поведение, если захочет. Однако, насколько мне известно, он никогда не предлагался, и даже если бы это было, это, вероятно, было бы очень низкоприоритетным пунктом - на самом деле это не очень много, разрешить новые стили программирования и т.д.

Ответ 3

Это подразумевается как дополнение к ответу Бен-Voigt, а не замена.

Вы можете подумать, что это всего лишь техничность. То, что стандарт, называющий его "undefined", - это всего лишь немного семантической twaddle, которая не имеет реальных эффектов, не позволяя авторам компилятора делать глупые вещи без уважительной причины. Но это не так.

Я мог видеть желательные реализации, в которых:

Base *b = new Derived;
delete b;

В результате поведение было довольно странным. Это связано с тем, что сохранение размера выделенного фрагмента памяти, когда оно известно статически компилятором, выглядит глупым. Например:

struct Base {
};

struct Derived {
   int an_int;
};

В этом случае, когда вызывается delete Base, у компилятора есть все основания (из-за правила, которое вы цитировали в начале вашего вопроса), полагая, что размер указанных данных равен 1, а не 4. Если он, например, реализует версию operator new, которая имеет отдельный массив, в котором все байтовые сущности все плотно упакованы, а другой массив, в котором 4 байтовых сущности все плотно упакованы, в конечном итоге предполагается, что Base * указывает на место в массиве сущностей 1 байта, когда на самом деле он указывает где-то в 4-байтовый массив сущностей и делает по этой причине всевозможные интересные ошибки.

Я действительно хотел, чтобы operator delete был определен так же, как и размер, и компилятор передал либо статически известный размер, если operator delete был вызван на объект с не виртуальным деструктором, либо известный размер фактический объект, на который указывает, если он был вызван в результате деструктора virtual. Хотя это, вероятно, будет иметь другие вредные последствия и, возможно, не такая хорошая идея (например, если есть случаи, в которых operator delete вызывается без вызова деструктора). Но это сделало бы проблему болезненно очевидной.

Ответ 4

Существует много дискуссий по нерелевантным вопросам выше. Да, в основном для совместимости с C существует ряд гарантий, на которые вы можете положиться, пока вы знаете, что делаете. Все это, однако, не имеет отношения к вашему основному вопросу. Главный вопрос: существует ли какая-либо ситуация, когда объект может быть удален с использованием типа указателя, который не соответствует динамическому типу объекта и где у указанного типа нет виртуального деструктора. Ответ: нет, нет.

Логика для этого может быть получена из того, что должна выполнять система времени выполнения: она получает указатель на объект и его просят удалить. Ему нужно будет хранить информацию о том, как вызвать деструкторы производного класса или объем памяти, который фактически занимает объект, если это необходимо определить. Однако это подразумевает, возможно, довольно значительную стоимость с точки зрения используемой памяти. Например, если первый член требует очень строгого выравнивания, например. для выравнивания на границе 8 байтов, как это имеет место для double, добавление размера добавило бы служебные данные не менее 8 байтов для распределения памяти. Хотя это может показаться не слишком плохим, это может означать, что только один объект вместо двух или четырех вписывается в строку кэша, что существенно снижает производительность.