{"id":601,"date":"2023-04-27T10:32:51","date_gmt":"2023-04-27T08:32:51","guid":{"rendered":"https:\/\/naupacte.com\/?p=601"},"modified":"2023-04-27T10:58:03","modified_gmt":"2023-04-27T08:58:03","slug":"c-associative-operators-are-asocial","status":"publish","type":"post","link":"https:\/\/naupacte.com\/index.php\/en\/2023\/04\/27\/c-associative-operators-are-asocial\/","title":{"rendered":"C++ associative operators are asocial"},"content":{"rendered":"\n

C++ has the drawback of being a bit binary… in its way of processing n<\/em>-ary operations that does not care about the associative intent of the programmer. Do we have to wait for a quantum compiler with non-binary states to process together the operands associated by the parentheses? \ud83d\ude09<\/p>\n\n\n\n

The problem<\/h2>\n\n\n\n

Although the + and * operators are mathematically associative, C++ treats their operands 2 by 2 from left to right. Thus a+b+c+d<\/code> is seen as: ((a+b)+c)+d<\/code>, without there being any way of specifying that one wants a sum of four operands other than by the less expressive call of a function such as sum(a, b, c, d)<\/code>. Admittedly, by the classic means of expression-templates<\/em>, one could arrive at the desired result, but at the cost of losing respect for parentheses. For example, if the programmer writes (a+b+c)+d<\/code>, a template-expression<\/em> could group the first three terms together, but eventually aggregate the fourth. Unless a static operator ()<\/em> is added to the C++ standard<\/strong>, which would operate on the result of a+b+c<\/code>, there is no way to keep track of parentheses.<\/p>\n\n\n\n

This is a serious problem for a programming interface, because it is important to respect the user\u2019s expressed intention<\/strong>.<\/p>\n\n\n\n

Proposal for C++<\/h2>\n\n\n\n

Let Expr be a type on which we propose the possibility of defining the following + operator:<\/p>\n\n\n\n

enum ExprOperator { ..., OpSum, ... OpProduct, ...};\nstruct Expr { ExprOperator; std::vector<Expr> operands;};\nstd::vector<Expr> to_vector(Expr... ee);\n\nExpr operator+(Expr e, Expr... ee) \/\/ <- proposition\n{\n    return Expr { OpSum, to_vector(e,ee...) };\n}<\/code><\/pre>\n\n\n\n
Note that such a program gets compiled but the operator+ is taken as a binary one. The variadic argument stands for one and only one We want it to be accepted as n-ary. With this, we are able to translate (a+b+c)+d<\/code> into Expr{OpSum,{Expr{OpSum,{a,b,c}}, d}<\/code> respecting the original.<\/p>\n\n\n\n
Of course, all variants taking const Expr&<\/code> and Expr&&<\/code> are possible.<\/p>\n\n\n\n
Implicit conversions or operations with other types<\/h2>\n\n\n\n
Often, because we have an Expr<\/code> variable a, we want to add a numeric type, such as 1, as in a+1<\/code> or 1+a<\/code> without specifying a+Expr(1) <\/code>or Expr(1)+a<\/code>, which would ruin the elegance of our expression. The + binary operator conventionally makes it possible to process this. How can it be generalized to a sum of multiple operands, such as in 1+a+b<\/code> or a+1+b<\/code>? We propose to use the concepts by allowing to write:<\/p>\n\n\n\n
Expr operator+(Expr e, auto convertible_to<Expr>... ee)<\/code><\/pre>\n\n\n\n
The problem is that we don\u2019t always have an Expr<\/code> type in the first position, as in the case of 1+a+b<\/code>. We therefore propose that C++ interpret this definition as: multiple operands, one of which is of type Expr<\/code> and the others of type convertible_to<Expr><\/code>. Perhaps a more acceptable way for compilers would be to write:<\/p>\n\n\n\n
Expr operator+(auto convertible_to<Expr>... ee1, Expr e, auto convertible_to<Expr>... ee2)<\/code><\/pre>\n\n\n\n
in which it would be the first among the operands which is of type Expr<\/code>. This possibility would be reserved for non-Boolean associative operators (+,*,…). For Boolean operators, a better proposal should be given.<\/p>\n","protected":false},"excerpt":{"rendered":"
C++ has the drawback of being a bit binary… in its way of processing n-ary operations that does not care about the associative intent of the programmer. Do we have to wait for a quantum compiler with non-binary states to process together the operands associated by the parentheses? \ud83d\ude09 The problem Although the + and * operators are mathematically associative, C++ treats their operands 2 by 2 from left to right. Thus a+b+c+d is seen as: ((a+b)+c)+d, without there being any way of specifying that one wants a sum of four operands other than by the less expressive call of a function such as sum(a, b, c, d). Admittedly, by the classic means of expression-templates, one could arrive at the desired result, but at the cost of losing respect for parentheses. For example, if the programmer writes (a+b+c)+d, a template-expression could group the first three terms together, but eventually aggregate the fourth. Unless a static operator () is added to the C++ standard, which would operate on the result of a+b+c, there is no way to keep track of parentheses. This is a serious problem for a programming interface, because it is important to respect the user\u2019s expressed intention. Proposal for C++ Let Expr be a type on which we propose the possibility of defining the following + operator: Note that such a program gets compiled but the operator+ is taken as a binary one. The variadic argument stands for one and only one We want it to be accepted as n-ary. With this, we are able to translate (a+b+c)+d into Expr{OpSum,{Expr{OpSum,{a,b,c}}, d} respecting the original. Of course, all variants taking const Expr& and Expr&& are possible. Implicit conversions or operations with other types Often, because we have an Expr variable a, we want to add a numeric type, such as 1, as in a+1 or 1+a without specifying a+Expr(1) or Expr(1)+a, which would ruin the elegance of our expression. The + binary operator conventionally makes it possible to process this. How can it be generalized to a sum of multiple operands, such as in 1+a+b or a+1+b? We propose to use the concepts by allowing to write: The problem is that we don\u2019t always have an Expr type in the first position, as in the case of 1+a+b. We therefore propose that C++ interpret this definition as: multiple operands, one of which is of type Expr and the others of type convertible_to<Expr>. Perhaps a more acceptable way for compilers would be to write: in which it would be the first among the operands which is of type Expr. This possibility would be reserved for non-Boolean associative operators (+,*,…). For Boolean operators, a better proposal should be given.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[41],"tags":[35],"class_list":["post-601","post","type-post","status-publish","format-standard","hentry","category-cpp-en","tag-c"],"_links":{"self":[{"href":"https:\/\/naupacte.com\/index.php\/wp-json\/wp\/v2\/posts\/601","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/naupacte.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/naupacte.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/naupacte.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/naupacte.com\/index.php\/wp-json\/wp\/v2\/comments?post=601"}],"version-history":[{"count":4,"href":"https:\/\/naupacte.com\/index.php\/wp-json\/wp\/v2\/posts\/601\/revisions"}],"predecessor-version":[{"id":606,"href":"https:\/\/naupacte.com\/index.php\/wp-json\/wp\/v2\/posts\/601\/revisions\/606"}],"wp:attachment":[{"href":"https:\/\/naupacte.com\/index.php\/wp-json\/wp\/v2\/media?parent=601"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/naupacte.com\/index.php\/wp-json\/wp\/v2\/categories?post=601"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/naupacte.com\/index.php\/wp-json\/wp\/v2\/tags?post=601"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}