C++ applique-t-il des instructions de retour?

Question

D'accord, petite curiosité que j'ai découverte avec mon compilateur C++.

J'avais un peu peu de code complexe à refactoriser, et j'ai accidentellement réussi à laisser dans un chemin qui n'avait pas une déclaration de retour. Ma faute. D'un autre côté, cela compilé, et segfaulted quand je l'ai couru et ce chemin a été frappé, évidemment.

Voici ma question: est-ce un bogue de compilateur, ou est-ce qu'il n'y a aucune garantie qu'un compilateur C++ imposera le besoin d'une déclaration de retour dans une fonction de retour non-vide?

Oh, et pour être clair, dans ce cas, c'était une instruction if inutile sans accompagnement. Pas de gotos, pas de sorties, pas d'abandons.

Answer 1

Personnellement, je pense que cela devrait être une erreur:

int f() { 
} 

int main() { 
    int n = f(); 
    return 0; 
} 

, mais la plupart des compilateurs traitent comme un avertissement, et vous pouvez même avoir à utiliser des commutateurs de compilateur pour obtenir cet avertissement.Par exemple, sur g ++ dont vous avez besoin pour obtenir -Wall:

[neilb@GONERIL NeilB]$ g++ -Wall nr.cpp 
nr.cpp: In function 'int f()': 
nr.cpp:2: warning: no return statement in function returning non-void 

Bien sûr, avec g ++ vous devez toujours compiler avec au moins -Wall de toute façon.

Answer 2

Il n'existe aucune garantie qu'un compilateur C++ l'appliquera. Une fonction C++ pourrait sauter hors de son flux de contrôle par des mécanismes inconnus du compilateur. Context change lorsque C++ est utilisé pour écrire un noyau OS est un exemple de cela. Une exception non interceptée lancée par une fonction appelée (dont le code n'est pas nécessairement disponible pour l'appelant) en est une autre.

Certains autres langages, comme Java, imposent explicitement que, avec les connaissances disponibles au moment de la compilation, tous les chemins renvoient une valeur. En C++, cela n'est pas vrai, comme c'est le cas pour beaucoup d'autres occasions dans le langage, comme si l'accès à un tableau hors de ses limites n'était pas vérifié non plus.

Answer 3

Le compilateur n'applique pas cela parce que vous avez des connaissances sur les chemins qui sont pratiquement possibles que le compilateur ne le fait pas. Le compilateur ne connaît généralement que ce fichier particulier, pas d'autres qui peuvent affecter le flux à l'intérieur d'une fonction donnée. Donc, ce n'est pas une erreur.

Dans Visual Studio, cependant, il s'agit d'un avertissement. Et nous devrions faire attention à tous les avertissements .... pas vrai? :)

Modifier: Il semble y avoir une discussion sur le moment où cela pourrait se produire. Voici un exemple modifié mais réel de ma bibliothèque de code personnel;

enum TriBool { Yes, No, Maybe }; 

TriBool GetResult(int input) { 
    if (TestOne(input)) { 
     return Yes; 
    } else if (TestTwo(input)) { 
     return No; 
    } 
} 

Ours avec moi parce que c'est vieux code. A l'origine il y avait un "autre retour peut-être" là-bas. :) Si TestOne et TestTwo sont dans une unité de compilation différente, alors lorsque le compilateur atteint ce code, il ne peut pas dire si TestOne et TestTwo peuvent tous deux renvoyer false pour une entrée donnée. Vous, en tant que programmeur qui a écrit TestOne et TestTwo, savez que si TestOne échoue, alors TestTwo réussira. Peut-être qu'il y a des effets secondaires de ces tests, alors ils doivent être faits. Serait-il préférable de l'écrire sans "else if"? Peut être. Probablement. Mais le fait est que ceci est légal en C++ et le compilateur ne peut pas savoir s'il est possible de quitter sans une instruction return. Il est, je suis d'accord, moche et pas bien codé mais c'est légal et Visual Studio va vous donner un avertissement mais il va compiler. N'oubliez pas que le C++ ne vise pas à vous protéger contre vous-même. Il s'agit de vous permettre de faire ce que votre coeur désire dans les limites de la langue, même si cela inclut vous tirer dans le pied.