2016-06-09 7 views
8

Ho il seguente codice:Conflitto nel tipo di ritorno dalla classe base con classe derivata utilizzando auto

struct A{}; 

struct Base { 
    virtual A& internal() = 0; 
}; 

struct Derives : public Base {  
    auto& internal() override { // <-- conflicting return type 
     return internal_; 
    } 

private: 
    A internal_; 
}; 

int main() { 
    Derives d; 
    auto& internal = d.internal(); 
} 

Questo non riesce a compilare (testato su coliru - con gcc) con un tipo di ritorno in conflitto - la mia domanda è perché il compilatore non può dedurre che sia internal_ (e quindi il tipo di reso) sia A? Il tipo dedotto per auto in una diversa fase di compilazione, ad esempio, di quella che controlla le sostituzioni virtuali? Naturalmente questo si compila se si sostituisce auto con il tipo corretto - ma questo è oltre il punto.

(Qui è l'errore clang, gcc è in qualche modo simile)

main.cpp:8:11: error: return type of virtual function 'internal' is not covariant with the return type of the function it overrides ('auto &' is not derived from 'A &')

auto& internal() override { // <-- conflicting return type 
~~~~~^

main.cpp:4:16: note: overridden virtual function is here

virtual A& internal() = 0; 
     ~~^

1 error generated.

+1

Domandandosi perchè stai mescolando il polimorfismo runtime (funzione virtuale) con classe di tempo compilatore classe di progettazione (modelli)? – Ajay

+0

@BeyelerStudios, ho guardato quella domanda, ma non credo che sia (anche se potrei sbagliarmi ..) – Nim

+2

In Visual Studio ottengo: "errore C3542:' Derives :: internal': una funzione membro virtuale deve non ho un tipo di ritorno che contenga 'auto'" –

risposta

14

Da [dcl.spec.auto]:

A function declared with a return type that uses a placeholder type shall not be virtual ([class.virtual]).

internal() è una funzione virtuale, quindi non è possibile utilizzare auto.

Il original proposal indica il ragionamento per questo:

It would be possible to allow return type deduction for virtual functions, but that would complicate both override checking and vtable layout, so it seems preferable to prohibit this.

Problemi correlati