2016-02-02 4 views
11

N4191 proposées pli-expressions à C++. La définition était queAssociativité des expressions de pli

(args + ...) 

est un facteur gauche (c.-à-(((a0 + a1) + a2) + ...), et que

(... + args) 

est un droit fold (c.-à-(... + (a8 + (a9 + a10))). Cependant, le document révisé N4295 inversé les définitions de gauche et à droite plis unaire

question:. quelle est la raison d'être Il semble plus intuitive (au moins lorsque vous êtes habitué à gauche à droite alphabets) pour évaluer?de gauche à droite.

+1

Je voudrais juste demander à Richard ou Andrew :) – SergeyA

+1

Je ne sais pas leur raison d'être, mais pour moi '(... + args)' ressemble à une sous-expression du pli gauche '(((... + a8) + a9) + a10) '. De même, '(args + ...)' ressemble à une sous-expression de right fold '(a0 + (a1 + (a2 ...)))'. – user2079303

+0

@ user2079303 L'associativité gauche de 'a + b + c' est communément définie par (a + b) + c, vous utilisez le contraire – TemplateRex

Répondre

8

Depuis le commentaire par @cpplearner, voici quelques archéologie de std-discussion

Le mer., 4 févr. 2015 à 1:30 AM, @T.C. wrote:

Dans N4295, qui a été effectivement voté dans la norme,

(... op e) est un pli unaire gauche;

(e op ...) est un pli droit unaire;

En N4191, cependant,

(e op ...) est appelé un pli gauche.

(... op e) est appelé un pli droit.

Pourquoi le virage à 180 degrés?

Et la réponse par @RichardSmith

La forme dans le document original était simplement une faute de frappe. Voici quelques raisons pour lesquelles la définition qui a été votée dans la norme est le correct un:

  1. Dans la formulation de la norme, (e op ...) a subexpressions la forme (e_i op <stuff>).Il n'a pas de sous-expressions du formulaire (<stuff> op e_i). Ceci est cohérent avec toutes les autres extensions du bloc , où l'extension comprend des instances répétées du motif .

  2. (e op ... op eN), où eN est un non-pack, doit avoir eN comme l'opérande le plus intérieur afin d'être utile - à savoir, il doit être (e1 op (e2 op (e3 op (... op eN)...))), non (...(((e1 op e2) op e3) op ...) op eN) - et vice-versa pour (e0 op ... op e). Ceci permet, par exemple, , (string() + ... + things) et (std::cout << ... << things) de fonctionner. Par souci de cohérence, (e op ...) doit également être (e1 op (e2 op (...))).

6

Je ne peux pas parler en faveur de la proposition, mais les nouvelles définitions échangées me semblent naturelles. Mon raisonnement pour cela est que (... + args) est une sous-expression d'un pli gauche, et (args + ...) est une sous-expression d'un pli droit. En fait, le premier est le dernier segment, et le second est le segment initial de l'expression (je n'utilise peut-être pas la bonne terminologie).

Voici comment j'illustrerait l'expansion du pli de la syntaxe:

gauche pli

     (... + args) 
      (... + args) + a999) 
    (... + args) + a998) + a999) 

((...((a0 + a1) + a2)...) + a999) 

droit fold

(args + ...) 
(a0 + (args + ...) 
(a0 + (a1 + (args + ...) 

(a0 + (...(a997 + (a998 + a999))...))