C++標準化委員会の文書: P0650R1-P0722R1

[PDF] P0650R1: C++ Monadic interface

C++でモナドをやるためのライブラリの提案。どうもライブラリでやると煩雑になる気がするのだが。

[PDF] P0655R0: visit<R>: Explicit Return Type for visit

戻り値の型Rを明示的に指定できるvisit<R>の提案。

[PDF] P0657R1: Deprecate Certain Declarations in the Global Namespace

C言語における標準ヘッダーファイル<name.h>はC++では<cname>になった。C++形式のヘッダーファイルをincludeすると、std名前空間スコープに名前が宣言される。同時に、グローバル名前空間に名前が宣言されるかもしれない。

この提案は、C++形式のヘッダーファイルをincludeすると、グローバル名前空間に名前が宣言されることをdeprecated扱いする提案だ。なので、文面は「グローバル名前空間に名前が宣言されるかもしれない」から、「deprecated扱いではあるが、グローバル名前空間に名前が宣言されるかもしれない」になる。

P0658R1: Proposal for adding alias declarations to concepts

conceptのrequires式の本体にエイリアス宣言を書けるようにする提案。

template < typename T>
concept bool SomeReq = requires {
    typename value_type_t<T> ;
    requires Constructible<T, value_type_t<T> > ;
} ;

が、

template < typename T>
concept bool SomeReq = requires {
    using value_type = value_type_t<T> ;
    requires Constructible<T, value_type > ;
} ;

になる。conceptでネストされた型名記述に誤解を生みそうな気がする。conceptはすでにドラフト入りしているのだが、果たして普通のC++プログラマーが書けるようになるのだろうか。

P0670R1: Static reflection of functions

関数呼び出し式から呼び出される関数を得たり引数の型をそれぞれ得たりできるわりと軽めのリフレクション機能の提案。

void func(int);
void func(std::string);
using func_call_m = reflexpr(func(123));
using func_m = get_callable_t<func_call_m>; // reflects void func(int)
using param0_m = get_element_t<0, get_parameters_t<func_m>>;
cout << get_name_v<get_type_t<param0_m>> << '\n'; // prints "int"

[PDF] P0684R1: C++ Stability, Velocity, and Deployment Plans

C++標準化委員会が新機能を追加する際に下位互換性を破壊する変更を伴う時、ユーザーが既存のコードを変更する際に行われる行動を想定した上で、どのようにすべきかという提案。

C++の新しい規格を受容する時は以下のようなステップで行われる。

1. 新しい規格をサポートした新しいコンパイラーにアップグレードする
2. 新しいコンパイラーの古い規格モードでの既存のコードをコンパイルすると互換性の問題になる箇所について警告を受ける
3. 警告を確認してコードを修正する
4. 新しい規格モードを有効にする

これに従い、下位互換性を破壊する言語機能は容易に警告を出せるかどうかについて注意を払うべきである。

P0692R0: Access Checking on Specializations

知らなかった。

クラスのprivateなメンバーは当然クラス外部からアクセスできないわけだが、既存のほとんどのコンパイラーはテンプレートの明示的特殊化でアクセス指定を無視する。また、GCCとMSVCは部分的特殊化でもアクセス指定を無視する。

class A {
template < typename T >
class impl { } ;
} ;

template < typename T >
struct traits { } 

// 明示的特殊化
// 規格上はエラー
// GCC, Clang, ICC, MSVCは通す
template < >
struct traits< A::impl > { } ;

// 部分的特殊化
// 規格上はエラー
// GCC, MSVCは通す
// Clang, ICCはエラー
template < typename T >
struct traits< A::impl > { } ;

これを踏まえると、現状のC++実装がこの場合にアクセス指定を無視するよう実装していて、またこの仕様ではないとprivateメンバーの型に対する特殊化が出来ないことも考えると、規格を変更してこの制限を取り払ったほうがよいので、明示的特殊化と部分的特殊化ではアクセス指定の制限を緩和をする提案。

P0701R1: p0701r1: Back to the std2::future Part II

名前がよい。

内容はfutureに対する機能追加に対する提案。

[PDF] P0707R2: Metaclasses: Generative C++

現在提案されている静的リフレクションライブラリが入ったという前提でその静的リフレクション機能を使って実装できるmetaclassライブラリの提案。

constexpr {       // コンパイル時実行
    for ( auto m : $T.variables() ) // T型のメンバー変数それぞれに対し
        if ( m.name() == "foo" )  // "foo"という名前のメンバーがあれば
            -> { int bar ; }  // int型の"bar"という名前のメンバーを注入する。

}

割と衝撃的なコードだ。

P0722R1: Efficient sized delete for variable sized classes

sized deallocate functionにクラスへのポインターを取るオーバーロードを追加する提案。

クラスオブジェクトの近隣のストレージ領域を活用した動的にオブジェクトサイズを変えるクラスを実装する時、sizeを効率的に指定するために使える。

void operator delete ( X *, std::destroying_delete_t, その他の引数 ) ;

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

採用情報｜株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0