Pourquoi est f(i = -1, i = -1) un comportement indéfini?

Que j'ai lu sur l'ordre d'évaluation des violations, et ils donnent un exemple qui m'intrigue, c'.

1) Si un effet indésirable sur un scalaire objet est non-séquencés par rapport à un autre effet secondaire sur la même scalaire objet, le comportement est indéfini. 

//snip
f(i = -1, i = -1); //undefined behavior

Dans ce contexte, i est un scalaire objet, ce qui signifie apparemment

Arithmétique types (3.9.1), l'énumération des types, des types pointeur, pointeur de types de membres (3.9.2), std::nullptr_t, et de cv qualifiés versions de ces types (3.9.3) sont collectivement appelés types scalaires.

Je ne vois pas comment l'énoncé est ambigu dans ce cas. Il me semble que, peu importe si le premier ou le deuxième argument est évalué en premier, i finit -1, et les deux arguments sont également -1.

Quelqu'un peut-il préciser?

Mise à JOUR

J'ai vraiment apprécier toutes les discussions. Jusqu'à présent, j'aime @harmaline réponse beaucoup car il expose les pièges et subtilités de la définition de cette déclaration, en dépit de la façon dont tout droit vers l'avant, il semble au premier coup d'œil. @acheong87 souligne certains problèmes qui surgissent lors de l'utilisation de références, mais je pense que c'est orthogonale à la non effets secondaires aspect de cette question.

RÉSUMÉ

Depuis que cette question a obtenu une tonne de l'attention, je vais résumer les principaux points et/ou des réponses. Tout d'abord, permettez-moi une petite digression à souligner que "pourquoi" peut avoir étroitement liés et pourtant subtilement différentes significations, à savoir "ce que cause", "pour quoi raison", et "pour quoi but". Je vais regrouper les réponses par lequel de ces sens de "pourquoi" ils se sont adressés.

pour quelle cause

La principale réponse ici provient de Paul Draper, avec Martin J contribuant similaire, mais pas aussi étendues de réponse. Paul Draper la réponse se résume à

C'est un comportement indéfini, car il n'est pas défini ce que le comportement est.

La réponse est dans l'ensemble très bon en termes d'expliquer ce que le C++ standard dit. Il aborde également certains liés à des cas d'UB comme f(++i, ++i); et f(i=1, i=-1);. Dans le premier des cas, il n'est pas clair si le premier argument doit être i+1 et la deuxième i+2 ou vice-versa; dans le second, il n'est pas clair si i devrait être de 1 ou de -1, après l'appel de la fonction. Deux de ces cas sont des cas d'UB, parce qu'ils relèvent de la règle suivante:

Si un effet indésirable sur un scalaire objet est séquencé par rapport à un autre effet secondaire sur la même scalaire objet, le comportement est indéfini.

Par conséquent, f(i=-1, i=-1) est également UB car il tombe sous la même règle, malgré que l'intention du programmeur est (à mon humble avis) c'est évident et sans ambiguïté.

Paul Draper rend également explicite dans sa conclusion que

Aurait-il été défini comportement? Oui. Était-il défini? No.

qui nous amène à la question "pour quelles raisons a été f(i=-1, i=-1) gauche comme un comportement indéfini?"

pour quelles raisons

Bien qu'il existe quelques oublis (peut-être imprudente) dans la norme C++, de nombreuses omissions sont bien motivés et servir un but précis. Même si je suis conscient que le but est souvent de "faire le compilateur-écrivain travail plus facile", ou "plus vite code", j'ai surtout été intéressé de savoir si il y a une bonne raison de quitter f(i=-1, i=-1) comme UB.

harmaline et supercat fournir les principales réponses qui fournissent une raison pour l'UB. Harmaline, un compilateur optimisant qui pourraient briser soi-disant atomique des opérations d'affectation en plusieurs instructions machine, et qu'il pourrait en outre interleave ces instructions pour une vitesse optimale. Cela pourrait conduire à des résultats surprenants: i finit -2 dans son scénario! Ainsi, harmaline montre comment affecter le même valeur à une variable plus d'une fois, peut avoir des effets pervers si les opérations sont séquencé.

supercat fournit un liés à l'exposition des pièges d'essayer d'obtenir f(i=-1, i=-1) de faire ce qu'il dirait qu'il devrait faire. Il souligne que sur certaines architectures, il y a de dur restrictions à l'encontre des multiples et simultanées écrit à la même adresse mémoire. Un compilateur pourrait avoir un moment difficile de l'attraper si on avait affaire à quelque chose de moins banal que f(i=-1, i=-1).

davidf fournit également un exemple d'entrelacement des instructions très similaire à l'harmaline de l'.

Bien que chacun de harmaline, de supercat et davidf' exemples sont un peu artificiel, prises ensemble, elles servent encore de fournir une réelle raison pourquoi f(i=-1, i=-1) devrait être un comportement indéfini.

J'ai accepté harmaline de la réponse, car elle fait le meilleur travail de traiter l'ensemble des significations de pourquoi, même si Paul Draper de la réponse adressée le "pourquoi" de la portion de mieux.

d'autres réponses

JohnB souligne que, si l'on considère surcharge des opérateurs d'affectation (au lieu de simplement les scalaires), alors on peut avoir des problèmes ainsi.

  • Un scalaire objet est un objet de type scalaire. Voir 3.9/9: "de l'Arithmétique types (3.9.1), l'énumération des types, des types pointeur, pointeur de types de membres (3.9.2), std::nullptr_t, et de cv qualifiés versions de ces types (3.9.3) sont collectivement appelés types scalaires."
  • Peut-être il y a une erreur sur la page, et il s'agit f(i-1, i = -1) ou quelque chose de similaire.
  • Jetez un oeil à cette question: stackoverflow.com/a/4177063/71074
  • Merci. N' "arithmétique" types comprennent bool?
  • Eh bien, je suppose que la réponse est simple: l'ordre d'évaluation des paramètres dépend de la convention d'appel utilisé par le compilateur/architecture - qui le programmeur n'a pas beaucoup de contrôle(?!) et donc, le comportement peut être différent d'un compilateur/architecture à l'autre.
  • SchighSchagh votre mise à jour devrait être dans la section de réponse.
  • Vous devriez probablement mentionner dans le résumé, que, depuis le C++17 ce n'est pas UB plus, voir @AlexDs réponse

InformationsquelleAutor Nicu Stiurca | 2014-02-10
  1. 343

    Puisque les opérations sont non, il n'y a rien de dire que les instructions de réaliser la mission ne peut pas être entrelacées. Il peut être optimal de le faire, en fonction de l'architecture du PROCESSEUR. Référencé dans la page indique ceci:

    Si A n'est pas séquencée avant de B et B n'est pas séquencée avant, puis
    deux possibilités existent:

    • évaluations de A et B sont non: ils peuvent être effectués dans n'importe quel ordre et peuvent se chevaucher (dans un seul thread d'exécution, le
      compilateur peut intercaler des instructions du PROCESSEUR qui la composent, A et B)

    • évaluations de A et B pour une durée indéterminée-séquencés: ils peuvent être effectués dans n'importe quel ordre, mais ne peuvent pas se chevaucher: soit Un sera complet
      avant B, ou B sera complet avant de A. La commande peut être le
      en face la prochaine fois que la même expression est évaluée.

    Que par lui-même ne semble pas comme il serait la cause d'un problème - en supposant que l'opération en cours est de stocker la valeur -1 dans un emplacement de mémoire. Mais il n'y a rien de dire que le compilateur ne peut pas optimiser que dans un ensemble d'instructions qui a le même effet, mais qui pourrait échouer si l'opération a été intercalées avec une autre opération sur le même emplacement de mémoire.

    Par exemple, imaginez que c'était plus efficace à zéro de la mémoire, puis de décrémentation, par rapport à charger la valeur -1 dans. Puis ceci:

    f(i=-1, i=-1)

    pourrait devenir:

    clear i
clear i
decr i
decr i

    Maintenant i est -2.

    Il est probablement un faux exemple, mais c'est possible.

    • Très bel exemple de la façon dont l'expression pourrait réellement faire quelque chose d'inattendu tout en se conformant à des règles d'ordonnancement. Oui, un peu tiré par les cheveux, mais c'est le code ciselée je veux parler en premier lieu. 🙂
    • Et même si l'assignation est faite comme une opération atomique, il est possible de concevoir une superscalar architecture où les deux affectations sont faites simultanément, provoquant des accès à la mémoire du conflit qui se solde par un échec. Le langage est conçu de sorte que les rédacteurs du compilateur ont autant de liberté que possible en utilisant les avantages de la machine cible.
    • J'aime vraiment votre exemple de la façon dont même l'attribution de la même valeur pour la même variable dans les deux paramètres pourraient aboutir à un résultat inattendu, car les deux missions sont séquencé
    • +1e+6 (ok, +1) pour le point que le code compilé n'est pas toujours ce que vous attendez. Les optimiseurs sont vraiment bonne à jeter ces sortes de courbes à vous lorsque vous ne suivez pas les règles 😛
    • Sur le processeur Arm une charge de 32 bits peut prendre jusqu'à 4 instructions: Il ne load 8bit immediate and shift jusqu'à 4 fois. Généralement, le compilateur ne adressage indirect pour extraire un numéro de la forme d'une table pour éviter cela. (-1 peut être fait en 1 instruction, mais un autre exemple pourrait être choisi).
    • Sur quelque chose comme un PIC 16Cxx, unsigned char foo=255; peut-être movlw 255 / movwf _foo ou clrf _foo / decf foo. L'ancien testament de la charge de travail s'inscrire avec 255; ce dernier permettra de le laisser tranquille.
    • Je pense que cette réponse fait plus de mal que de bien. Il n'importe pas de savoir si ou non vous pouvez penser d'une certaine façon, il peut échouer. La norme dit que c'est pas défini, et que la norme est la source faisant autorité pour ce qu'il fait ou ne définit pas. Période.
    • Bel exemple! Le compilateur clang pris cette situation avec -Wunsequenced (je présume que GCC serait de faire ainsi).

    InformationsquelleAutor harmic
  2. 209

    Première, "scalaire objet" désigne un type comme un int, float, ou un pointeur (voir Ce qui est un scalaire Objet en C++?).

    Seconde, il peut sembler plus évident que 

    f(++i, ++i);

    aurait un comportement indéfini. Mais

    f(i = -1, i = -1);

    est moins évident.

    Un exemple légèrement différent:

    int i;
f(i = 1, i = -1);
std::cout << i << "\n";

    Attribution de ce qui s'est passé "dernier", i = 1, ou i = -1? Ce n'est pas définie dans la norme. Vraiment, cela signifie que i pourrait être 5 (voir l'harmaline, en réponse à une explication plausible pour l'devriez être le cas). Ou vous programme pourrait erreur de segmentation. Ou de reformater votre disque dur.

    Mais maintenant, vous demandez: "Quel sujet de mon exemple? J'ai utilisé la même valeur (-1) pour les deux missions. Ce qui pourrait éventuellement être difficile de savoir à ce sujet?"

    Vous avez raison...sauf dans la façon dont le C++ comité de normalisation décrit cette.

    Si un effet indésirable sur un scalaire objet est séquencé par rapport à un autre effet secondaire sur la même scalaire objet, le comportement est indéfini.

    Ils pourrait ont fait une exception pour votre cas particulier, mais ils n'ont pas. (Et pourquoi devraient-ils? Quelle sera l'utilisation que peut en avoir?) Donc, i pourrait encore être 5. Ou de votre disque dur pourrait être vide. Donc la réponse à votre question est:

    C'est un comportement indéfini, car il n'est pas défini ce que le comportement est.

    (Ce qui mérite d'être soulignée, car de nombreux programmeurs pensent "undefined" signifie "au hasard", ou "imprévisible". Il n'en est rien; il ne signifie pas définie par la norme. Le comportement pourrait être 100% compatible, et encore non défini.)

    Aurait-il été défini comportement? Oui. Était-il défini? Pas de. Par conséquent, il est "undefined".

    Qui a dit, "undefined" ne veut pas dire qu'un compilateur de formater votre disque dur...cela veut dire qu'il pourrait et il serait toujours conforme aux normes du compilateur. De façon réaliste, je suis sûr que g++, Clang, et MSVC tous faire ce qui vous attend. Ils n'ont pas de".

    Une autre question qui est peut être Pourquoi le C++ comité des normes de choisir pour faire de ce côté-effet non?. Cette réponse impliquera de l'histoire et de l'avis de la commission. Ou Ce qui est bon au sujet de avoir de ce côté-effet non en C++?, ce qui permet à toute justification, si oui ou non il était le raisonnement de la commission des normes. Vous pourriez poser ces questions ici, ou à programmers.stackexchange.com.

    • "De façon réaliste, je suis sûr que g++, Clang, et MSVC tous faire ce qui vous attend." - Tant que vous n'avez pas à passer des options spécifiquement pour attraper ce code, de toute façon.
    • oui, en fait je sais que si vous activez -Wsequence-point g++, il vous en avertira.
    • Pourquoi est-ce moins évident? Vous modifiez le même paramètre avant la séquence de point
    • J'étais en train de penser plus à quelque chose comme clang est -fsanitize=undefined qui, même si elle peut ne pas attraper ce dans sa forme actuelle (je ne suis pas sûr), pourrait dans l'avenir.
    • C'est moins évident parce que vous sont en train de changer à la même valeur dans les deux opérations, et ni l'affectation repose sur la valeur précédente, ainsi définie, l'ordre des opérations semble pas pertinent pour le lecteur occasionnel.
    • "Je suis sûr que g++, Clang, et MSVC tous faire ce qui vous attend" je ne ferais pas confiance à un compilateur moderne. Qu'ils sont mauvais. Par exemple, ils pourraient reconnaître que c'est un comportement indéterminé et d'assumer ce code est inaccessible. S'ils ne le font pas aujourd'hui, ils pourraient le faire demain. Tout UB est une bombe à retardement.
    • harmic a fourni un excellent exemple de POURQUOI cette UB peut générer des effets pervers. Les compilateurs modernes vraiment parfois faire de telles optimisations. Pas sur votre CPU? Déplacer vers Itanium. Ou AVR. Ou, Atari. (laissez-moi simplement ajouter que j'ai ceux de la plateforme sont des exemples de rhétorique et qui ne sont pas vérifiées 😉 )
    • Traditionnellement, on peut parfois remarquer que le compilateur est libre de réagir à l'indéfini des constructions en faisant des démons voler hors de votre nez. Donc quel que soit le comportement d'un compilateur de ne faire face à un indéfini de construire est un nasale démon.
    • Je suis curieux - comment avez-vous justifier en disant que "...i pourrait être de 5." dans le contexte du code en cours de discussion? Je suis d'accord que, compte tenu de f(i = 1, i = -1) la variable i pourrait être 1 ou -1, mais je ne vois pas comment i pourrait être affecté d'une valeur de 5 donné le code comme indiqué.
    • parce que c'est un comportement indéterminé. Donc si l'un compilateur décide qu'il veut je de 5, ou faire autre chose, alors il est encore conforme compilateur. Je ne pense pas qu'il signifie en réalité que i==5 serait une conséquence probable.
    • la réponse est mauvaise, parce qu'elle n'est pas bien" n'est pas très utile de rétroaction, est-il?
    • le comportement non défini est de l'ordre d'évaluation des missions. Si vous dites "attribuer 1", suivi par "affecter -1" et le compilateur met i à 5, ce n'est pas "un comportement indéfini" - c'est tout simplement faux.
    • jetez un oeil à l'Harmaline de réponse et dites-nous pourquoi ce (ou tout autre nombre) ne serait pas conforme à la norme.
    • comme Harmaline dit, c'est un faux exemple. Si le compilateur génère du code qui n'attribue pas une valeur, c'est mal. Il pourrait avoir un choix de que de la valeur à attribuer dans que commander, mais il ne peut pas affecter une mauvaise valeur. Dans cet exemple, il est à supposer que les instructions claires et décrémenter la valeur de i sont entrelacés; ce n'est pas raisonnable de comportement de la part du compilateur. Il pourrait générer clear; decr; clear; decr, mais clear; clear; decr; decr ne serait pas le résultat de quelque chose que l'exige le code, et la seule chose généré doit être un rapport de bogue.
    • Je ne prétends pas que ce genre de comportement serait raisonnable, mais je ne pense pas que c'est explicitement définie par la norme - et comme d'autres l'ont mentionné, une fois que vous avez UB, tout est permis, y compris les voies nasales démons et les disques durs formatés.
    • vous avez tort de supposer la serializability des opérations exécutées sur les données. Même si l'hypothèse est valable pour le courant dominant des architectures matérielles, beaucoup d'autres architectures ont existé et qui doivent être développés dans le futur.
    • Il peut même être plus raisonnable que vous ne le pensez. Lorsque vous avez accordé le luxe de faire quelque chose de UB, vous pouvez l'utiliser pour optimiser. Quand vous faites des optimisations tandis que les pas se soucier de la façon dont un cas d'utilisation des œuvres, vous pouvez obtenir de drôles de résultats.
    • La compile a absolument aucune obligation de produire la même distance de corriger le code dans le visage de comportement indéfini. Mésange peut même supposer que ce code n'est jamais la même appelé et donc remplacer le tout avec un nop (à Noter que les compilateurs réellement faire de telles hypothèses dans le visage de l'AC). Donc je dirais que la bonne réaction à un tel rapport de bug ne peut être "fermé, il fonctionne comme prévu"
    • En fait, j'ai même vu un guide d'optimisation de la avise écrire du code qui peut avoir un comportement indéfini pour permettre des optimisations du compilateur. (l'exemple est d'utiliser connecté indice de boucle variables, de sorte que le compilateur n'a pas à s'inquiéter de la production de corriger le comportement d'un unsigned boucle variable d'index de débordement)
    • It is undefined behavior because it is not defined what the behavior is. Pour moi, c'est tautologique réponse est plutôt insatisfaisant. Personnellement, j'ai tendance à associer UB avec des choses qui, naturellement, ne faites pas de sens ou qui est autrement difficile de définir. J'apprécie la discussion ici, mais je préfère l'harmaline de réponse qui permet de mieux exposer les pièges d'essayer de définir ce. (Votre réponse presque indices que la spécification du comité a été trop paresseux.)
    • la "raison", c'est ceci: dans le cas général, le comportement est incertain, car il n'y a pas de relatif "l'ordre" pour le paramètre de la fonction d'évaluation. Dans votre cas particulier, il n'y a aucune raison de le faire, donc ils ne vous inquiétez pas à propos de faire une exception.
    • suppose que vous ne comprenez pas la tautologique de l'ironie.
    • Peut-être le particulier de l'architecture CPU nécessite la mise en valeur de bit 4 avant le réglage de la 1, puis la suppression de 4. Résultant de la valeur 5. Je sais, c'est fou, mais des trucs comme ça arrive parfois.
    • Parfois, un de reformuler les termes (dont seulement sur la surface semble être une réponse tautologique) est ce que les gens ont besoin. La plupart des gens nouveaux à des spécifications techniques penser undefined behavior signifie something random will happen, ce qui est loin d'être le cas la plupart du temps.
    • J'ai tendance à associer UB avec des choses qui, naturellement, ne faites pas de sens ou qui est autrement difficile de définir" -- c'est l'erreur que cette réponse est d'essayer de corriger. Vous ne devez pas associer un comportement indéfini avec des choses qui sont difficiles à définir, vous devez l'associer avec des choses qui en fait ne sont pas définis. C'est bien si vous pouvez voir un exemple de pourquoi il bénéficie de certaines hypothèses de mise en œuvre pour être indéfini (comme harmaline de répondre, en fait), mais tout ce qui est nécessaire pour clarifier votre déclaration "i finit -1", c'est qu'il n'est pas garanti 😉
    • C'est aussi instructif que It is undefined behavior because it is not defined what the behavior is..
    • Je n'ai pas posé la question. J'ai juste répondu. (Et c'est la bonne réponse.)
    • Correct, oui, dans le sens que x == x est correct. Correct ne veut pas dire utile. Si j'ai demandé à Pourquoi X n'est pas le cas?, quelqu'un pouvait répondre à X n'est pas le cas, car il n'est pas le cas que X., et ils seraient de la même façon exact. Mais ces tautologies sont en aucun cas utile. En tout cas, votre récente clarification a supprimé la tautologie de la tautologie, pour ainsi dire. Avoir un upvote.
    • Une citation qui est très applicable ici. "Le pire résultat possible d'un comportement indéfini est de le faire faire ce que vous attendiez."

    InformationsquelleAutor Paul Draper
  3. 27

    Une raison pratique pour ne pas faire une exception aux règles simplement parce que les deux valeurs sont les mêmes:

    //config.h
#define VALUEA  1

//defaults.h
#define VALUEB  1

//prog.cpp
f(i = VALUEA, i = VALUEB);

    Considérer le cas cela était autorisé.

    Maintenant, quelques mois plus tard, le besoin de changer

     #define VALUEB 2

    Apparemment inoffensif, n'est-ce pas? Et pourtant, soudain, prog.cpp ne compile pas plus.
    Pourtant, nous pensons que la compilation ne doit pas dépendre de la valeur d'un littéral.

    Bottom line: il n'y a pas d'exception à la règle parce qu'il ferait compilation réussie dépend de la valeur (plutôt le type) d'une constante.

    MODIFIER

    @Dispositif heartware souligné qu'une des expressions de la forme A DIV B ne sont pas autorisés dans certaines langues, quand B est 0, et la cause de la compilation à l'échec. C'est pourquoi le changement d'une constante pourrait provoquer des erreurs de compilation dans un autre lieu. Qui est, à mon humble avis, regrettable. Mais il est certainement une bonne chose pour limiter de telles choses à l'inévitable.

    • Bien sûr, mais l'exemple de ne utilisez les littéraux entiers. Votre f(i = VALUEA, i = VALUEB); a certainement le potentiel pour un comportement indéterminé. J'espère que vous n'êtes pas vraiment de codage par rapport à des valeurs de derrière les identificateurs.
    • Mais le compilateur ne voit pas les macros du préprocesseur. Et même si ce n'était pas ainsi, il est difficile de trouver un exemple dans tout langage de programmation, où une source code compile jusqu'à ce que l'on modifie un int constant de 1 à 2. C'est tout simplement inacceptable et inexplicable, alors que vous voyez très bonnes explications ici pourquoi ce code est brisé, même avec les mêmes valeurs.
    • Oui, la compile ne voit pas les macros. Mais, a ce la question?
    • Votre réponse est à côté de la question, lire harmaline réponse et l'OP de la commenter.
    • "Et même si ce n'était pas ainsi, il est difficile de trouver un exemple dans tout langage de programmation, où une source code compile jusqu'à ce que l'on modifie un int constant de 1 à 2". C'est facile :-). Juste essayez de compiler ce: CONST A = 1; CONST B = 2; CONST C = B DIV (2-A); puis modifiez CONST A = 1 CONST A = 2 et voir si le compilateur compiler 🙂 :-).
    • Dans quelle langue?
    • PASCAL / Delphi / Pascal Objet
    • Ils se plaignent à ce sujet? Alors, ils sont cassés, à mon humble avis. Je voudrais accepter, même de bienvenue, un avertissement qu'il y a un zéro de diviser. Mais pas un refus de le compiler.
    • Quelle est la valeur de C puis ont dans les états qui l'utilisent? Comme lui passant comme paramètre à une fonction qui accepte un nombre entier? Comment le compilateur compiler cette déclaration: SomeProcedure(A,B,C);
    • Oh - et Microsoft C# compilateur se plaint de "Division par une constante zéro" dans le présent code: private const int A = 2; private const int B = 2; private const int C = B/(2 - Un); considérant que ce code fonctionne comme prévu: private const int A = 1; private const int B = 2; private const int C = B/(2 - Un); Donc, la seule modification à faire pas de compilation a été modifier une définition de la constante de 1 à 2 :-).
    • Il pourrait le faire SomeProcedure(A, B, B DIV (2-A)). De toute façon, si les états langue que CONST doivent être évaluées au moment de la compilation, alors, bien sûr, ma demande n'est pas valide pour ce cas. Puisque de toute façon il brouille la distinction de compile-time et de l'exécution. Serait-il également d'avis que si nous écrire CONST C = X(2-A); FUNCTION X:INTEGER(CONST Y:INTEGER) = B/Y; ?? Ou sont les fonctions qui ne sont pas autorisés?
    • CONST expressions (en PASCAL et en C#) doivent être entièrement évaluables au moment de la compilation, donc pas les appels de fonction sont autorisés. Et d'ailleurs - même, il le compilateur est de le compiler en tant que SomeProcedure(A, B, B DIV (2-UN)), il ne serait toujours pas compiler, tout ça parce que j'ai changé quelques int constant de 1 à 2. Donc il n'est pas difficile de trouver des exemples qui empêchent la compilation du fichier source lorsque je passe d'une définition d'une constante de 1 à 2 :-).
    • être pleinement évaluables au moment de la compilation, donc pas les appels de fonction sont permis" - c'est un non sequitur, en particulier lorsque le compilateur sait que la fonction et il contient uniquement un code qui est autorisé dans des expressions constantes. -- Cependant, je dois accepter que ma demande a été facile à réfuter. Pourtant, je ne pense pas que c'est comme il devrait être.
    • Touché :-). Permettez-moi de le modifier, puis: CONST expressions (en PASCAL et en C#) doivent être entièrement évaluables par le compilateur, sans l'aide de code défini par l'utilisateur, au moment de la compilation, donc pas de fonction définie par l'utilisateur les appels sont autorisés (mais f.ex. ABS, SQRT, et d'autres-dans des fonctions intrinsèques sont autorisés, car ils sont compilateur fourni par "magie" des fonctions et non réel, le code qui est appelé comme une sous-routine - au moins en PASCAL/Delphi).
    • Je ne vois pourquoi ils ne le permet pas. On pourrait facilement écrire l'ensemble des programmes en CONST FONCTIONS (à noter que les langages fonctionnels comme Haskell fournir uniquement ces fonctions, en dehors de primitives) et ceux des calculs entièrement dans le compilateur. Ce serait amusant. 🙂
    • Yet, we feel that compilation should not depend on the value of a literal. Meh. Vous pouvez faire beaucoup de trucs cool avec des littéraux, en particulier dans le modèle de méta-programmation, mais évidemment pas tous les possibles littérale sera toujours judicieux. Aussi, je pense que votre réponse manque le point un peu. Mais je vous remercie pour la discussion de toute façon.
    • Il a été écrit sur l'hypothèse qu'il est clair maintenant pourquoi f(i = 1, i = 2) est à juste titre pas défini, et tente de donner une pratique (plutôt que de la technique) pourquoi pas pour faire une exception à la règle dans le cas particulier f(i = 1, i = 1) (comme quelqu'un ici a suggéré).

    InformationsquelleAutor Ingo
  4. 12

    La confusion est que le stockage d'une valeur constante à une variable locale n'est pas une instruction atomique sur chaque architecture, la C est conçu pour être exécuté sur. Le processeur le code s'exécute sur des sujets plus que le compilateur dans ce cas. Par exemple, sur les BRAS où chaque instruction ne peut pas porter un complet de 32 bits constant, stocker un int dans une variable a besoin de plus qu'une instruction. Exemple avec cette pseudo-code où vous pouvez stocker uniquement les 8 bits à la fois et doit travailler dans un 32 bits de registre, je est un int32:

    reg = 0xFF; //first instruction
reg |= 0xFF00; //second
reg |= 0xFF0000; //third
reg |= 0xFF000000; //fourth
i = reg; //last

    Vous pouvez imaginer que si le compilateur veut optimiser l'on peut intercaler d'une même séquence deux fois, et vous ne savez pas quelle valeur sont écrites dans i; et disons qu'il n'est pas très intelligent:

    reg = 0xFF;
reg |= 0xFF00;
reg |= 0xFF0000;
reg = 0xFF;
reg |= 0xFF000000;
i = reg; //writes 0xFF0000FF == -16776961
reg |= 0xFF00;
reg |= 0xFF0000;
reg |= 0xFF000000;
i = reg; //writes 0xFFFFFFFF == -1

    Cependant, dans mes tests, gcc est assez aimable pour reconnaître que la même valeur est utilisée deux fois et génère une seule fois, et n'a rien de bizarre. Je reçois -1, -1
    Mais mon exemple est encore valide, il est important de considérer que même une constante ne peut pas être aussi évidente qu'elle semble être.

    • Je suppose que sur les BRAS le compilateur suffit de charger la constante à partir d'une table. Ce que vous décrivez ressemble plus à MIPS.
    • Yep, mais dans un cas où elle n'est pas simplement -1 (que le compilateur a stocké quelque part), mais c'est plutôt 3^81 mod 2^32, mais constante, alors le compilateur peut faire exactement ce qui est fait ici, et dans certains levier de omtimization, mon interleave l'appel des séquences pour éviter l'attente.
    • ouais, je l'ai vérifié en place déjà. En effet, le compilateur est trop intelligent pour charger chaque constante à partir d'une table. De toute façon, il ne serait jamais utiliser le même registre pour calculer les deux constantes. Ce serait tout aussi sûrement "destruction" le comportement défini.
    • Mais vous n'êtes probablement pas "chaque compilateur C++ programmeur dans le monde". Rappelez-vous qu'il y a des machines avec 3 court registres disponibles pour les calculs uniquement.
    • prenons l'exemple f(i = A, j = B) où i et j sont deux objets distincts. Cet exemple n'a pas d'UB. Machine ayant 3 court registres n'est pas une excuse pour le compilateur de mélanger les deux valeurs de A et B dans le même registre (comme indiqué dans @davidf de réponse), parce qu'il allait se casser la sémantique du programme.
    • Cette réponse est un non-sens. C'est une pure question à propos de la norme. Ce que toute plate-forme qui fonctionne ou ne pas le faire n'est pas pertinent. Même si il n'existait pas de plate-forme où cela pourrait éventuellement échouer, le comportement serait encore indéfini parce que la norme dit clairement qu'il n'a pas le définir.

    InformationsquelleAutor davidf
  5. 11

    Comportement est généralement spécifié non définies s'il est concevable de raison d'un compilateur qui essayait d'être "utile" peut faire quelque chose qui serait la cause totalement inattendue.

    Dans le cas où une variable est écrit plusieurs fois avec rien pour s'assurer que les écritures se produire à des moments distincts, certains types de matériel peut autoriser plusieurs "stocker" les opérations qui doivent être effectuées simultanément à différentes adresses à l'aide d'un double port mémoire. Cependant, certaines à double port souvenirs interdisent expressément le scénario où deux magasins frappé de la même adresse simultanément, indépendamment de si oui ou non les valeurs écrites match. Si un compilateur pour une telle machine remarque deux séquencé tente d'écrire la même variable, il peut soit refuser de compiler ou de s'assurer que les deux écritures ne peuvent pas obtenir prévus en même temps. Mais si l'un ou les deux de l'accès est par l'intermédiaire d'un pointeur ou d'une référence, le compilateur ne peut pas toujours être en mesure de dire si les deux écritures peuvent frapper le même emplacement de stockage. Dans ce cas, il peut planifier l'écrit simultanément, provoquant un matériel de piège sur la tentative d'accès.

    Bien sûr, le fait que quelqu'un pourrait mettre en œuvre un compilateur C sur une telle plate-forme ne permet pas de croire qu'un tel comportement ne devrait pas être définis sur des plates-formes matérielles lors de l'utilisation de magasins de types assez petit pour être traitées de manière atomique. Essayez de stocker deux valeurs différentes dans séquencé de la mode pourrait causer étrangeté, si un compilateur n'est pas au courant de celui-ci; par exemple, étant donné:

    uint8_t v;  //Global

void hey(uint8_t *p)
{
  moo(v=5, (*p)=6);
  zoo(v);
  zoo(v);
}

    si le compilateur dans les lignes de l'appel à "meuh" et vous pouvez dire qu'il ne modifie pas la
    "v", il peut stocker un 5 à v, puis stocker un 6 *p, puis passer 5 à "zoo",
    et puis passer le contenu de v pour "zoo". Si "zoo" ne pas modifier "v",
    il devrait y avoir aucun moyen de les deux appels doivent être transmises des valeurs différentes,
    mais qui pourrait facilement passer de toute façon. D'autre part, dans les cas où
    deux magasins à écrire la même valeur, telle étrangeté ne pourrait pas se produire et
    il y aurait sur la plupart des plateformes être pas de raison logique pour une mise en œuvre
    à faire des choses bizarres. Malheureusement, certains rédacteurs de compilateur n'en a pas besoin
    excuse stupide comportements au-delà de "parce que la Norme le permet", de sorte que même
    ces cas ne sont pas sécuritaires.

    InformationsquelleAutor supercat
  6. 9

    Le fait que le résultat serait le même dans la plupart des implémentations dans ce cas, est accessoire; l'ordre d'évaluation n'est toujours pas défini. Envisager f(i = -1, i = -2): ici, l'ordre des questions. La seule raison pour laquelle il n'a pas d'importance dans votre exemple, l'accident que les deux valeurs sont -1.

    Étant donné que l'expression est spécifié comme l'une avec un comportement indéfini, un malicieusement conforme compilateur peut afficher une image inappropriée lorsque vous évaluez f(i = -1, i = -1) et interrompt l'exécution - et toujours être considéré comme tout à fait correct. Heureusement, pas de compilateurs je suis conscient de le faire.

    InformationsquelleAutor Amadan
  7. 8

    Il me semble que la seule règle concernant le séquençage de l'argument de fonction de l'expression est ici:

    3) Lors de l'appel d'une fonction (la fonction est en ligne, et si oui ou non explicite de la fonction de la syntaxe d'appel est utilisé), chaque valeur de calcul et des effets secondaires associés avec n'importe quel argument de l'expression, ou avec le suffixe expression désignant la fonction appelée, est séquencée avant l'exécution de chaque instruction ou de l'expression dans le corps de la fonction appelée.

    Ce n'est pas de définir le séquençage entre les expressions d'arguments, on se retrouve donc dans ce cas:

    1) Si un effet indésirable sur un scalaire objet est séquencé par rapport à un autre effet secondaire sur la même scalaire objet, le comportement est indéfini.

    Dans la pratique, sur la plupart des compilateurs, l'exemple que vous avez cité fonctionnent très bien (par opposition à "l'effacement du disque dur" et d'autres théorique comportement indéfini conséquences).

    Il est, cependant, une responsabilité, puisque cela dépend du compilateur spécifique de comportement, même si les deux valeurs sont les mêmes. Aussi, évidemment, si vous avez essayé d'attribuer des valeurs différentes, le résultat serait "vraiment" undefined:

    void f(int l, int r) {
    return l < -1;
}
auto b = f(i = -1, i = -2);
if (b) {
    formatDisk();
}
    InformationsquelleAutor Martin J.
  8. 8

    C++17 définit plus strictes règles d'évaluation. En particulier, les séquences des arguments de la fonction (bien que dans un ordre non spécifié).

    N5659 §4.6:15

    Les évaluations Un et B sont pour une période indéterminée séquencé lorsque Un est séquencée avant de B ou B est séquencée avant de Un,
    mais il n'est pas précisé lequel. [ Note: pour une période Indéterminée séquencé les évaluations ne peuvent pas se chevaucher, mais pourrait
    exécuté en premier. —la note de fin de ]

    N5659 § 8.2.2:5

    L'
    l'initialisation d'un paramètre, y compris tous les associés de la valeur de calcul et d'effets secondaires, est pour une période indéterminée
    séquencé par rapport à celle de tout autre paramètre.

    Il permet à certains cas qui serait UB avant:

    f(i = -1, i = -1); //value of i is -1
f(i = -1, i = -2); //value of i is either -1 or -2, but not specified which one
    • Merci pour l'ajout de cette mise à jour pour c++17, donc je n'ai pas à le faire. 😉
    • Génial, merci beaucoup pour cette réponse. Légère suivi: si f's signature ont été f(int a, int b), est-ce que C++17 garantir que a == -1 et b == -2 si on l'appelle comme dans le deuxième cas?
    • Oui. Si nous avons paramètres a et b, puis i-puis-a sont initialisé à -1, après i-puis-b sont initialisées à -2, ou le moyen de la contourner. Dans les deux cas, nous nous retrouvons avec a == -1 et b == -2. Au moins c'est comment j'ai lu "L'initialisation d'un paramètre, y compris tous les associés de la valeur de calcul et d'effets secondaires, est pour une période indéterminée séquencé par rapport à celle de tout autre paramètre".
    • Je pense que ça a été la même en C depuis toujours.
    InformationsquelleAutor AlexD
  9. 5

    De l'opérateur d'affectation pourrait être surchargé, qui pourrait avoir son importance:

    struct A {
    bool first;
    A () : first (false) {
    }
    const A & operator = (int i) {
        first = !first;
        return * this;
    }
};

void f (A a1, A a2) {
    //...
}


//...
A i;
f (i = -1, i = -1);   //the argument evaluated first has ax.first == true
    • Il est vrai, mais la question était de savoir types scalaires, qui d'autres l'ont souligné signifie essentiellement int de la famille, le flotteur de la famille, et des pointeurs.
    • Le vrai problème dans ce cas est que l'opérateur d'affectation est dynamique, de sorte que même régulièrement de la manipulation de la variable est sujette à des questions de ce genre.
    InformationsquelleAutor JohnB
  10. 2

    C'est juste pour répondre à "je ne suis pas sûr de ce que "scalaire objet" pourrait se traduire en plus de quelque chose comme un int ou un float".

    Je interpréter le "scalaire objet" comme une abréviation de "type scalaire objet", ou simplement "variable de type scalaire". Ensuite, pointer, enum (constante) sont de type scalaire.

    C'est un article de MSDN de Types Scalaires.

    • Il lit un peu comme un "lien seule réponse". Pouvez-vous copier le bits à partir de ce lien vers cette réponse (dans une blockquote)?
    • Ce n'est pas un lien unique réponse. Le lien est seulement pour de plus amples explications. Ma réponse est un "pointeur", "enum".
    • Je n'ai pas dit votre réponse est un lien unique réponse. Je l'ai dit ", se lit comme [un]". Je vous suggère de lire jusqu'pourquoi nous ne voulons pas de lien seules réponses dans la section aide. La raison d'être, si Microsoft met à jour l'Url de leur site, ce lien se brise.
    InformationsquelleAutor Peng Zhang
  11. 1

    En fait, il y a une raison de ne pas dépendre du fait que le compilateur vérifiera que i est attribué, avec la même valeur à deux reprises, de sorte qu'il est possible de le remplacer avec de l'affectation unique. Que faire si nous avons certaines expressions?

    void g(int a, int b, int c, int n) {
    int i;
    //hey, compiler has to prove Fermat's theorem now!
    f(i = 1, i = (ipow(a, n) + ipow(b, n) == ipow(c, n)));
}
    • N'a pas besoin de démontrer le théorème de Fermat: il suffit d'attribuer 1 à i. Soit les deux arguments attribuer 1 et ce n'est la "bonne" chose, ou les arguments attribuer des valeurs différentes et c'est un comportement indéfini de sorte que notre choix est encore possible.
    InformationsquelleAutor polkovnikov.ph