Jaka jest specyfikacja wyjątku dla domyślnego wirtualnego destruktora w C++ 11?

Question

Załóżmy, że mam:

class Foo 
{ 
public: 
    virtual ~Foo()=default; 
}; 

Co jest wyjątkiem specyfikacją na niewykonaniem destructor? Czy defaulted destructor równoważne:

virtual ~Foo() {}; 
or 
    virtual ~Foo() throw() {}; 
or 
    virtual ~Foo() noexcept {}; 

rozdziale 15.4 standardu C++ 11 mówi, że to zależy od specyfikacji wyjątkiem funkcji bezpośrednio powoływane przez niejawny definicji destruktor jest. W tym przypadku nie ma żadnych członków i klas podstawowych, więc AFAIK nie ma żadnych funkcji bezpośrednio wywoływanych przez niejawny destruktor. Czy jest to niejednoznaczność (lub pominięcie) w standardzie?

Ma to znaczenie, ponieważ jeśli niejawnie ma throw(), wówczas wszystkie podklasy muszą zadeklarować swoje destruktory za pomocą throw(). Nie mów mi, że to zły pomysł na wyrzucanie wyjątków w destruktorach, wiem o tym. Mam do czynienia z dużą ilością starszego kodu, w którym specyfikacje wyjątków nie były w ogóle używane.

Jako punkt informacji, kiedy próbowałem:

class SubFoo : public Foo 
{ 
public: 
    virtual ~SubFoo(); 
}; 

mam błąd (niedopasowane specyfikację wyjątku) w GCC 4.4 (chociaż muszę przyznać, że nie może mieć przełączniki linii poleceń po prawej), ale nie w XCode 4.3 przy użyciu kompilatorów "11".

Answer 1

Powrót do wcześniej w tym samym zdaniu (§15.4/14):

... jej niejawny wyjątek-specyfikacja określa typ-id T wtedy i tylko wtedy, gdy T jest dozwolone przez exception- określenie funkcji bezpośrednio powoływane przez niejawny definicji f jest; ...”

Dlatego jeśli ~Foo nie wywoływać żadnych funkcji, ma niejawny deklarację, która pozwala bez wyjątków być rzucony

według. do §15.4/3:

Dwa wyjątku specyfikacji są zgodne, jeżeli:

• oba są non-rzucanie (patrz poniżej), niezależnie od ich formy,

To w tym przypadku, więc nie ma znaczenia, czy deklaracja jest throw() czy noexcept - oba są kompatybilne w każdym przypadku.

Answer 2

standardese zaczyna ładnie w C++ 11 §8.4.2/2,

Jeśli funkcja jest wyraźnie wywiąże się ze swoim pierwszym oświadczeniu
- jest domyślnie uznawane za constexpr jeśli domyślna deklaracja będzie,
- domyślnie uważa się, że ma taką samą specyfikację wyjątków, jak gdyby została domyślnie zadeklarowana (15.4), & hellip;

Ale potem, w C++ 11 §15.4/14 logika szybko nakładanych,

niejawnie uznane specjalną funkcję użytkownika (punkt 12) powinny mieć wyjątku specyfikacją. Jeśli f jest domyślnie deklarowanym konstruktorem domyślnym, konstruktorem kopiowania, konstruktorem ruchu, destruktorem, operatorem przypisania kopiowania lub operatorem przypisania, jego specyfikacja wyjątku wyjątkowego określa identyfikator typu T, jeśli jest dozwolona tylko przez specyfikację wyjątku. funkcji bezpośrednio wywoływanej przez domyślną definicję f; f zezwala na wszystkie wyjątki, jeśli jakakolwiek funkcja, którą wywołuje bezpośrednio, dopuszcza wszystkie wyjątki, a f nie dopuszcza żadnych wyjątków, jeśli każda funkcja, do której się bezpośrednio wywołuje, nie dopuszcza żadnych wyjątków.

W rozumieniu standardu "dopuszczaj" chodzi o jawne dopuszczenie, poprzez specyfikację wyjątku.

Jeśli f wywołuje dwie funkcje, z których jeden precyzuje i dlatego pozwala T, a jeden, który pozwala wszystkie wyjątki, a następnie f musi określić zarówno Ti pozwolić wszystkie wyjątki, które ISN ’ t możliwe.

To zdecydowanie wygląda na wadę standardu.

Znalazłem powiązany raport o defekcie, http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1351.

Wygląda jednak na to, że ten obszar jest po prostu wielkim bałaganem. :-(