Sovrascrittura di una funzione virtuale [[Noreturn]]

Question

L'attributo [[noreturn]] può essere applicato a funzioni che non sono destinate a restituire. Per esempio:

[[noreturn]] void will_throw() { throw std::runtime_error("bad, bad, bad ...."); } 

Ma ho incontrato la seguente situazione (no, non ho progettare questo):

class B { 
public: 
    virtual void f() { throw std::runtime_error(""); } 
}; 

class D : public B { 
    void f() override { std::cout << "Hi" << std::endl; } 
}; 

mi piacerebbe davvero per posizionare l'attributo [[noreturn]] nella dichiarazione B::f(). Ma non sono chiaro su cosa succede all'override nella classe derivata. Il ritorno con successo da una funzione [[noreturn]] ha come risultato un comportamento indefinito, e certamente non voglio che se una sovrascrittura erediti anche l'attributo.

La domanda: Con l'override [[noreturn] virtual void B::f(), faccio io eredito l'attributo [[noreturn]]?

Ho esaminato lo standard C++ 14 e ho difficoltà a determinare se gli attributi sono ereditati.

Answer 1

In pratica, né g++, clang né MSVC considerano l'attributo [[noreturn]] come ereditato

#include <iostream> 

struct B { 
public: 
    [[noreturn]] virtual void f() { std::cout << "B\n"; throw 0; } 
}; 

struct D : public B { 
    void f() override { std::cout << "D\n"; } 
}; 

int main() 
{ 
    try { B{}.f(); } catch(...) {} 
    D{}.f(); 

    B* d = new D{}; 
    d->f(); 
} 

che stampa "B", "D" e "D" per tutti e tre i compilatori.

Answer 2

Ho attraversato lo standard e non c'è alcuna indicazione che sia lo [[noreturn]] nello specifico, sia gli attributi più in generale, siano "ereditati" dalle funzioni di override.

E 'difficile fornire una prova negativa, e lo standard di fatto non dichiara questo in entrambi i casi, ma, dal momento che A::f() e B::f() sono ancora funzioni distinte e l'unico comportamento descritto è definito in termini di funzioni, penso che tu sia al sicuro per contrassegnare A::f() come [[noreturn]].

Detto questo, non posso immaginare quale utile ottimizzazione il compilatore potrebbe successivamente eseguire, data la spedizione dinamica.

Answer 3

considerare ciò che in realtà si sta dicendo:

class B 
{ 
public: 
    [[noreturn]] virtual void f() { throw std::runtime_error(""); } 
}; 

Certamente il lettore umano, e, eventualmente, il compilatore, potrebbe interpretare questo come un 'contratto', vale a dire
"f() ritorno solito, te lo prometto"

Questo dovrebbe quindi essere applicato anche alle sostituzioni di f() oppure si sta violando il contratto.

Lo standard potrebbe essere sottodescritto su questo, ma anche se funziona, lo raccomanderei in base alla leggibilità.