same_asコンセプトとSymmetric Subsumption Idiom

C++2a(C++20)ライブラリ提供の標準コンセプトstd::same_as、およびコンセプト定義における対称包摂イディオム(Symmetric Subsumption Idiom)についてメモ。

制約式std::same_as<X, Y>と制約式std::same_as<Y, X>は対称関係、つまり互いに一方が他方を包摂する(subsume)関係にある。これによりコンセプトへのテンプレートパラメータ指定順が一致していなくとも、制約式を用いた関数オーバーロード解決の半順序関係を表現できる。

// C++2a(C++20)
#include <concepts>

template <typename X, typename Y>
  requires std::same_as<X, Y>
constexpr int f() { return 1; }  // #1

template <typename X, typename Y>
  requires std::same_as<Y, X> && (1 < sizeof(X))
constexpr int f() { return 2; }  // #2

f<int, int>();  // OK: #2を呼び出す

もしsame_asコンセプトがこのような対称性をもたない場合、関数オーバーロード解決は曖昧になり上記コードはill-formedとなってしまう。*1

C++2a標準ライブラリ

標準コンセプトsame_as<T,U>の定義では動作説明用(exposition only)のコンセプトsame-as-implを用いて、型パラメータT, Uに対象関係が成り立つようにしている。ここではC++2a言語仕様上、メタ関数is_same_vの直接記述ではなくコンセプトsame-as-impl経由が必須となる。（詳細後述）
N4830*2 14.8.2より引用。

template<class T, class U>
  concept same-as-impl = is_same_v<T, U>;  // exposition only

template<class T, class U>
  concept same_as = same-as-impl<T, U> && same-as-impl<U, T>;

1 [Note: same_as<T, U> subsumes same_as<U, T> and vice versa. -- end note]

当初はナイーブな定義とNoteによる動作説明になっており、パラメータの対称性を実現にはコンパイラマジックが必要であった。LWG3182によりライブラリ定義のみで対称性が実現されるよう修正された経緯がある（下線部は強調）。*3

The specification of the Same concept in 18.4.2 [concept.same]:

template<class T, class U>
  concept Same = is_same_v<T, U>;

-1- Same<T, U> subsumes Same<U, T> and vice versa.

seems contradictory. From the concept definition alone, it is not the case that Same<T, U> subsumes Same<U, T> nor vice versa. Paragraph 1 is trying to tell us that there's some magic that provides the stated subsumption relationship, but to a casual reader it appears to be a misannotated note. We should either add a note to explain what's actually happening here, or define the concept in such a way that it naturally provides the specified subsumption relationship.

Given that there's a straightforward library implementation of the symmetric subsumption idiom, the latter option seems preferable.

コンセプト利用

コンセプトsame_as定義にコンセプトsame-as-implを利用するとき、2つの制約式[A]same_as<X, Y>, [B]same_as<Y, X>の関係は次のように説明できる。

template<class T, class U>
  concept same-as-impl = is_same_v<T, U>/*#0*/;

template<class T, class U>
  concept same_as = same-as-impl<T, U> && same-as-impl<U, T>;

それぞれの制約式を正規化(normalization)すると、原子制約(atomic constraint)導出時のパラメータマッピング(parameter mapping)を ↦ 表記して、次の正規形(normal form)が得られる：

• [A]same_as<X, Y>の正規形は is_same_v<T↦X, U↦Y>#0 ∧ is_same_v<T↦Y, U↦X>#0
• [B]same_as<Y, X>の正規形は is_same_v<T↦Y, U↦X>#0 ∧ is_same_v<T↦X, U↦Y>#0

制約P=[A]same_as<X, Y>, 制約Q=[B]same_as<Y, X>とおくと、PのDNF(選言標準形; disjunctive normal form)およびQのCNF(連言標準形; conjunctive normal form)の各項は次の通り：

• P₁=(is_same_v<T↦X, U↦Y>#0 ∧ is_same_v<T↦Y, U↦X>#0)
• Q₁=is_same_v<T↦Y, U↦X>#0, Q₂=is_same_v<T↦X, U↦Y>#0

項P₁は2つの原子制約 P_1,1=is_same_v<T↦X, U↦Y>#0, P_1,2=is_same_v<T↦Y, U↦X>#0からなり、QのCNF項に含まれる原始制約Q_j,bに対して同一(identical; ≡ 表記)な原子制約P_i,aが存在する：

• 原子制約Q_1,1=is_same_v<T↦Y, U↦X>#0 ≡ 原子制約P_1,2=is_same_v<T↦Y, U↦X>#0 つまり “項P₁ subsumes 項Q₁”
• 原子制約Q_2,1=is_same_v<T↦X, U↦Y>#0 ≡ 原子制約P_1,1=is_same_v<T↦X, U↦Y>#0 つまり “項P₁ subsumes 項Q₂

以上より、制約Pの全てのDNF項(P₁)は制約Qの全てのCNF項(Q₁, Q₂)を包摂する、つまり “[A]same_as<X, Y> subsumes [B]same_as<Y, X>” が導出される。

制約P, Qを入れ替えると、同様に対称な関係 “[B]same_as<Y, X> subsumes [A]same_as<X, Y>” が導出される。

メタ関数利用

コンセプトsame_as定義にメタ関数is_same_vを直接利用したとき、2つの制約式[A]same_as<X, Y>, [B]same_as<Y, X>の関係は次のように説明できる。

template<class T, class U>
  concept same_as = is_same_v<T, U>/*#1*/ && is_same_v<U, T>/*#2*/;

それぞれの制約式を正規化すると、次の正規形が得られる：

• [A]same_as<X, Y>の正規形は is_same_v<T↦X, U↦Y>#1 ∧ is_same_v<U↦Y, T↦X>#2
• [B]same_as<Y, X>の正規形は is_same_v<T↦Y, U↦X>#1 ∧ is_same_v<U↦X, T↦Y>#2

制約P=[A]same_as<X, Y>, 制約Q=[B]same_as<Y, X>とおくと、PのDNFおよびQのCNFの各項は次の通り：

• P₁=(is_same_v<T↦X, U↦Y>#1 ∧ is_same_v<U↦Y, T↦X>#2)
• Q₁=is_same_v<T↦Y, U↦X>#1, Q₂=is_same_v<U↦X, T↦Y>#2

項P₁は2つの原子制約 P_1,1=is_same_v<T↦X, U↦Y>#1, P_1,2=is_same_v<U↦Y, T↦X>#2からなるが、QのCNF項に含まれる原始制約Q_1,1やQ_2,1と “同じ式(the same expression)” かつ “同等のパラメータマッピング” をもつ原子制約が無い、つまりいずれの原子制約Q_j,bに対しても同一(identical)な原子制約P_i,aは存在しない。*4

つまり[A]same_as<X, Y>は[B]same_as<Y, X>を包摂しない。制約P, Qを入れ替えても同様に包摂関係は成り立たない。

関連URL

• コンセプト制約式の包摂関係とオーバーロード解決 - yohhoyの日記
• https://gist.github.com/yohhoy/a96021f1e0415d06bb8d4bd8eab94aec

*1:C++言語仕様を厳格に解釈すると 1 == sizeof(int) となる処理系が存在しうるため、該当コードでオーバーロード#1が選択される可能性もある。本記事ではそのような処理系の存在は無視する。

*2:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4830.pdf

*3:N4820以前のコンセプト名は Same とされていたが、(PDF)P1754R1採択によって same_as へと改名された。詳細はC++標準コンセプトの名前付けガイドラインを参照。

*4:N4830 13.4.1.2/p2: "Two atomic constraints are identical if they are formed from the same expression and the targets of the parameter mappings are equivalent according to the rules for expressions described in 13.6.6.1."

20分くらいでわかった気分になれるC++20コルーチン

20分くらいでわかった気分になれるC++20コルーチン

本文こちら→C++ MIX #5に参加しました - yohhoyの日記（別館）

スライド資料：https://www.slideshare.net/yohhoy/20c20

関連URL

• C++コルーチン拡張メモ（N4736） - yohhoyの日記
• C++コルーチン拡張メモ - Qiita

コンセプト制約式の包摂関係とオーバーロード解決

C++2a(C++20)で導入されるコンセプト(concept)に関して、制約式(constraint-expression)間の包摂(subsume)ルールに基づくオーバーロード解決のメモ。

本記事の内容はStackOverflowで見つけた質問と回答に基づく。

要約：制約式の包摂関係(subsumption relation)判定では、制約を構成するトークン列が同じというだけではダメで、C++ソースコード上での記述位置（＝構文木におけるノード）の同一性が考慮される。こんなん分かる気がしない_(:3｣∠)_

制約式を指定した2つの関数オーバーロード定義において、コンセプト名とテンプレート名では制約式の包摂関係の判断規則が異なるため、★箇所におけるオーバーロード解決の振る舞いが変化する。

// C++2a(N4830)
#if コンセプト
template <typename T> concept C1 = true;  // #1
template <typename T> concept C2 = true;  // #2
#elif 変数テンプレート
template <typename T> inline constexpr bool C1 = true;
template <typename T> inline constexpr bool C2 = true;
#endif

// [A] 制約式C1<T> && C2<T>
template <typename T>
  requires C1<T> && C2<T>  // #3
constexpr int foo() { return 0; }

// [B] 制約式C1<T>
template <typename T>
  requires C1<T>           // #4
constexpr int foo() { return 1; }

foo<int>();  // ★ [A]/[B] or...?

C1, C2がコンセプト名の場合

制約式C1<T> && C2<T>は制約式C1<T>を包摂する(subsume)ため、より強く制約された(more constrained) 関数[A] が選択される。正規化(normalization)によって前者はtrue#1∧true#2に、後者はtrue#1となる。このとき原子制約(atomic constraint) true#1は “同一の式(the same expression)” から構成されるため、C1<T> && C2<T> subsume C1<T>という包摂関係が成立する。

C1, C2が非コンセプト名（テンプレート）の場合

制約式C1<T> && C2<T>と制約式C1<T>は互いに包摂関係になく、関数呼び出しのオーバーロード解決は曖昧となるためプログラムはill-formed。正規化(normalization)によって前者はC1<T>#3∧C2<T>#3に、後者はC1<T>#4となる。このとき原子制約C1<T>#3とC1<T>#4は “同一の式(the same expression)” からは構成されておらず、無関係な制約式として解釈される。

原子制約の同一性(identical)判定基準は、Concepts TS時点の (PDF)P0717R1 Semantic constraint matching for concepts にて次のように説明される（下線部は強調）。

Equivalence during partial ordering
We propose to use a different model for determining whether two atomic constraints are equivalent. Tersely, we can describe this as follows: two atomic constraints are equivalent only if they originate from the same source-level construct.

メモ：C++20標準ライブラリ提供のコンセプト実装にて exposition only なコンセプトを多用しているのは、そのコンセプト名から期待される包摂関係が成り立つよう考慮した結果と思われる。

2019-09-11追記：P0717R1を実装したVisual Studio 2019 16.3 Preview 2で動作確認を行ったところ、上記解釈通りの実行結果「コンセプト名では[A]を選択／非コンセプト名ではオーバーロード解決が曖昧」が得られた。後者のエラー出力は下記の通り：

error C2668: 'foo': ambiguous call to overloaded function
message : could be 'int foo<int>(void)'
message : or       'int foo<int>(void)'
message : while trying to match the argument list '()'

2019-10-17追記：GCC 10.0.0 20191015(experimental)でも上記解釈通り動作することを確認。後者のエラー出力は下記の通り：

In function 'int main()':
error: call of overloaded 'f<int, int>()' is ambiguous
  |   return f<int, int>();
  |                      ^
note: candidate: 'constexpr int f() [with T = int; U = int]'
  | constexpr int f() { return 1; }  // #1
  |               ^
note: candidate: 'constexpr int f() [with T = int; U = int]'
  | constexpr int f() { return 2; }  // #2
  |               ^

C++2a言語仕様

N4830*1(C++2a WD) 13.4.1.2/p1-2, 13.4.3/p1-2, 13.4.4/p1-4, 13.6.6.2/p2より一部引用（下線部は強調）。

1 An atomic constraint is formed from an expression E and a mapping from the template parameters that appear within E to template arguments involving the template parameters of the constrained entity, called the parameter mapping (13.4.2). [Note: Atomic constraints are formed by constraint normalization (13.4.3). E is never a logical AND expression (7.6.14) nor a logical OR expression (7.6.15). -- end note]
2 Two atomic constraints are identical if they are formed from the same expression and the targets of the parameter mappings are equivalent according to the rules for expressions described in 13.6.6.1.

1 The normal form of an expression E is a constraint (13.4.1) that is defined as follows:

• The normal form of an expression ( E ) is the normal form of E.
• The normal form of an expression E1 || E2 is the disjunction (13.4.1.1) of the normal forms of E1 and E2.
• The normal form of an expression E1 && E2 is the conjunction of the normal forms of E1 and E2.
• The normal form of an id-expression of the form C<A1, A2, ..., An>, where C names a concept, is the normal form of the constraint-expression of C, after substituting A1, A2, ..., An for C's respective template parameters in the parameter mappings in each atomic constraint. (snip)
• The normal form of any other expression E is the atomic constraint whose expression is E and whose parameter mapping is the identity mapping.

2 The process of obtaining the normal form of a constraint-expression is called normalization. [Note: Normalization of constraint-expressions is performed when determining the associated constraints (13.4.1) of a declaration and when evaluating the value of an id-expression that names a concept specialization (7.5.4). -- end note]

1 A constraint P subsumes a constraint Q if and only if, for every disjunctive clause P_i in the disjunctive normal form¹³² of P, P_i subsumes every conjunctive clause Q_j in the conjunctive normal form¹³³ of Q, where

• a disjunctive clause P_i subsumes a conjunctive clause Q_j if and only if there exists an atomic constraint P_ia in P_i for which there exists an atomic constraint Q_jb in Q_j such that P_ia subsumes Q_jb, and
• an atomic constraint A subsumes another atomic constraint B if and only if the A and B are identical using the rules described in 13.4.1.2.

[Example: Let A and B be atomic constraints (13.4.1.2). The constraint A ∧ B subsumes A, but A does not subsume A ∧ B. The constraint A subsumes A ∨ B, but A ∨ B does not subsume A. Also note that every constraint subsumes itself. -- end example]
脚注132) A constraint is in disjunctive normal form when it is a disjunction of clauses where each clause is a conjunction of atomic constraints. (snip)
脚注133) A constraint is in conjunctive normal form when it is a conjunction of clauses where each clause is a disjunction of atomic constraints. (snip)

2 [Note: The subsumption relation defines a partial ordering on constraints. This partial ordering is used to determine

• (snip)
• the partial ordering of function templates (13.6.6.2).

-- end note]
3 A declaration D1 is at least as constrained as a declaration D2 if

• D1 and D2 are both constrained declarations and D1's associated constraints subsume those of D2; or
• D2 has no associated constraints.

4 A declaration D1 is more constrained than another declaration D2 when D1 is at least as constrained as D2, and D2 is not at least as constrained as D1. (snip)

2 Partial ordering selects which of two function templates is more specialized than the other by transforming each template in turn (see next paragraph) and performing template argument deduction using the function type. The deduction process determines whether one of the templates is more specialized than the other. If so, the more specialized template is the one chosen by the partial ordering process. If both deductions succeed, the partial ordering selects the more constrained template as described by the rules in 13.4.4.

§13.4.1.2 [temp.constr.atomic]/p2 で言及される "the same expression" の解釈については、https://github.com/cplusplus/draft/issues/2554 が挙げられている。より明確化されたWordingへと変更されるかも。

2020-01-22追記：C++2a WD (PDF)N4842にて構文規則のフォントが変更され*2、言語仕様から本来の意図を読み取りやすくなった。

関連URL

• c++ - Understanding what atomic constraints are - Stack Overflow
• 制約とコンセプトとオーバーロードと半順序 - Qiita
• C++ Concepts（P0734R0） - yohhoyの日記

*1:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4830.pdf

*2:N4843 Editors' Report: "The typeface used for grammar productions has been changed from italic to a slanted sans-serif font in order to distinguish grammar productions from defined terms."

va_argマクロの奇妙な制限事項

C言語の可変引数リストアクセス用 va_arg マクロにおける奇妙な制限事項についてメモ。

va_argマクロの第二引数へ指定する型名には、“関数ポインタ型” や “配列へのポインタ型” を直接記述できない。ただしtypedefによる別名であればOK。こんなコード書くやつおらんやろ

#include <stdarg.h>

void f0(int x, ...)
{
  va_list ap;
  va_start(ap, x);
  // NG: 関数ポインタ型 int(*)(int) は直接指定できない
  int (*pf)(int) = va_arg(ap, int(*)(int));
  // NG: 配列へのポインタ型 int(*)[N] は直接指定できない
  int (*pa)[3] = va_arg(ap, int(*)[3]);
  va_end(ap);
}

void f1(int x, ...)
{
  typedef int (*PF)(int), (*PA)[3];
  va_list ap;
  va_start(ap, x);
  // OK: typdefされた別名 PF ならば指定可能
  PF pf = va_arg(ap, PF);
  // OK: typdefされた別名 PA ならば指定可能
  PA pa = va_arg(ap, PA);
  va_end(ap);
}

int h(int n);
int a[3];
f0(0, &h, &a);
f1(0, &h, &a);

C99 7.15.1.1 p1-2より一部引用（下線部は強調）。

#include <stdarg.h>
type va_arg(va_list ap, type);

The va_arg macro expands to an expression that has the specified type and the value of the next argument in the call. (snip) The parameter type shall be a type name specified such that the type of a pointer to an object that has the specified type can be obtained simply by postfixing a * to type. If there is no actual next argument, or if type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), the behavior is undefined, except for the following cases:

• one type is a signed integer type, the other type is the corresponding unsigned integer type, and the value is representable in both types;
• one type is pointer to void and the other is a pointer to a character type.

一見すると奇妙なこの制限は、va_argマクロの実装を考慮して設けられた。プリプロセッサでは単純なトークン列操作しか行えないため、型名に*を後置するだけで妥当なポインタ型名を生成できる必要がある。(PDF)C99 Rationale 7.15.1.1より引用（下線部は強調）。

7.15.1.1 The va_arg macro
Changing an arbitrary type name into a type name which is a pointer to that type could require sophisticated rewriting. To allow the implementation of va_arg as a macro, va_arg need only correctly handle those type names that can be transformed into the appropriate pointer type by appending a *, which handles most simple cases. Typedefs can be defined to reduce more complicated types to a tractable form. When using these macros, it is important to remember that the type of an argument in a variable argument list will never be an integer type smaller than int, nor will it ever be float (see §6.7.5.3).

va_arg can only be used to access the value of an argument, not to obtain its address.

例：古の GCC 2.95.3*1 では下記マクロ定義となっていた（読みやすさのため簡略化している）

#define va_arg(AP, TYPE)  \
  (AP = (va_list) ((char *) (AP) + __va_rounded_size(TYPE)),  \
   *((TYPE *) ((char *) (AP) - __va_rounded_size(TYPE))))

/* __va_rounded_size(T) := sizeof(T)をsizeof(int)の倍数に切り上げ */

GCC 3.0以降*2やLLVM/Clang*3では組み込み関数__builtin_va_argにより実装されるため、厳密に同制限を守らないコードでもコンパイルできてしまう。
VisualC++ 2017(MSVC 19.10)の場合、同制限に違反するコードは（一見すると不可解な）コンパイルエラーを引き起こすが、このMSVCの振る舞いはC言語仕様準拠といえる。

関連URL

• 可変引数リストと非PODクラス型の関係・改 - yohhoyの日記
• 可変引数リストと文字列とヌルポインタの特別な関係 - yohhoyの日記

*1:https://github.com/gcc-mirror/gcc/blob/releases/gcc-2.95.3/gcc/ginclude/stdarg.h#L105-L117

*2:https://github.com/gcc-mirror/gcc/blob/releases/gcc-3.0/gcc/ginclude/stdarg.h#L56

*3:https://github.com/llvm-mirror/clang/blob/release_26/lib/Headers/stdarg.h#L32

C++標準コンセプトの名前付けガイドライン

C++2a(C++20)標準ライブラリに導入される コンセプト(concept) の名前付けガイドラインについて。

2019年Cologne会合にて (PDF)P1754R1 が採択され、Ranges TS提案当初から PascalCase 形式で検討されていた命名規則から snake_case 形式へと変更された。これにより従来C++標準ライブラリとの一貫性は向上したが、その名前のみからはコンセプトなのかクラスやメタ関数*1なのかを判別しづらくなっている。*2

提案文書P1851R0では、P1754R1から改善した下記ガイドラインを提案している。

• コンセプト名は snake_case 形式とする。
• コンセプトを示す接頭辞(prefix)/接尾辞(suffix)は使わない。
• コンセプトの目的に応じた3つのカテゴリ：特性(Capabilities)、抽象(Abstrations)、その他の述語(predicate)
• 特性コンセプト(capability concept)：ある関数／メンバ関数呼び出しが可能といった単一要件で構成される。
  • 特性コンセプトの名前は、その要件を説明する形容詞(adjective)とする。
  • 要求する特性が関数のとき、そのコンセプト名には関数名に-ibleや-able接尾辞をつけたものとする。例：swap可能を要求するswappable, コピー構築可能を要求するcopy_constructible
• 抽象コンセプト(abstract concept)：複数要件から構成されたりコンセプト構成のルートにあたるハイレベル・コンセプト。
  • 抽象コンセプトの名前は、新しい専門用語(terminology)を導入する名詞(noun)とする。例：forward_iterator（要件を列挙しただけのhas_increment_equality_and_dereferenceはNG）
  • 抽象コンセプトの名前は、同コンセプトを満たす型の名前よりも総称的(general)であること。
• その他の述語コンセプト：下記に該当する場合は、型トレイツ(type traits)の命名規則に従う。ただしis_接頭辞はつけない。
  • 主に複数の型引数をとり型制約に利用されるときは、適切な前置詞(preposition)で終わる名前とする。例：swappable_with, same_as<int>, constructible_with<args>, sentinel_for<iterator>
  • 主に別コンセプトの定義やrequires節で利用されるときは、前置詞(preposition)は付けない。例：swappable, mergeable

関連URL

• P1810R0 A Quick Look at What P1754 Will Change
• C++ Concepts（P0734R0） - yohhoyの日記
• C++ Conceptsの短縮構文（P1141R2） - yohhoyの日記

*1:標準ヘッダ <type_traits> で提供される、ある型の特性(traits)をコンパイル時に判別するテンプレート関数群。

*2:P1754R1では変更根拠として、PascalCase はドメイン固有のエンティティ名として用いられるケースが多いことと、アプリケーションコードでの using namespace std; 利用によって生じる名前衝突回避を挙げている。

フライングWindows API待機関数

Windows APIのタイムアウト指定待機関数では、指定期間よりも僅かに早くタイムアウト発生する。この振る舞いは仕様通り(by design)とのこと。

• WaitForSingleObject, WaitForSingleObjectEx
• WaitForMultipleObjects, WaitForMultipleObjectsEx
• MsgWaitForMultipleObjects, MsgWaitForMultipleObjectsEx
• etc.

Windows OSのデフォルトタイマ割込間隔は 64 [Hz]＝15.625 [msec] となっているため、平均的に数ミリ秒だけ早くタイムアウトが発生しうる。

Wait Functions and Time-out Intervals
The accuracy of the specified time-out interval depends on the resolution of the system clock. The system clock "ticks" at a constant rate. If the time-out interval is less than the resolution of the system clock, the wait may time out in less than the specified length of time. If the time-out interval is greater than one tick but less than two, the wait can be anywhere between one and two ticks, and so on.

https://docs.microsoft.com/windows/win32/sync/wait-functions

関連URL

• (docx) Timers, Timer Resolution, and Development of Efficient Code
• http://www.windowstimestamp.com/
• https://github.com/yohhoy/yamc/pull/25

nan("is Not-a-Number")

プログラミング言語C/C++における浮動小数点数 NaN(Not-a-Number)*1 について。

C/C++標準ライブラリはquiet NaN*2を返すnan関数を提供し、同関数では処理系定義(implementation-defined)のタグ文字列を受け取る。一般的には空文字列""を指定するが、ライブラリ仕様上は任意の文字列*3を指定可能。

// C
#include <math.h>
double d1 = nan("42");   // OK
double d2 = nan("wtf");  // OK

// C++
#include <cmath>
double d1 = std::nan("42");   // OK
double d2 = std::nan("wtf");  // OK

IEC 60559浮動小数点型のバイナリ表現は {符号S, 指数部E, 仮数部T} の組で表され、指数部Eが全ビット1かつ仮数部Tが非ゼロのとき NaN と解釈される。上記で指定するタグは仮数部(significand)ビット列*4に反映される。ただし、ISO C/C++およびIEC 60559いずれの仕様でもその意味を規定しないため、実動作は処理系に依存する。

C11 7.12.11.2/p1-2, 7.22.1.3/p3-4より一部引用（下線部は強調）。C++標準ライブラリに含まれるC標準ライブラリはC言語仕様に従う。*5

#include <math.h>
double nan(const char *tagp);
float nanf(const char *tagp);
long double nanl(const char *tagp);

2 The call nan("n-char-sequence") is equivalent to strtod("NAN(n-char-sequence)", (char**) NULL); the call nan("") is equivalent to strtod("NAN()", (char**) NULL). If tagp does not point to an n-char sequence or an empty string, the call is equivalent to strtod("NAN", (char**) NULL). Calls to nanf and nanl are equivalent to the corresponding calls to strtof and strtold.

3 The expected form of the subject sequence is an optional plus or minus sign, then one of the following:

• (snip)
• NAN or NAN(n-char-sequence_opt), ignoring case in the NAN part, where:

　　n-char-sequence:
　　　　digit
　　　　nondigit
　　　　n-char-sequence digit
　　　　n-char-sequence nondigit
(snip)

4 (snip) A character sequence NAN or NAN(n-char-sequence_opt) is interpreted as a quiet NaN, if supported in the return type, else like a subject sequence part that does not have the expected form; the meaning of the n-char sequence is implementation-defined.²⁹³⁾(snip)
脚注293) An implementation may use the n-char sequence to determine extra information to be represented in the NaN's significand.

C99 (PDF)Rationale 5.2.4.2.2, 7.20.1.3より一部引用。

5.2.4.2.2 Characteristics of floating types <float.h>
NaNs
The primary utility of quiet NaNs, as stated in IEC 60559, "to handle otherwise intractable situations, such as providing a default value for 0.0/0.0," is supported by C99.

Other applications of NaNs may prove useful. Available parts of NaNs have been used to encode auxiliary information, for example about the NaN’s origin. Signaling NaNs might be candidates for filling uninitialized storage; and their available parts could distinguish uninitialized floating objects. IEC 60559 signaling NaNs and trap handlers potentially provide hooks for maintaining diagnostic information or for implementing special arithmetics.

However, C support for signaling NaNs, or for auxiliary information that could be encoded in NaNs, is problematic. Trap handling varies widely among implementations. Implementation mechanisms may trigger signaling NaNs, or fail to, in mysterious ways. The IEC 60559 floating-point standard recommends that NaNs propagate; but it does not require this and not all implementations do. And the floating-point standard fails to specify the contents of NaNs through format conversion. Making signaling NaNs predictable imposes optimization restrictions that anticipated benefits don’t justify. For these reasons this standard does not define the behavior of signaling NaNs nor specify the interpretation of NaN significands.

7.20.1.3 The strtod, strtof, and strtold functions
So much regarding NaN significands is unspecified because so little is portable. Attaching meaning to NaN significands is problematic, even for one implementation, even an IEC 60559 one. For example, the IEC 60559 floating-point standard does not specify the effect of format conversions on NaN significands. Conversions, perhaps generated by the compiler, may alter NaN significands in obscure ways.

IEEE 754 2.1, 6.2, 6.2.1より一部引用。

2.1 Definitions
payload: The diagnostic information contained in a NaN, encoded in part of its trailing significand field.

6.2 Operations with NaNs
Two different kinds of NaN, signaling and quiet, shall be supported in all floating-point operations. Signaling NaNs afford representations for uninitialized variables and arithmetic-like enhancements (such as complex-affine infinities or extremely wide range) that are not in the scope of this standard. Quiet NaNs should, by means left to the implementer's discretion, afford retrospective diagnostic information inherited from invalid or unavailable data and results. To facilitate propagation of diagnostic information contained in NaNs, as much of that information as possible should be preserved in NaN results of operations.

6.2.1 NaN encodings in binary formats
All binary NaN bit strings have all the bits of the biased exponent field E set to 1 (see 3.4). A quiet NaN bit string should be encoded with the first bit (d₁) of the trailing significand field T being 1. A signaling NaN bit string should be encoded with the first bit of the trailing significand field being 0. If the first bit of the trailing significand field is 0, some other bit of the trailing significand field must be non-zero to distinguish the NaN from infinity. In the preferred encoding just described, a signaling NaN shall be quieted by setting d1 to 1, leaving the remaining bits of T unchanged.

For binary formats, the payload is encoded in the p-2 least significant bits of the trailing significand field.

関連URL

• floating point - Why does IEEE 754 reserve so many NaN values? - Stack Overflow
• c - What is the "char-sequence" argument to NaN generating functions for? - Stack Overflow
• c++ - When creating a nan which contains a char-sequence, how do I get the char-sequence back? - Stack Overflow
• https://twitter.com/yohhoy/status/1155140703707492352

*1:https://ja.wikipedia.org/wiki/NaN

*2:C/C++言語仕様およびIEC 60559仕様（旧IEC 559）では、2種類のNaN "quiet NaN" と "signaling NaN" を規定している。

*3:厳密には アンダースコア(_)、アルファベット(a-z A-Z)、数値(0-9)の組み合わせが許容される。（C11 6.4.2.1/p1）

*4:仮数部(significand) MSB 2ビットはquiet NaN/signaling Nanの区別に利用するため、以降のビット列がペイロード(payload)となる。

*5:C++17 20.2/p2: "The descriptions of many library functions rely on the C standard library for the semantics of those functions. In some cases, the signatures specified in this International Standard may be different from the signatures in the C standard library, and additional overloads may be declared in this International Standard, but the behavior and the preconditions (including any preconditions implied by the use of an ISO C restrict qualifier) are the same unless otherwise stated."