名前付きループ in 標準C

プログラミング言語Cの次期標準C2yでは、名前付きループ(Named Loop)構文としてbreak／continue文へのラベル指定がサポートされる。

// C2y
outer:
for (int i = 0; i < N; ++i) {
  for (int j = 0; j < M; ++j) {
    break;       // 内部ループ脱出: 1)へ
    break outer; // 外部ループ脱出: 2)へ  
  }
  // 1)
}
// 2)

同様の構文はJava*1, JavaScript*2, Rust*3, Go*4等でもサポートされている。

関連URL

• N3355 Named loops, v3
• https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665061.html

*1:https://docs.oracle.com/javase/tutorial/java/nutsandbolts/branch.html

*2:https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/label

*3:https://doc.rust-lang.org/rust-by-example/flow_control/loop/nested.html

*4:https://go.dev/ref/spec#Label_scopes

8進数リテラルプレフィクス in 標準C

プログラミング言語Cの次期標準C2yでは、8進数リテラルプレフィクス0o／0Oが導入される。

// C2y
int n1 = 0o52;  // 42
int n2 = 0O52;  // 42
int n0 = 052;   // 42 (従来記法; 廃止予定)

0o／0Oプレフィクス追加と同時に、数値0のみプレフィクスとする従来8進数リテラル表記は廃止予定(obsolescent feature)とされる。

プログラミング言語C++に対しても2005年頃(！)に同等の提案P0085R0がなされており、C2y採択に伴ってC++2c(C++26)に向けた検討が再開されている。*1

関連URL

• N3353 Obsolete implicitly octal literals and add delimited escape sequences
• 2進数リテラル in 標準C - yohhoyの日記
• 019 > 020 ? - yohhoyの日記

*1:https://github.com/cplusplus/papers/issues/2055

OpenMP 6.0仕様リリース

2024年11月 OpenMP 6.0仕様リリース記事 https://www.openmp.org/home-news/openmp-arb-releases-openmp-6-0-for-easier-programming/ より抄訳。

OpenMP仕様バージョン6.0はOpenMP ARB、主要なコンピュータハードウェア／ソフトウェアベンダーのグループ、そしてOpenMPコミュニティ全体のユーザーによって共同開発されました。改訂仕様ではいくつかの細かな改良に加え、次の大きな追加が行われました：

• タスクプログラミングの簡略化：
  • 並列リージョンを実行するどのチームにも割当てられない、フリーエージェント(free-agent)スレッドによるタスク実行のサポート。
  • 効率的な再現実行(replay execution)のためのタスクグラフ記録(taskgraph record)の有効化。
  • 依存関係を指定できるタスクの集合を拡張する、透過タスク(transparent task)の追加。
• デバイスサポートの拡張：
  • 配列構文アプリケーションのサポート追加：workdistributeディレクティブは配列記法の実行を個別の作業単位へ分割し、Fortranのデバイスサポートを強化します。
  • メモリ割当とアクセシビリティの制御が強化され、割当可能な変数の管理が容易になります。
  • デフォルトのデータ環境属性のサポートを拡張。
  • 構造化された非同期データマッピング領域の追加による、非同期データ転送の記述の容易化。
  • デバイスへのデータマッピング拡張によるメモリ制御の向上。
  • groupprivateディレクティブより、デバイス上にチーム別メモリを持つ機能を追加。
• ループ変換(loop transformation)プログラミングの容易化： ループの融合(fusion)・反転(reverse)・交換(interchange)の使用が簡素化されます。
• インダクション(induction)操作のサポート：既知のパターンに従うループにおける基本的な算術演算とユーザ定義演算の並列化をサポート。*1
• 最新C／C++およびFortran言語標準の並列化をサポート：
  • C属性構文*2を含むC23、Fortran 2023、C++23の完全サポート。
  • 新しいC/C++属性の導入。
• ストレージリソースとメモリスペースのユーザコントロール強化：
  • メモリ割当制御を強化する新しいメモリトレイトを追加。
  • メモリ空間の定義とクエリのための新しいAPIルーチンを提供。
• 非推奨機能の削除：バージョン5.0、5.1、5.2で非推奨とされた機能が削除されました。

関連URL

• (PDF) OpenMP Application Programming Interface, Version 6.0
• OpenMP 5.2仕様リリース - yohhoyの日記
• OpenMP 5.1仕様リリース - yohhoyの日記
• OpenMP 5.0仕様リリース - yohhoyの日記
• OpenMP 4.5仕様リリース - yohhoyの日記
• OpenMP 4.0仕様リリース - yohhoyの日記

*1:従来からある リダクション(reduction)＝演繹操作 に対して、インダクション(induction)＝帰納操作 が導入される。反復的ループにおいて前イテレーションまでの計算結果に依存する演算。OpenMP 6.0では組込型のインダクション操作として加算(+)と乗算(*)がサポートされる。

*2:https://yohhoy.hatenadiary.jp/entry/20200505/p1

i += 1 + ++i; の処理結果（Go／Rust編）

異なるプログラミング言語における式i += 1 + ++i処理結果の違いについて。番外編。

// Go
var i = 0
i += 1 + ++i  // ??

// Rust
let mut i = 0;
i += 1 + ++i;  // ??

まとめ：

• Go：コンパイルエラー
• Rust：コンパイルエラー
• Java／JavaScript／C#：値2（→id:yohhoy:20241124）
• C／C++：未定義動作(undefined behavior) or 値3（→id:yohhoy:20241125）

Go

プログラミング言語Goでは設計判断として前置インクリメント++iを提供しない。また後置インクリメントi++は提供されるが、式(expression)ではなく文(statement)として提供される（→id:yohhoy:20200131）。Go言語FAQより引用。

Why are ++ and -- statements and not expressions? And why postfix, not prefix?
Without pointer arithmetic, the convenience value of pre- and postfix increment operators drops. By removing them from the expression hierarchy altogether, expression syntax is simplified and the messy issues around order of evaluation of ++ and -- (consider f(i++) and p[i] = q[++i]) are eliminated as well. The simplification is significant. As for postfix vs. prefix, either would work fine but the postfix version is more traditional; insistence on prefix arose with the STL, a library for a language whose name contains, ironically, a postfix increment.

https://go.dev/doc/faq#inc_dec

Go言語では代入(=)や代入演算(+=など)は文(statement)として規定され*1、難解な式記述を許さない言語仕様となっている。Simplicity.*2

{ // Java/JavaScript/C#的な動作
  var i = 0;
  i = i + 1 + (i + 1)
  //          ^^^^^^^ ++iの代用
  // 変数 i は 値2
}
{ // C/C++的な動作
  var i = 0
  i++  // ++iの代用
  i += 1 + i
  //       ^ 項++i相当
  // 変数 i は 値3
}

Rust

プログラミング言語Rustでは設計判断としてインクリメント演算子(++)を提供しない*3。Rust言語Frequently Asked Questionsより引用。

Why doesn't Rust have increment and decrement operators?
Preincrement and postincrement (and the decrement equivalents), while convenient, are also fairly complex. They require knowledge of evaluation order, and often lead to subtle bugs and undefined behavior in C and C++. x = x + 1 or x += 1 is only slightly longer, but unambiguous.

GitHub - dtolnay/rust-faq: Frequently Asked Questions · The Rust Programming Language

Rust言語において前置インクリメント++iと等価な式は{ i += 1; i }と記述できる*4。複合代入演算子(+=など)のオペランド評価順はオペランド型に依存して評価順序が変化することに注意*5。両オペランドともプリミティブ型の場合は「右辺→左辺」順で評価が行われる。Here Be Dragons/Hic Sunt Dracones🐉

{ // Java/JavaScript/C#的な動作
  let mut i = 0;
  i = i + 1 + { i += 1; i };
  assert!(i == 2);
  // 部分式の評価順:
  //  i = i + 1 + { i += 1; i };
  // (6) (1) (2)   (4)  (3)(5)
}
{ // C/C++的な動作
  let mut i = 0;
  i += 1 + { i += 1; i };
  assert!(i == 3);
  // 部分式の評価順:
  //  i += 1 + { i += 1; i };
  // (5)  (1)   (3)  (2)(4)
}

Rust言語リファレンスより一部引用（下線部は強調）。

Evaluation order of operands
The following list of expressions all evaluate their operands the same way, as described after the list. Other expressions either don’t take operands or evaluate them conditionally as described on their respective pages.

• (snip)
• Arithmetic and logical binary operators
• (snip)

The operands of these expressions are evaluated prior to applying the effects of the expression. Expressions taking multiple operands are evaluated left to right as written in the source code.

Note: Which subexpressions are the operands of an expression is determined by expression precedence as per the previous section.

For example, the two next method calls will always be called in the same order:

let mut one_two = vec![1, 2].into_iter();
assert_eq!(
    (1, 2),
    (one_two.next().unwrap(), one_two.next().unwrap())
);

Note: Since this is applied recursively, these expressions are also evaluated from innermost to outermost, ignoring siblings until there are no inner subexpressions.

https://doc.rust-lang.org/reference/expressions.html#evaluation-order-of-operands

Compound assignment expressions
(snip)
Evaluation of compound assignment expressions depends on the types of the operators.

If both types are primitives, then the modifying operand will be evaluated first followed by the assigned operand. It will then set the value of the assigned operand's place to the value of performing the operation of the operator with the values of the assigned operand and modifying operand.

Note: This is different than other expressions in that the right operand is evaluated before the left one.

Otherwise, this expression is syntactic sugar for calling the function of the overloading compound assignment trait of the operator (see the table earlier in this chapter). A mutable borrow of the assigned operand is automatically taken.

(snip)

Like assignment expressions, compound assignment expressions always produce the unit value.

⚠️Warning: The evaluation order of operands swaps depending on the types of the operands: with primitive types the right-hand side will get evaluated first, while with non-primitive types the left-hand side will get evaluated first. Try not to write code that depends on the evaluation order of operands in compound assignment expressions. See this test for an example of using this dependency.

https://doc.rust-lang.org/reference/expressions/operator-expr.html#compound-assignment-expressions

関連URL

• Rust expression order of evaluation - language design - Rust Internals
• Document execution order by Havvy · Pull Request #888 · rust-lang/reference · GitHub
• i += 1 + ++i; の処理結果（C／C++編） - yohhoyの日記
• i += 1 + ++i; の処理結果（Java／JavaScript／C#編） - yohhoyの日記
• Go言語の++/--は文(Statement) - yohhoyの日記
• https://twitter.com/dragosr/status/1802904803841860039

*1:https://go.dev/ref/spec#Assignment

*2:https://go.dev/talks/2015/simplicity-is-complicated.slide#4

*3:当然ながら、Rust言語ではデクリメント演算子 -- も提供されない。

*4:Rust言語では加算代入 i += 1 の評価結果はユニット値(unit value)となり、0 + (i += 1) のような式は型不整合によるコンパイルエラーとなる。

*5:代入演算子オーバーロード機能を提供するC++にも同様のオペランド評価順問題があり、C++17以降では「ユーザ型向けにオーバーロードされていても、プリミティブ型に対するオペランド評価順と統一する」規則を追加導入している。

i += 1 + ++i; の処理結果（C／C++編）

異なるプログラミング言語における式i += 1 + ++i処理結果の違いについてメモ。

警告：1つの式内で同一変数を複数回更新する技巧的なコード記述は避けてください。DO NOT WRITE THIS ON PRODUCTION CODE.

sequenced-before関係ルールを覚えてまで際どいコードを書くほど人生は長くないはず。

i = i++ + 1;の評価順規定 - yohhoyの日記

int i = 0; // Java,C#,C++,C
// let i = 0; // JavaScript

i += 1 + ++i;
// 変数 i の値は？

まとめ：整数型の変数iが値0で初期化さているとき、下記プログラミング言語における処理結果は次の通り。

• Java：値2（→id:yohhoy:20241124）
• JavaScript：値2（→id:yohhoy:20241124）
• C#：値2（→id:yohhoy:20241124）
• C：未定義動作(undefined behavior)
• C++
  • C++14まで：未定義動作(undefined behavior)
  • C++17以降：値3

複合代入演算子+=の左辺変数i値を “どのタイミングで読み取るか” により結果が異なる。C言語（C23現在）とC++14までは未定義動作(undefined behavior)となるが、C++17以降では順序規定の追加によって結果が保証されるようになる。こんなコードはダメ。ゼッタイ。

C90/99

式文末尾が副作用完了点(sequence point)と規定され、そこまでの間に複合代入(i += ...)および前置インクリメント(++i)により同一変数iに対する更新操作(modify)が複数回生じるため、未定義動作(undefined behavior)を引き起こす。C++98/03動作と同じ。

C99 6.5/p2, 6.5.16/p4, 6.8/p4より一部引用（下線部は強調）。

2 Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.

4 The order of evaluation of the operands is unspecified. If an attempt is made to modify the result of an assignment operator or to access it after the next sequence point, the behavior is undefined.

4 A full expression is an expression that is not part of another expression or of a declarator. Each of the following is a full expression: an initializer; the expression in an expression statement; (snip) The end of a full expression is a sequence point.

C11/17/23

複合代入演算子+=の左オペランド(i)における値の計算(value computation)と、右オペランドに含まれる前置インクリメント(++i)の副作用(side effect)が unsequenced 関係にあるため、式は未定義動作(undefined behavior)を引き起こす。C++11/14動作と同じ。

C23 6.5.1/p2-3、6.5.17.1/p3より引用（下線部は強調）。*1

2 If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.
3 The grouping of operators and operands is indicated by the syntax. Except as specified later, side effects and value computations of subexpressions are unsequenced.

3 An assignment operator stores a value in the object designated by the left operand. An assignment expression has the value of the left operand after the assignment, but is not an lvalue. The type of an assignment expression is the type the left operand would have after lvalue conversion. The side effect of updating the stored value of the left operand is sequenced after the value computations of the left and right operands. The evaluations of the operands are unsequenced.

C++98/03

式文末尾が副作用完了点(sequence point)と規定され、そこまでの間に複合代入(i += ...)および前置インクリメント(++i)により同一変数iに対する更新操作(modify)が複数回生じるため、未定義動作(undefined behavior)を引き起こす。C90/99動作と同じ。

C++03＋CWG351 1.9/p12, p16, 5/p4より引用（下線部は強調）。

12 A full-expression is an expression that is not a subexpression of another expression. If a language construct is defined to produce an implicit call of a function, a use of the language construct is considered to be an expression for the purposes of this definition.

16 There is a sequence point at the completion of evaluation of each full-expression.

4 Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified. Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined. [Example:

i = v[i++];       // the behavior is unspecified
i = 7, i++, i++;  // i becomes 9

i = ++i + 1;      // the behavior is undefined
i = i + 1;        // the value of i is incremented

-- end example]

C++11/14

複合代入演算子+=の左オペランド(i)における値の計算(value computation)と、右オペランドに含まれる前置インクリメント(++i)の副作用(side effect)が unsequenced 関係にあるため、式は未定義動作(undefined behavior)を引き起こす。C11/17/23動作と同じ。

C++14 1.9/p15, 5.17/p1より一部引用（下線部は強調）。

15 Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced. [Note: In an expression that is evaluated more than once during the execution of a program, unsequenced and indeterminately sequenced evaluations of its subexpressions need not be performed consistently in different evaluations. -- end note] The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. If a side effect on a scalar object is unsequenced relative to either another side effect on the same scalar object or a value computation using the value of the same scalar object, and they are not potentially concurrent (1.10), the behavior is undefined. (snip)

1 The assignment operator (=) and the compound assignment operators all group right-to-left. All require a modifiable lvalue as their left operand and return an lvalue referring to the left operand. The result in all cases is a bit-field if the left operand is a bit-field. In all cases, the assignment is sequenced after the value computation of the right and left operands, and before the value computation of the assignment expression. With respect to an indeterminately-sequenced function call, the operation of a compound assignment is a single evaluation. (snip)

C++17/20/23

C++11/14の規定に加えて、複合代入演算子+=の右オペランド(1 + ++i)は左オペランド(i)より前に順序付けられる(sequenced before)ため、下記順序で評価が行われ変数iは値3となる。

1. 複合代入演算子+=右辺(1 + ++i)を評価し、値2をえる。
   1. 加算演算子+左辺(1)の値を計算(value computation)し、値1をえる。手順1.2とは順不同。
   2. 加算演算子+右辺(++i)を評価し、値1をえる。手順1.1とは順不同。
      1. 前置インクリメント++オペランド(i)の値を計算(value computation)し、値0をえる。
      2. 前置インクリメントの値を計算(value computation)し、手順1.2.1評価結果から0 + 1→値1をえる。
      3. 前置インクリメントの副作用(side effect)として、変数iに値1を代入する。
   3. 加算の値の計算(value computation)として、手順1.1〜1.2評価結果から1 + 1→値2をえる。
2. 複合代入演算子+=左辺(i)の値を計算(value computation)し、値1をえる。
3. 複合代入の値の計算(value computation)として、手順1〜2評価結果から1 + 2→値3をえる。
4. 複合代入の副作用(side effect)として、変数iに値3を代入する。

C++23 7.6.19/p1より一部引用（下線部は強調）。

1 The assignment operator (=) and the compound assignment operators all group right-to-left. All require a modifiable lvalue as their left operand; their result is an lvalue of the type of the left operand, referring to the left operand. The result in all cases is a bit-field if the left operand is a bit-field. In all cases, the assignment is sequenced after the value computation of the right and left operands, and before the value computation of the assignment expression. The right operand is sequenced before the left operand. With respect to an indeterminately-sequenced function call, the operation of a compound assignment is a single evaluation. (snip)

関連URL

• JPCERT CC, EXP30-C. 副作用が発生する式の評価順序に依存しない
• cpprefjp 厳密な式の評価順
• XOR swap今昔物語: sequence pointからsequenced-beforeへの変遷
• i = i++ + 1;の評価順規定 - yohhoyの日記
• 厳格な式の評価順序 for C2y - yohhoyの日記
• https://twitter.com/yohhoy/status/1822820499044585656

*1:C23 5.1.2.4/p2: "Evaluation of an expression in general includes both value computations and initiation of side effects."

i += 1 + ++i; の処理結果（Java／JavaScript／C#編）

異なるプログラミング言語における式i += 1 + ++i処理結果の違いについてメモ。*1

警告：1つの式内で同一変数を複数回更新する技巧的なコード記述は避けてください。こんな式を書くもんじゃねぇよ言語仕様書の紙束で張っ倒すぞ(#ﾉﾟДﾟ)ㇸ📘 ...取り乱しました。

int i = 0; // Java,C#,C++,C
// let i = 0; // JavaScript

i += 1 + ++i;
// 変数 i の値は？

まとめ：整数型の変数iが値0で初期化さているとき、下記プログラミング言語における処理結果は次の通り。

• Java：値2
• JavaScript：値2
• C#：値2
• C：未定義動作(undefined behavior)（→id:yohhoy:20241125）
• C++（→id:yohhoy:20241125）
  • C++14まで：未定義動作(undefined behavior)
  • C++17以降：値3

複合代入演算子+=の左辺変数i値を “どのタイミングで読み取るか” により結果が異なる。Java／JavaScript／C#ではi = i + (1 + ++i)相当と解釈され、いずれも値2が言語仕様により保証された結果である。*2

Java

式i += 1 + ++iは下記順序で評価され、最終的に変数iは値2となる。

1. 複合代入演算子+=左辺(変数i)の値0を保存しておく(★L)。
2. 複合代入演算子+=右辺(1 + ++i)を評価し、値2をえる(★R)。
   1. 加算演算子+左辺(1)を評価し、値1をえる。
   2. 加算演算子+右辺(++i)を評価し、変数iの値を0→1に更新したのち、値1をえる。
   3. 部分式(1 + ++i)の評価結果として、1 + 1より値2をえる。
3. 複合代入演算子+=の計算プロセスとして、手順1:保存した左辺の値(★L)と手順2:右辺の評価結果(★R)に対して加算操作(+)を適用し、値2をえる。
4. 手順3の評価結果2を、複合代入演算子+=左辺(変数i)に代入する。

複合代入演算子の評価プロセスについて、Java Language Specification(JLS) Java SE 23 Edition, 15.26.2より一部引用（下線部は強調）。*3

A compound assignment expression of the form E1 op= E2 is equivalent to E1 = (T) ((E1) op (E2)), where T is the type of E1, except that E1 is evaluated only once.
(snip)
At run time, the expression is evaluated in one of two ways.

If the left-hand operand expression is not an array access expression, then:

• First, the left-hand operand is evaluated to produce a variable. If this evaluation completes abruptly, then the assignment expression completes abruptly for the same reason; the right-hand operand is not evaluated and no assignment occurs.
• Otherwise, the value of the left-hand operand is saved and then the right-hand operand is evaluated. If this evaluation completes abruptly, then the assignment expression completes abruptly for the same reason and no assignment occurs.
• Otherwise, the saved value of the left-hand variable and the value of the right-hand operand are used to perform the binary operation indicated by the compound assignment operator. If this operation completes abruptly, then the assignment expression completes abruptly for the same reason and no assignment occurs.
• Otherwise, the result of the binary operation is converted to the type of the left-hand variable, and the result of the conversion is stored into the variable.

JLS 23, 15.26.2 Compound Assignment Operators

JavaScript

式i += 1 + ++iは下記順序で評価され、最終的に変数iは値2となる。

1. 複合代入演算子+=左辺(変数i)の値0を保存しておく(lval)。
2. 複合代入演算子+=右辺(1 + ++i)を評価し、値2をえる(rval)。
   1. 加算演算子+左辺(1)を評価し、値1をえる。
   2. 加算演算子+右辺(++i)を評価し、変数iの値を0→1に更新したのち、値1をえる。
   3. 部分式(1 + ++i)の評価結果として、1 + 1より値2をえる。
3. 複合代入演算子+=の計算プロセスとして、保存した左辺の値(lval)と右辺の評価結果(rval)に対して加算操作(+)を適用し、値2をえる(r)。
4. 手順3の評価結果2(r)を、複合代入演算子+=左辺(変数i; lref)に代入する。

複合代入演算子の評価プロセスについて、ECMAScript 2024 Language Specification 15th edition, 13.15.2より一部引用。*4

AssignmentExpression : LeftHandSideExpression AssignmentOperator AssignmentExpression

1. Let lref be ? Evaluation of LeftHandSideExpression.
2. Let lval be ? GetValue(lref).
3. Let rref be ? Evaluation of AssignmentExpression.
4. Let rval be ? GetValue(rref).
5. Let assignmentOpText be the source text matched by AssignmentOperator.
6. Let opText be the sequence of Unicode code points associated with assignmentOpText in the following table:
   • assignmentOpText += ／ opText +
   • (snip)
7. Let r be ? ApplyStringOrNumericBinaryOperator(lval, opText, rval).
8. Perform ? PutValue(lref, r).
9. Return r.

ECMAScript 2024 Language Specification, 13.15.2 Runtime Semantics: Evaluation

C#

式i += 1 + ++iは式i = i + (1 + ++i)として下記順序で評価され、最終的に変数iは値2となる。

1. 複合代入演算子+=左辺(変数i)を評価し、値0をえる。
2. 加算演算子+左辺(1)を評価し、値1をえる。
3. 加算演算子+右辺(++i)を評価し、変数iの値を0→1に更新したのち、値1をえる。
4. 手順1〜3評価結果から0 + (1 + 1)→値2を算出し、複合代入演算子+=左辺(変数i)に代入する。

演算子オペランドの評価順序および複合代入演算子の評価プロセスについて、ECMA-334 6th edition*5, 11.4.1, 11.18.2, 11.18.3より一部引用。

11.4 Operators
11.4.1 General
Expressions are constructed from operands and operators. The operators of an expression indicate which operations to apply to the operands.

(snip)

The order of evaluation of operators in an expression is determined by the precedence and associativity of the operators (§11.4.2).

Operands in an expression are evaluated from left to right.

Example: In F(i) + G(i++) * H(i), method F is called using the old value of i, then method G is called with the old value of i, and, finally, method H is called with the new value of i. This is separate from and unrelated to operator precedence. end example

11.18.2 Simple assignment
The run-time processing of a simple assignment of the form x = y consists of the following steps:

• If x is classified as a variable:
  • x is evaluated to produce the variable.
  • y is evaluated and, if required, converted to the type of x through an implicit conversion (§10.2).
  • If the variable given by x is an array element of a reference_type, (snip)
  • The value resulting from the evaluation and conversion of y is stored into the location given by the evaluation of x.
• (snip)

11.18.3 Compound assignment

An operation of the form x «op»= y is processed by applying binary operator overload resolution (§11.4.5) as if the operation was written x «op» y. Then,

• If the return type of the selected operator is implicitly convertible to the type of x, the operation is evaluated as x = x «op» y, except that x is evaluated only once.
• (snip)

The term "evaluated only once" means that in the evaluation of x «op» y, the results of any constituent expressions of x are temporarily saved and then reused when performing the assignment to x.

関連URL

• i = i++ + 1;の評価順規定 - yohhoyの日記

*1:謝辞：本記事は https://twitter.com/YojoPaisen/status/1859465566324654494 および https://twitter.com/it_muitenai/status/1859163754644083193 経由で頂いた情報をベースにしています。

*2:JavaおよびJavaScript(ECMAScript)言語仕様の解釈には曖昧さが無い。一方でC#言語の仕様記述は曖昧さが残るため、本文中の仕様解釈に多少の疑念がないわけでもない。これ以外の解釈とする必然性もないし、たぶん合ってるんじゃない？

*3:JLS 同セクションの Example 15.26.2-2. Value Of Left-Hand Side Of Compound Assignment Is Saved Before Evaluation Of Right-Hand Side にて本記事との類似ケースが例示説明されている。

*4:ECMAScript言語仕様のRuntime Semantics記述に頻出する ? 記号は、仮想操作ReturnIfAbrupt適用を表す略記用プレフィクス(prefix)である。本記事においては例外を扱わないため、単に無視してもよい。詳細は§5.2.3.4 ReturnIfAbrupt Shorthands参照のこと。

*5:https://ecma-international.org/wp-content/uploads/ECMA-334_6th_edition_june_2022.pdf

std::monostate as a Unit Type

C++標準ライブラリで提供されるstd::monostateは、単一値しか持たない ユニット型(Unit type) としても利用できる。*1

2024-11-29追記：C++2c(C++26)に向けて提案文書(PDF)P0472R3が採択され、ヘッダ<utility>にも汎用部品としてstd::monostateが追加される。*2

std::monostateはデフォルト構築可能でコピー操作や比較演算全般をサポートする正則な(regular)型であり*3、クラステンプレート特殊化を必要とするvoid型よりも自然に「情報を持たない」ことを表現できる。*4

#include <concepts>
#include <variant>

static_assert(std::regular<std::monostate>);
static_assert(not std::regular<void>);  // voidは非正則

関連URL

• (PDF)P0472R2 Put std::monostate in <utility>
• Why is C++'s void type only half-heartedly a unit type? - Stack Overflow
• cppreference std::regular, cpprefjp std::regular
• std::monostateのハッシュ値 - yohhoyの日記

*1:C++17以降のヘッダ<variant>中にて定義され、本来は std::variant<std::monostate, Types...> のように空(empty)ステートを表現するためのクラス。

*2:https://github.com/cplusplus/papers/issues/1993

*3:ある型が正則(regular)となるには、==, != 演算子による等値比較のみ可能であればよい。std::monostate は等値比較以外にも大小比較やハッシュ演算をサポートする。

*4:例：std::future<T> は結果型を持たない std::future<void> 特殊化を提供する。