Quel est le point de noreturn?

[dcl.attr.noreturn] donne l'exemple suivant:

[[ noreturn ]] void f() {
    throw "error";
    //OK
}

mais je ne comprends pas quel est le point de [[noreturn]], parce que le type de retour de la fonction est déjà void.

Alors, quel est le point de la noreturn attribut? Comment est-il censé être utilisé?

  • Ce qui est important à propos de ce genre de d'une fonction (qui ont le plus de chances de se produire une fois dans un programme d'exécution) qui mérite une telle attention? N'est-ce pas facilement détectable situation?
  • L'OP est l'amalgame entre les notions de “retour” et “valeur de retour”. Compte tenu de la façon dont ils sont presque toujours utilisé en tandem, je pense que la confusion est justifiée.
  • Votre titre est parfait!
InformationsquelleAutor BЈовић | 2012-05-10
  1. 185

    La noreturn attribut est censé être utilisé pour les fonctions qui ne retournent pas à l'appelant. Cela ne veut pas dire nulle (fonctions qui ne retournent pas à l'appelant - ils juste ne retourne pas une valeur), mais les fonctions où le flux de contrôle ne sera pas de retour à la fonction appelante après la fonction se termine (par exemple, les fonctions que vous quittez l'application, boucle pour toujours ou de lancer des exceptions comme dans votre exemple).

    Cela peut être utilisé par les compilateurs de faire quelques optimisations et de générer de meilleurs avertissements. Par exemple, si f a la noreturn attribut, le compilateur pourrait vous avertir sur g() mort de code lorsque vous écrivez f(); g();. De même, le compilateur ne sais pas pour vous avertir sur le manque de retour des déclarations après les appels à f().

    • Quid d'une fonction, telle que la execve que ne pas de retour, mais pourrait? Devrait-il avoir le noreturn attribut?
    • Non, il ne devrait pas -- s'il y a une possibilité de contrôle de flux pour retourner à l'appelant, il ne doit pas avoir la noreturn attribut. noreturn ne peut être utilisée que si votre fonction est la garantie de faire quelque chose qui met fin au programme avant de flux de contrôle peut retourner à l'appelant, par exemple parce que vous appelez de sortie (de), abort(), assert(0), etc.
    • Cela comprend-il les rentre par exception jeter (façon de parler), ou ne les exceptions lancées sauter catches en dehors de la noreturn fonction, ou est en train de lancer des exceptions à l'intérieur de la noreturn fonction refusé?
    • Si un appel à une noreturn fonction est enveloppé dans un try-bloc, le code du bloc catch sur sera considéré comme accessible à nouveau.
    • Cool. Il n'est donc pas possible de revenir en arrière, juste anormal. C'est utile. Des acclamations.
    • non, il est impossible de revenir. Lancement d'une exception n'est pas de retour, donc si chaque chemin jette alors c'est noreturn. La manipulation de cette exception n'est pas la même que celle ayant retourné. Le code à l'intérieur de la try après l'appel est toujours inaccessible, et si pas void puis de toute cession ou l'utilisation de la valeur de retour ne se fera pas.
    • Oui bien évidemment, il est impossible de officiellement return; toutefois, j'ai demandé si il était possible de faire un retour de l'exécution de l'opération. C'est pourquoi j'ai dit “le retour via exception jeter (façon de parler)”. J'aurais probablement écrit “l'accomplissement (hacky) fonctionnalité semblable à revenir à l'aide de throw” ou tout simplement “sortie de l'exécution de la fonction et de continuer dans la enfermant appel à l'aide de throw”. Tout le monde ici sait que throw n'a pas de valeur de retour, et qu'il reprend l'exécution à la catch. J'ai demandé pour le retour-comme capacité, pas return.
    • Je ne serais pas si sûr que "tout le monde le sait" -- gardez à l'esprit que les gens très nouvelle C++ et de la programmation en général sont sur ce site, trop, et il serait trop facile pour eux de lire vos commentaires et de supposer que throwing était un type de returning. Je suis conscient que ce n'était pas votre intention, mais c'est pourquoi il vaut la peine explicitement soulignée, même si tout le monde qui a commenté susceptibles de connaître la différence. (Aussi, désolé pour le nécro, mais personne d'autre n'explique donc j'ai senti comme si quelqu'un doit.)
    • Je pense qu'il serait utile de modifiering cette réponse à mentionner explicitement comment throw est traitée. Alors qu'il est déjà implicite, cela le rend plus clair et coûte très peu à ajouter les phrases "throwing à partir d'un [[noreturn]] fonction est possible, et fonctionne comme prévu -- la seule chose que vous ne pouvez pas faire est de return. Si vous encapsuler l'appel à un try/catch, vous pouvez le traiter comme n'importe quel autre lancer la fonction". (Probablement mieux écrit, cependant).

    InformationsquelleAutor sepp2k
  2. 57

    noreturn ne pas dire au compilateur que la fonction ne retourne aucune valeur. Il indique au compilateur que flux de contrôle ne sera pas de retour à l'appelant. Cela permet au compilateur de faire une variété d'optimisations -- il n'a pas besoin d'enregistrer et de restaurer tous les volatiles de l'état autour de l'appel, il peut dead-code d'éliminer n'importe quel code qui serait autrement suivent l'appel, etc.

    InformationsquelleAutor Stephen Canon
  3. 26

    Cela signifie que la fonction ne sera pas complète. Le flux de contrôle n'atteindra jamais l'instruction suivant l'appel à f():

    void g() {
   f();
   //unreachable:
   std::cout << "No! That's impossible" << std::endl;
}

    L'information peut être utilisée par le compilateur/optimiseur de différentes manières. Le compilateur peut ajouter un avertissement que le code ci-dessus est inaccessible, et il peut modifier le code de g() de différentes manières, par exemple à l'appui de poursuites.

    • gcc/clang ne pas donner des avertissements
    • Compiler avec -Wno-return et vous recevrez un avertissement. Probablement pas celui que vous attendiez, mais il est probablement suffisant pour vous dire que le compilateur a connaissance de ce que [[noreturn]] est et il peut prendre avantage de cela. (Je suis un peu surpris de voir que -Wunreachable-code n'a pas un coup de pied dans...)
    • ne prévient pas 🙁
    • Désolé -Wmissing-noreturn, l'avertissement implique que l'analyse des flux déterminé que le std::cout n'est pas accessible. Je n'ai pas un assez nouveau gcc à la main à l'assembly généré, mais je ne serais pas surpris si l'appel à operator<< a été abandonné
    • maintenant ça fonctionne, et c'est assez décent (essentiellement: [[noreturn]] doit être appliquée de manière transitive vers l'extérieur-plus de portée)
    • Voici un assemblée dump (-S -o - drapeaux en coliru), en effet les gouttes de la "inaccessible" du code. Fait intéressant à noter, -O1 est déjà assez pour déplacer ce code inaccessible sans la [[noreturn]] soupçon.
    • Tout le code est dans la même unité de traduction et visible, de sorte que le compilateur peut en déduire la [[noreturn]] à partir du code. Si cette unité de traduction n'avait qu'une déclaration de la fonction qui a été défini quelque part d'autre, le compilateur ne sera pas en mesure de déposer le code, car il n' savoir que la fonction ne retourne pas. C'est là que l'attribut doit aider le compilateur.

    InformationsquelleAutor David Rodríguez - dribeas
  4. 12

    Réponses précédentes correctement expliqué ce que noreturn est, mais pas pourquoi il existe. Je ne pense pas que le "optimisation" des commentaires est le but principal: Fonctions qui ne sont pas de retour sont rares et habituellement n'ont pas besoin d'être optimisé. Au contraire, je pense que la principale raison d'être de noreturn est pour éviter les faux-positifs avertissements. Considérons par exemple ce code:

    int f(bool b){
    if (b) {
        return 7;
    } else {
        abort();
    }
 }

    Avait abort() pas été marqués comme "noreturn", le compilateur peut ont mis en garde à propos de ce code ayant un chemin où f ne pas renvoyer un nombre entier comme prévu. Mais parce que abort() est marqué pas de retour, il sait que le code est correct.

    • Tous les autres exemples mentionnés utiliser void fonctions -- comment fonctionne lorsque vous avez à la fois la [[pas de retour]] directive et un non-vide type de retour? Le [[pas de retour]] directive n'entre en jeu que lorsque le compilateur s'apprête à mettre en garde sur une possibilité de ne pas retourner et d'ignorer l'avertissement? Par exemple, le compilateur de go: "Ok, c'est un non-void function." * continue de la compilation * "Oh merde, ce code peut ne pas revenir! Dois-je avertir l'utilisateur?* "Tant pis, j'voir la n de la directive retour. Carry on"
    • Le noreturn fonction dans mon exemple n'est pas f(), c'est abort(). Il ne fait pas de sens pour marquer un non-void function noreturn. Une fonction qui retourne parfois une valeur et retourne parfois (un bon exemple est execve()) ne peut pas être marqué noreturn.
    InformationsquelleAutor Nadav Har'El
  5. 10

    Type théoriquement parlant, void est ce qui est appelé dans d'autres langues unit ou top. Son équivalent logique est Vrai. Toute valeur peut être légitimement exprimées à void (chaque type est un sous-type de void). Penser à cela comme une "univers" ensemble; il n'y a pas d'opérations en commun à tous les valeurs dans le monde, donc il n'y a pas d'opérations valides sur une valeur de type void. Mettre une autre manière, vous dire que quelque chose appartient à l'univers vous donne aucune information que ce soit, vous le savez déjà. Donc la suite est du son:

    (void)5;
(void)foo(); //whatever foo() does

    Mais la cession ci-dessous n'est pas:

    void raise();
void f(int y) {
    int x = y!=0 ? 100/y : raise(); //raise() returns void, so what should x be?
    cout << x << endl;
}

    [[noreturn]], d'autre part, on appelle parfois empty, Nothing, Bottom ou Bot et est l'équivalent logique de Faux. Il n'a pas de valeurs à tous, et une expression de ce type peuvent être exprimés à l' (j'.e est le sous-type) de tout type. C'est l'ensemble vide. Notez que si quelqu'un vous dit "la valeur de l'expression foo() appartient à l'ensemble vide" c'est très instructif - il vous dit que cette expression ne sera jamais complète son exécution normale; il va abandonner, de jeter ou de blocage. Il est l'exact opposé de void.

    Donc la suite n'a pas de sens (pseudo-C++, car noreturn n'est pas un premier de la classe C++ type)

    void foo();
(noreturn)5; //obviously a lie; the expression 5 does "return"
(noreturn)foo(); //foo() returns void, and therefore returns

    Mais la cession ci-dessous est tout à fait légitime, puisque throw est compris par le compilateur de ne pas revenir:

    void f(int y) {
    int x = y!=0 ? 100/y : throw exception();
    cout << x << endl;
}

    Dans un monde parfait, vous pouvez utiliser noreturn que la valeur de retour de la fonction raise() ci-dessus:

    noreturn raise() { throw exception(); }
...
int x = y!=0 ? 100/y : raise();

    Malheureusement C++ ne le permet pas, probablement pour des raisons pratiques. Au lieu de cela il vous donne la possibilité d'utiliser [[ noreturn ]] attribut qui permet de guider les optimisations du compilateur et les avertissements.

    • Rien ne peut être jeté à l' void et void jamais évalue à true ou false ou quoi que ce soit d'autre.
    • Tout ce qui peut être jeté à void. et void jamais évalue à true depuis bool est sous-type de void et non l'inverse. Encore une fois, tout ce qui est dit ici est de type théorique. rien C++-centrique. void n'est pas un 1er de la classe des citoyens dans le C++ type de système.
    • Quand je dis true, je ne veux pas dire "la valeur true du type bool" mais la logique du sens, voir Curry-Howard correspondance
    • Type abstrait de la théorie qui ne correspond pas au type de système d'une langue spécifique est hors de propos lors du débat sur le type de système de la langue. La question, en cause :-), est sur le C++, pas de théorie des types.
    • Précisément à cette question, type abstrait de la théorie des donne la réponse parfaite. C++ ne prend pas brutalement la viole (puisque c'est à peu près cohérent) dans ce cas.
    • Pourquoi pouvez-vous faire en C++ des trucs comme y!=0 ? x/y : throw exception()
    • Spécifiquement pour cette réponse, il suggère que void(true) est autorisé en C++. Il n'est pas. y != 0 ? x / y : throw exception() n'a rien à voir avec la façon dont void est traité comme un type.
    • (void)true; est parfaitement valide, comme la réponse suggère. void(true) est quelque chose de complètement différent, du point de vue syntaxique. C'est une tentative de créer un nouvel objet de type void par l'appel d'un constructeur avec true comme argument; cela échoue, entre autres raisons, parce que void n'est pas de première classe.
    • Il en est ainsi. Je suis habitué à utiliser le type(valeur) de casting, pas de c style casting.
    • Quelle langue, exactement, êtes-vous utilisé?
    • Je suis également curieux de connaître la langue dans laquelle vous êtes habitué. Ni de vous faire beaucoup de sens, d'être familier avec le C-style de langues, qui sont la pierre angulaire de la programmation moderne, par de nombreuses personnes de normes.
    • J'ai utilisé le C/C++ notation, tout comme l'OP.
    • Cette réponse n'a rien à voir avec l'OP de la question.
    • il explique la différence entre void et noreturn dans le type de la théorie terme, en complément de l' (certes plus utile) des réponses pratiques ci-dessus.

    InformationsquelleAutor Elazar