Dziwne wyliczenie w destruktorze

Obecnie czytam kod źródłowy Protocol Bufferi znalazłem jeden dziwne enumkody zdefiniowane tutaj

  ~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;
    }
  }

Dlaczego enum { type_must_be_complete = sizeof(C) };tutaj zdefiniowano? do czego jest to używane?

Ta sztuczka pozwala uniknąć UB, zapewniając, że definicja C jest dostępna podczas kompilacji tego destruktora. W przeciwnym razie kompilacja zakończy się niepowodzeniem, ponieważ sizeofnie można określić niekompletnego typu (zadeklarowane typy do przodu), ale można użyć wskaźników.

W skompilowanym pliku binarnym ten kod zostałby zoptymalizowany i nie miałby żadnego efektu.

Zauważ, że: Usunięcie niekompletnego typu może być niezdefiniowanym zachowaniem z 5.3.5 / 5 :.

jeśli usuwany obiekt ma niekompletny typ klasy w momencie usunięcia, a cała klasa ma nietrywialny destruktor lub funkcję cofnięcia alokacji, zachowanie jest niezdefiniowane .

g++ wydaje nawet następujące ostrzeżenie:

ostrzeżenie: możliwy problem wykryty w wywołaniu operatora usuwania:
ostrzeżenie : `` p '' ma niekompletny typ
ostrzeżenie: deklaracja przekazania `` struct C ''

sizeof(C)zakończy się niepowodzeniem w czasie kompilacji, jeśli Cnie jest kompletnym typem. Ustawienie zakresu lokalnego enumna to sprawia, że ​​instrukcja jest niegroźna w czasie wykonywania.

Jest to sposób programisty chroniącego się przed samym sobą: zachowanie kolejnego delete ptr_na niekompletnym typie jest niezdefiniowane, jeśli ma nietrywialny destruktor.

Aby zrozumieć enum, zacznij od rozważenia destruktora bez niego:

~scoped_ptr() {
    delete ptr_;
}

gdzie ptr_jest C*. Jeśli typ Cjest niekompletna w tym momencie, to znaczy, że wszystko jest kompilator wie struct C;, to ⁽¹⁾ domyślne generowane zrobić-nic destructor służy do instancji wskazał C. Jest mało prawdopodobne, aby to była właściwa czynność w przypadku obiektu zarządzanego przez inteligentny wskaźnik.

Jeśli usuwanie przez wskaźnik do niekompletnego typu zawsze miało niezdefiniowane zachowanie, to standard może po prostu wymagać, aby kompilator zdiagnozował to i zakończył się niepowodzeniem. Ale jest dobrze zdefiniowane, gdy prawdziwy destruktor jest trywialny: wiedza, którą programista może mieć, ale kompilator nie ma. Dlaczego język definiuje i na to pozwala, jest poza mną, ale C ++ obsługuje wiele praktyk, które dziś nie są uważane za najlepsze praktyki.

Typ kompletny ma znany rozmiar i dlatego sizeof(C)będzie kompilowany wtedy i tylko wtedy, gdy Cjest typem pełnym - ze znanym destruktorem. Więc może być używany jako strażnik. Jeden sposób byłby prosty

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

Ja przypuszczam , że z jakiegoś kompilatora oraz opcje kompilator optymalizuje ją zanim zdążyła zauważyć, że nie należy skompilować i że enumjest sposób, aby uniknąć takiego niezgodnych zachowanie kompilatora:

enum { type_must_be_complete = sizeof(C) };

Alternatywnym wyjaśnieniem wyboru, enuma nie tylko odrzuconego wyrażenia, są po prostu osobiste preferencje.

Lub, jak sugeruje James T. Hugget w komentarzu do tej odpowiedzi: „Wyliczenie może być sposobem na utworzenie pseudo-przenośnego komunikatu o błędzie w czasie kompilacji”.

^{(1) Domyślnie generowany destruktor nic nie rób dla niekompletnego typu był problemem ze starym std::auto_ptr. Było tak podstępne, że trafiło do artykułu GOTW na temat idiomu PIMPL , napisanego przez przewodniczącego międzynarodowej komisji normalizacyjnej C ++, Herba Suttera. Oczywiście w dzisiejszych czasach to std::auto_ptrjest przestarzałe, zamiast tego użyjemy innego mechanizmu.}

Może sztuczka, aby mieć pewność, Czostała zdefiniowana.