Странное перечисление в деструкторе

Question 1

В настоящее время я читаю исходный код Protocol Bufferи обнаружил один странный enumкод, определенный здесь

  ~scoped_ptr() {
    enum { type_must_be_complete = sizeof(C) };
    delete ptr_;
  }

  void reset(C* p = NULL) {
    if (p != ptr_) {
      enum { type_must_be_complete = sizeof(C) };
      delete ptr_;
      ptr_ = p;
    }
  }

Почему enum { type_must_be_complete = sizeof(C) };определяется здесь? для чего это используется?

Question 2

Этот трюк позволяет избежать UB, гарантируя, что определение C доступно при компиляции этого деструктора. В противном случае компиляция не удалась бы, поскольку sizeofнеполный тип (объявленные вперед типы) нельзя определить, но можно использовать указатели.

В скомпилированном двоичном коде этот код будет оптимизирован и не будет иметь никакого эффекта.

Обратите внимание, что: Удаление неполного типа может быть неопределенным поведением из 5.3.5 / 5 :.

если удаляемый объект имеет неполный тип класса на момент удаления, а полный класс имеет нетривиальный деструктор или функцию освобождения, поведение не определено .

g++ даже выдает следующее предупреждение:

предупреждение: возможная проблема обнаружена при вызове оператора удаления:
предупреждение: 'p' имеет неполный тип
предупреждение: прямое объявление 'struct C'

Question 3

sizeof(C)завершится ошибкой во время компиляции, если Cэто не полный тип. Установка локальной области видимости enumделает оператор безопасным во время выполнения.

Это способ программиста защитить себя от самих себя: поведение последующего delete ptr_на неполном типе не определено, если у него есть нетривиальный деструктор.

Question 4

Чтобы понять это enum, начните с рассмотрения деструктора без него:

~scoped_ptr() {
    delete ptr_;
}

где ptr_а C*. Если тип Cна этом этапе является неполным, то есть все, что известно компилятору struct C;, то ⁽¹⁾ для указанного экземпляра C используется деструктор, созданный по умолчанию . Вряд ли это будет правильным решением для объекта, управляемого интеллектуальным указателем.

Если удаление с помощью указателя на неполный тип всегда имело неопределенное поведение, тогда стандарт мог бы просто потребовать, чтобы компилятор диагностировал его и завершился ошибкой. Но это четко определено, когда реальный деструктор тривиален: знания, которые может иметь программист, но нет у компилятора. Я не понимаю, почему язык определяет и допускает это, но C ++ поддерживает многие практики, которые сегодня не считаются лучшими.

Полный тип имеет известный размер и, следовательно, sizeof(C)будет компилироваться тогда и только тогда, когда Cэто полный тип - с известным деструктором. Так что его можно использовать как охранник. Один путь был бы просто

(void) sizeof(C);  // Type must be complete

Я предполагаю, что с некоторым компилятором и параметрами компилятор оптимизирует его, прежде чем он сможет заметить, что он не должен компилироваться, и что enumэто способ избежать такого несоответствующего поведения компилятора:

enum { type_must_be_complete = sizeof(C) };

Альтернативное объяснение выбора, enumа не просто отброшенное выражение, - это просто личные предпочтения.

Или, как предлагает Джеймс Т. Хаггет в комментарии к этому ответу, «перечисление может быть способом создания псевдопереносимого сообщения об ошибке во время компиляции».

^{⁽¹⁾ Сгенерированный по умолчанию деструктор бездействия для неполного типа был проблемой со старым std::auto_ptr. Он был настолько коварен, что попал в статью GOTW об идиоме PIMPL , написанную председателем международного комитета по стандартизации C ++ Хербом Саттером. Конечно, в настоящее время это std::auto_ptrне рекомендуется, вместо этого можно использовать какой-то другой механизм.}

Question 5

Может быть, уловка Cопределена.