Pourquoi le compilateur n'est-il pas plus intelligent dans ce problème de surcharge de fonction const?

Question

Le code suivant ne compile pas:

#include <iostream> 
class Foo { 
    std::string s; 
public: 
    const std::string& GetString() const { return s; } 
    std::string* GetString() { return &s; } 
}; 

int main(int argc, char** argv){ 
    Foo foo; 
    const std::string& s = foo.GetString(); // error 
    return 0; 
} 

J'obtiens l'erreur suivante:

const1.cc:11: error: 
invalid initialization of reference of type 'const std::string&' 
from expression of type 'std::string* 

Il ne fait un certain sens, car foo est pas de type const Foo, mais juste Foo, de sorte que le compilateur veut utiliser la fonction non-const. Mais encore, pourquoi ne peut-il pas reconnaître que je veux appeler la fonction const GetString, en regardant la (type de) variable à laquelle je l'assigne? J'ai trouvé ce genre de surprenant.

Answer 1

Je ne me souviens pas exactement pourquoi ils ne permettent pas de surcharger le type de retour (je pense qu'il est parce que les valeurs de retour peuvent être mis au rebut et donc la fonction ne serait pas distincte), mais vous pouvez résoudre le problème avec un soupçon const_cast au compilateur: const std::string& s = const_cast<const Foo&>(foo).GetString();

Answer 2

Le type de retour est déterminée à partir de la fonction surchargée qui est en fait appelée, elle constitue jamais une partie de la résolution de surcharge elle-même. (Et si le type de retour n'a pas été utilisé?)

const est pas le problème avec la valeur de retour que vous pouvez lier un objet non const à une référence const, il est le fait que votre fonction retourne un pointeur que vous ne déréférenciez pas.

Comme foo n'est pas const, la non constGetString() est appelé - il est une meilleure correspondance pour un objet non const. Vous avez besoin:

const std::string& s = *foo.GetString(); 

Answer 3

Adresser MarkB's answer avec une petite illustration d'un scénario potentiellement pire que le rejet de la valeur de retour:

#include <cmath> 
#include <complex> 

struct Foo { 
    int x; 
    double y; 
    std::complex<char> z; 
    // etc, etc 
}; 

int evaluate(Foo f) { return f.x; } 
double evaluate(Foo f) { return f.y; } 
std::complex<char>(Foo f) { return f.z; } 
//etc, etc 

template <typename T> class Thingamajig 
{ 
public: 
    enum { value = sizeof (T); }; 
}; 

template <> 
class Thingamajig<double> class Thingamajig 
{ 
public: 
    int value(int a) { return a/3; } 
}; 

template <typename T> Thingamajig<T> thingamatize(const T& t) 
{ 
    return Thingajamig<T>(); 
} 

Foo myfoo = { 1, 2, 3 }; 
size_t result = sizeof(thingamatize(std::abs(4 - evaluate(myfoo))).value('B')); 

Il est un proc très long pour déterminer que double evaluate(Foo f) doit être choisi.

Lire aussi: http://blogs.msdn.com/ericlippert/archive/2006/03/31/delegates-lambdas-type-inference-and-long-playing-records.aspx

« ? Combien de travail que vous voulez créer pour votre compilateur aujourd'hui ™ »

Answer 4

Le type de retour d'une fonction n'est pas utilisé lors de la sélection de la surcharge. C'est juste comment la langue fonctionne.

Cependant, les conversions implicites sont sélectionnées en fonction du contexte. Donc, techniquement vous pouvez le faire compiler en retournant quelque chose qui est implicitement convertible à la fois à une référence et à un pointeur. Mais la vraie réponse est que les fonctions surchargées sur constness devraient avoir un type de retour similaire. (Je suppose que c'est là que la convention «utilise des pointeurs pour des choses mutables, des références const pour des choses immuables» tombe en panne.)