yohhoyの日記

技術的メモをしていきたい日記

C互換ヘッダとstd名前空間

C++ C

C++標準ライブラリに含まれるC標準ライブラリヘッダ*1と、std名前空間との関係についてメモ。

C++11以降では、下記の振る舞いが保証される：

  • ヘッダcxxx: 名前空間stdにCライブラリの識別子が宣言される。グローバル名前空間にも宣言されるかもしれない。
  • ヘッダxxx.h: グローバル名前空間にCライブラリの識別子が宣言される。名前空間stdにも宣言されるかもしれない。

C++17

C++17 D.5/p3-4より引用（下線部は強調）。29.9.5＝Mathematical special functions*2, 21.2.5＝byte type operations*3

3 Every other C header, each of which has a name of the form name.h, behaves as if each name placed in the standard library namespace by the corresponding cname header is placed within the global namespace scope, except for the functions described in 29.9.5, the declaration of std::byte (21.2.1), and the functions and function templates described in 21.2.5. It is unspecified whether these names are first declared or defined within namespace scope (6.3.6) of the namespace std and are then injected into the global namespace scope by explicit using-declarations (10.3.3).
4 [Example: The header <cstdlib> assuredly provides its declarations and definitions within the namespace std. It may also provide these names within the global namespace. The header <stdlib.h> assuredly provides the same declarations and definitions within the global namespace, much as in the C Standard. It may also provide these names within the namespace std. -- end example]

C++11/14

C++11 D.5/p2-3より引用（下線部は強調）。C++14でも同様。

2 Every C header, each of which has a name of the form name.h, behaves as if each name placed in the standard library namespace by the corresponding cname header is placed within the global namespace scope. It is unspecified whether these names are first declared or defined within namespace scope (3.3.6) of the namespace std and are then injected into the global namespace scope by explicit using-declarations (7.3.3).
3 [Example: The header <cstdlib> assuredly provides its declarations and definitions within the namespace std. It may also provide these names within the global namespace. The header <stdlib.h> assuredly provides the same declarations and definitions within the global namespace, much as in the C Standard. It may also provide these names within the namespace std. -- end example]

C++03

ヘッダcxxxでは名前空間std配下に宣言し、ヘッダxxx.hでは “名前空間std配下に宣言してからグローバル名前空間へ取り込む(using-declaration)” と強く規定されていた。C++03 D.5/p2-3より引用。

2 Every C header, each of which has a name of the form name.h, behaves as if each name placed in the Standard library namespace by the corresponding cname header is also placed within the namespace scope of the namespace std and is followed by an explicit using-declaration (7.3.3).
3 [Example: The header <cstdlib> provides its declarations and definitions within the namespace std. The header <stdlib.h> makes these available also in the global namespace, much as in the C Standard. -- end example]

関連URL

*1:ヘッダ <cstdlib> とヘッダ <stdlib.h> など

*2:assoc_laguerre, assoc_legendre, beta, comp_ellint_1, comp_ellint_2, comp_ellint_3, cyl_bessel_i, cyl_bessel_j, cyl_bessel_k, cyl_neumann, ellint_1, ellint_2, ellint_3, expint, hermite, laguerre, legendre, riemann_zeta, sph_bessel, sph_legendre, sph_neumann

*3:std::byte 型に対する演算子オーバーロード、to_integer<IntType>関数テンプレート

Concept-basedオーバーロードとSFINAE-unfriendlyメタ関数の落とし穴

C++ C++2a

C++2a(C++20)で導入されるrequires節を用いた関連制約(associated constraints)により従来SFINAE技法よりも関数テンプレートのオーバーロード制御が容易となるが、戻り値型にSFINAE-unfriendlyなメタ関数を用いるケースでは意図しないコンパイルエラーを引き起こす。

2021-01-13追記：CWG 2369. Ordering between constraints and substitution にてConceptとSFINAEの差異をなくす修正提案がなされ、N4879 によれば DefectReport として採択済み。C++20から遡及適用されるため、本記事の内容は全て無効となる。☆（ゝω・）vﾔｯﾀﾈ

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

下記コードにおいてdouble型の値1.0でtest関数を呼び出すと、オーバーロード#1の戻り値型導出にて make_signedメタ関数 の必須要件(Mandates)違反によるコンパイルエラーとなる（→id:yohhoy:20200605）。*1

// C++2a
#include <concepts>
#include <type_traits>

// template <typename T>
//   requires std::unsigned_integral<T>と等価
template <std::unsigned_integral T>
auto test(T) -> std::make_signed_t<T>;  // #1

template <typename T>
auto test(T) -> int;  // #2

test(1u);   // OK: #1を選択
test(1.0);  // NG!? (#2を期待)

この振る舞いは 1) 実引数からのテンプレートパラメータ推論とオーバーロード候補除外（SFINAE-based overloading）、2) テンプレートパラメータに依存する戻り値型導出、3) 関連制約に基づくオーバーロード候補除外（Concept-based overloading）という順序に起因している。

前掲コードを古き良きSFINAE技法に書き換えると、オーバーロード#1の戻り値型導出よりも前に候補除外されstd::make_signedメタ関数の必須要件違反は回避される。一方でrequires節に比べると煩雑なコード記述が必要とされる。

#include <concepts>
#include <type_traits>

template <typename T,
          typename = std::enable_if_t<std::unsigned_integral<T>>>
auto test(T) -> std::make_signed_t<T>;  // #1

template <typename T,
          typename = std::enable_if_t<!unsigned_integral<T>>>
auto test(T) -> int;  // #2

test(1u);   // OK: #1を選択
test(1.0);  // OK: #2を選択

StackOverflow回答によれば本件は CWG 2369 にて議論中とのこと。2020年9月現在は最新ステータス非公開...

C++2a DIS(N4861) 13.10.2/p5より引用（下線部は強調）。

The resulting substituted and adjusted function type is used as the type of the function template for template argument deduction. If a template argument has not been deduced and its corresponding template parameter has a default argument, the template argument is determined by substituting the template arguments determined for preceding template parameters into the default argument. If the substitution results in an invalid type, as described above, type deduction fails. [Example:

 template <class T, class U = double>
 void f(T t = 0, U u = 0);

 void g() {
   f(1, 'c');      // f<int,char>(1,'c')
   f(1);           // f<int,double>(1,0)
   f();            // error: T cannot be deduced 
   f<int>();       // f<int,double>(0,0)
   f<int,char>();  // f<int,char>(0,0)
}

-- end example]
When all template arguments have been deduced or obtained from default template arguments, all uses of template parameters in the template parameter list of the template and the function type are replaced with the corresponding deduced or default argument values. If the substitution results in an invalid type, as described above, type deduction fails. If the function template has associated constraints (13.5.2), those constraints are checked for satisfaction (13.5.1). If the constraints are not satisfied, type deduction fails.

関連URL

*1:実際の振る舞いはC++標準ライブラリ内部実装に依存する。処理系によってはオーバーロード#1が ill-formed とならずに、期待通りオーバーロード#2が選択される可能性もある。

memcmp関数 × 宇宙船演算子

C++ C++2a

C++2a(C++20)で導入される三方比較演算子(three-way comparison operator)<=>（通称：宇宙船演算子(spaceship operator)）と、C言語時代の関数インタフェースでよくみられる三方比較結果 “負値／値0／正値” との組合せ利用について。新旧仕様の橋渡し。

例えばmemcmp関数によるメモリブロック比較結果(int型)は、さらに値0と三方比較することでstrong_ordering型の比較結果へと変換できる。

// C++2a
#include <cstring>  // memcmp
#include <compare>

auto memblock_compare(const void* p, const void* q, size_t n)
  -> std::strong_ordering
{
  return std::memcmp(p, q, n) <=> 0;
  // 下記処理に相当
  // int r = std::memcmp(p, q, n);
  // if (r < 0) return std::strong_ordering::less;
  // if (r > 0) return std::strong_ordering::greater;
  // return std::strong_ordering::equal;
}

ノート：C++標準ライブラリstd::basic_string, std::basic_string_view, std::filesystem::pathのcompareメンバ関数も三方比較結果を戻り値 “負値／値0／正値” として返すが、C++2aでは<=>演算子オーバーロードも直接提供するため本テクニックの利用機会はないだろう。

関連URL

todo!とunimplemented!の違い

Rust

プログラミング言語Rustのtodo!マクロとunimplemented!マクロの違い。

  • todo!：作業途中のコード。あとで実装する。
  • unimplemented!：現行コードでは未実装（実装するとは言っていない）

The difference between unimplemented! and todo! is that while todo! conveys an intent of implementing the functionality later and the message is "not yet implemented", unimplemented! makes no such claims. Its message is "not implemented". Also some IDEs will mark todo!s.

関連URL

複合要件とsame_as/convertible_toコンセプト

C++ C++2a

C++2a(C++20)コンセプト requires式(requires-expression) に記述する 複合要件(compound-requirement) では「ある式の評価結果が特定コンセプトを満たすこと」を制約するが、このとき標準コンセプトstd::same_as／std::convertible_toを適切に使い分ける必要がある。特に “データメンバ型の制約” には注意すること。

下記コードのコンセプトC0では式t.dataがint型へと変換可能(convertible_to<int>)と制約しているが、コンセプトC1のようにint型と等しい(same_as<int>)と制約するとプログラマの期待通りに動作しない。

// C++2a
#include <concepts>

struct S {
  int data;   // int型のデータメンバ
  int& mf();  // int&型を返すメンバ関数
};

template <typename T> concept C0 = requires (T t) {
  // T型の値tはデータメンバdataをもち、int型へと変換可能
  { t.data } -> std::convertible_to<int>;
  // T型の値tはメンバ関数mf()をもち、呼び出し結果はint&型に等しい
  { t.mf() } -> std::same_as<int&>;
};
static_assert( C0<S> );  // OK

template <typename T> concept C1 = requires (T t) {
  // T型の値tはデータメンバdataをもち、"式t.data"はint型に等しい
  { t.data } -> std::same_as<int>;
  // ...
};
static_assert( C1<S> );  // NG: 式t.dataの型はint&

戻り値型を制約する複合要件{ E } -> C<U>;は、2つの制約E; requires C<decltype((E)), U>;*1と等価である。ここでdecltype指定子オペランドが括弧付きの式(E)となることに留意。（→id:yohhoy:20200817）

template <typename T> concept C1 = requires (T t) {
  // { t.data } -> std::same_as<int>; と等価な制約
  t.data;
  requires std::same_as<decltype((t.data)), int>;
  // ...
};

クラスのデータメンバ型をsame_asコンセプトで制約する場合は、下記コンセプトC2のように入れ子要件(nested-requirement)を利用する。*2

template <typename T> concept C2 = requires {
  // メンバT::dataはint型に等しい
  requires std::same_as<decltype(T::data), int>;
  // ...
}
static_assert( C2<S> );  // OK

下記コンセプトC3のように複合要件とsame_asコンセプトを組み合わせた場合、データメンバ型はintまたはint&いずれも制約を満たす。これはsame_asコンセプト利用意図からすると、不適切な制約表現といえる。*3

struct S1 {
  int data;   // int型のデータメンバ
};
struct S2 {
  int& data;  // int&型のデータメンバ
};

template <typename T> concept C3 = requires (T t) {
  { t.data } -> std::same_as<int&>;
};

// OK: データメンバが int型 または int&型 であれば制約を満たす
static_assert( C3<S1> && C3<S2> );

N4861 7.5.7.3/p1, 18.4.2, 18.4.4/p1より一部引用。

compound-requirement:
　　{ expression } noexceptopt return-type-requirementopt ;
return-type-requirement:
　　-> type-constraint


A compound-requirement asserts properties of the expression E. Substitution of template arguments (if any) and verification of semantic properties proceed in the following order:

  • Substitution of template arguments (if any) into the expression is performed.
  • If the noexcept specifier is present, E shall not be a potentially-throwing expression (14.5).
  • If the return-type-requirement is present, then:
    • Substitution of template arguments (if any) into the return-type-requirement is performed.
    • The immediately-declared constraint (13.2) of the type-constraint for decltype((E)) shall be satisfied. [Example: Given concepts C and D,
requires {
  { E1 } -> C;
  { E2 } -> D<A1, ..., An>;
};

is equivalent to

requires {
  E1; requires C<decltype((E1))>;
  E2; requires D<decltype((E2)), A1, ..., An>;
};

(including in the case where n is zero). -- end example]

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>;

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

Given types From and To and an expression E such that decltype((E)) is add_rvalue_reference_t<From>, convertible_to<From, To> requires E to be both implicitly and explicitly convertible to type To. The implicit and explicit conversions are required to produce equal results.

template<class From, class To>
  concept convertible_to =
    is_convertible_v<From, To> &&
    requires(add_rvalue_reference_t<From> (&f)()) {
      static_cast<To>(f());
    };

関連URL

*1:単純要件(simple-requirement)と入れ子要件(nested-requirement)の2つで表現される。

*2:制約が std::same_as<decltype(T::data), int> のみで構成される場合は requires 式の入れ子要件とする必要はなく、直接 template <typename T> concept C2 = std::same_as<decltype(T::data), int>; と記述すればよい。

*3:ソースコード上は “参照型と等しい” と読み取れる記述がなされ、実際には参照型／値型の両方を許容するコンセプトはトラブルの元になる可能性が高い。

decltype(auto) as non-type template-parameter

C++

非型テンプレートのプレースホルダ型にはautoまたはdecltype(auto)いずれも利用できる。素直にautoを使うべき。

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

template <auto N>
struct S { /*...*/ };
// または
template <decltype(auto) N>
struct S { /*...*/ };

S<42> obj;

C++17 10.1.7.4/p1, p5, 17.1/p4より一部引用（下線部は強調）。

1 The auto and decltype(auto) type-specifiers are used to designate a placeholder type that will be replaced later by deduction from an initializer. The auto type-specifier is also used to introduce a function type having a trailing-return-type or to signify that a lambda is a generic lambda (8.1.5.1). The auto type-specifier is also used to introduce a structured binding declaration (11.5).

5 A placeholder type can also be used in the type-specifier-seq in the new-type-id or type-id of a new-expression (8.3.4) and as a decl-specifier of the parameter-declaration's decl-specifier-seq in a template-parameter (17.1).

4 A non-type template-parameter shall have one of the following (optionally cv-qualified) types:

  • (snip)
  • a type that contains a placeholder type (10.1.7.4).

関連URL

decltype(e)とdecltype((e))のキモチ

C++

プログラミング言語C++における decltype指定子(decltype-specifier) の振る舞いについてメモ。

int x = 42;

// 括弧なしの変数名 x
decltype( x ) y = x;  // int 型
// 括弧付きの式 (x)
decltype((x)) z = x;  // int& 型

一見すると奇妙に思えるdecltype(e)型導出ルールは、「式eの型宣言を探す」という指針に基づいている。

  • 変数名x：ソースコード上に直接登場する変数x宣言時の型intとなる。
  • 式(x)：式(x)はソースコード上の宣言には現れない。式(x)の左辺値としての性質(lvalueness)を保持する参照型int&となる。*1

C++11言語仕様へのdecltype導入当時の提案文書(PDF) N2115 Decltype (revision 6): proposed wording より一部引用。*2

2.2 Semantics of decltype
Determining the type decltype(e) build on a single guiding principle: look for the declared type of the expression e. If e is a variable or formal parameter, or a function/operator invocation, the programmer can trace down the variable's, parameter's, or function's declaration, and find the type declared for the particular entity directly from the program text. This type is the result of decltype. For expressions that do not have a declaration in the program text, such as literals and calls to built-in operators, lvalueness implies a reference type.

おまけ：括弧付きの変数名のみからなる式(e)の扱いは検討当時も紆余曲折あったようで、(PDF)N1705(rev.4)時点ではdecltype((e))とdecltype(e)は等価とされていたが、その後のN2115(rev.6)にて現行仕様へと再変更されている。

C++17 10.1.7.2/p4より引用（下線部は強調）。*3

For an expression e, the type denoted by decltype(e) is defined as follows:

  • if e is an unparenthesized id-expression naming a structured binding (11.5), decltype(e) is the referenced type as given in the specification of the structured binding declaration;
  • otherwise, if e is an unparenthesized id-expression or an unparenthesized class member access (8.2.5), decltype(e) is the type of the entity named by e. If there is no such entity, or if e names a set of overloaded functions, the program is ill-formed;
  • otherwise, if e is an xvalue, decltype(e) is T&&, where T is the type of e;
  • otherwise, if e is an lvalue, decltype(e) is T&, where T is the type of e;
  • otherwise, decltype(e) is the type of e.

The operand of the decltype specifier is an unevaluated operand (Clause 8).
[Example:

const int&& foo();
int i;
struct A { double x; };
const A* a = new A();
decltype(foo()) x1 = 17;   // type is const int&&
decltype(i) x2;            // type is int
decltype(a->x) x3;         // type is double
decltype((a->x)) x4 = x3;  // type is const double&

-- end example] [Note: The rules for determining types involving decltype(auto) are specified in 10.1.7.4. --end note]

関連URL

*1:C++文法上は変数宣言時に括弧を記述できるが（例：int (y) = 42;）、この冗長な括弧は単に無視されてdecltypeの振る舞いには影響を与えない。https://gist.github.com/yohhoy/7b63eafcc42e078f34294857698adfd9

*2:C++仕様には後続文書(PDF)N2343が採択されている。

*3:1番目のBulletは 構造化束縛(structured binding) に対するルール。構造化束縛で導入される名前の型導出は、通常の変数宣言よりも複雑な規則となっている。