C++標準化委員会の文書: P0165R0-P0293R0

P0165R3: C++ Standard Library Issues to be moved in Issaquah

Issaquah会議で議論されるマイナーな問題集。

[PDF] P0187R1: Proposal/Wording for Bit-field Default Member Initializer Syntax

ビットフィールド付きのデータメンバーにメンバー初期化子を書けるようにする提案。

前回の提案では以下のような文法が提案されていたが、

struct X
{
    int data : 5 = 1 ;
} ;

この文法は曖昧だとして、以下のような文法になった。

struct X
{
    int data : 5 : = 1 ;
    int another_data : 5 : {2} ;
} ;

P0194R2: P0194R2 — Static reflection

様々な型情報、ソースコード情報を取得する静的リフレクション機能の文面。テンプレートメタプログラミングを土台としている極めて使いづらい設計となっている。

P0195R1: Modernizing using-declarations

using宣言をパラメーターパックに対応させる提案。

template < typename ... Funcs >
struct overload
{
    using Funcs::operator () ... ;
} ;

overloadのようなライブラリを再帰を使わずに簡単に実装できるようになる。

[PDF] P0196R2: Generic none() factories for Nullable types

nullableな型のためにnone_t型と、ファクトリー関数none<T>()を追加する提案。ポインターやoptionalなど様々なnullableな型に使える。

[PDF] P0201R1: An indirect value-type for C++

ディープコピーを行う版unique_ptr<T>のような型、indirect<T>の提案。前回の提案では、cloned_ptr<T>と呼ばれていた。

indirect<int> i{ new int(42) } ;
// ディープコピーされる
// 新しいint型のオブジェクトが確保されて値42がコピーされる
auto j = i ; 

// 42
std::cout << *j << '\n' ;

// i, jのデストラクターで所有するint型のオブジェクトがそれぞれ破棄される

unique_ptrはポインターを所有し、コピーを禁止し、デストラクターで破棄する。。shared_ptrはポインターを所有し、コピーはリファレンスカウントにより所有権を共有し、デストラクターでリファレンスカウントを減じて、どこからも参照されていなければ破棄する。indirectはポインターを所有し、コピー時にはディープコピーし、デストラクターでは破棄する。

コピーと破棄には、コピーアーとデリーターによって独自の挙動を設定できる。

int * ptr = static_cast<int *>( std::malloc( sizeof(int) ) ) ;
*ptr = 42 ;
indirect<int> i( ptr,
[]( auto ptr ){
    int * copy = static_cast<int * >( std::malloc( sizeof(int)) ) ;
    *copy = *ptr ;
    return copy },
[]( auto ptr )
{
    std::free( ptr ) ;
} ) ;

// mallocでメモリが確保される
auto j = i ;

// freeでメモリが破棄される

[PDF] P0214R2: Data-Parallel Vector Types & Operations

SIMDやGPGPUなどの並列処理を行うためのベクトル型の提案。

[PDF] P0233R2: Hazard Pointers: Safe Reclamation for Optimistic Concurrency

ハザードポインターライブラリー、haz_ptrの提案

P0237R3: Wording for fundamental bit manipulation utilities

符号なし整数型に対して、ビット単位のイテレーターを提供するライブラリ。イテレーターを提供することにより、汎用的なアルゴリズムにビット列処理のために渡すことができる。

[PDF] P0249R2: Input Devices For 2D Graphics

2Dグラフィックライブラリのために、GUIプログラミングで一般的なイベント駆動を実現するためにメッセージ処理を行うためのライブラリの提案。

[PDF] P0252R2: Operator Dot Wording

複雑怪奇で理解不可能なoperator .のオーバーロードを可能にする文面案。

このような極めてわかりにくい機能が提案されているのは、おそらくこれがBjarne Stroustrupのお気に入り案件だからだろう。最近のBjarne StroustrupのC++の判断能力は、最近の書籍から判断すると、極めて疑問である。Bjarne StroustrupはC++から引退するべきではないだろうか。

P0261R1: C++ Distributed Counters

高頻度のインクリメントを行うが読み込みはまれなアトミックなカウンターライブラリの提案。

アトミック操作では、インクリメントは読み込みよりコストがかかる。多くのプログラムではカウンターを用いるが、めったに読み込まないカウンターのためにアトミックなインクリメント操作を行うのはスケールしない。そこで、読み込みのコストを犠牲にインクリメントを高速化した分散カウンターが標準ライブラリにほしい。

P0262R1: A Class for Status and Optional Value

値と情報を保有できる、status_valueライブラリの提案。

現在提案されているexpectedは、値か情報のどちらかを保有するライブラリだ。expectedは値と情報の両方を保有したい時には使えない。つまり、

• 値を保有する。情報は保有しない
• 値を保有しない。情報を保有する
• 値を保有する。情報を保有する
• 値を保有しない。情報を保有しない

というどの状態にもでき、かつoptionalやexpectedのように値がない場合の簡単に書けるようなライブラリを提案している。

こういう目的に特化したライブラリを乱立させるより、C++のコア言語にnullableな値も含む多値を扱える仕組みを入れたほうがいいのではないか。

[PDF] P0279R1: Read-Copy Update (RCU) for C++

RCUライブラリの提案。

P0290R1: P0290R1: apply() for synchronized_value

synchronized_value<T>はT型とmutexを保持するクラスだ。この文書で提案されているapplyは、synchronized_valueをlockして値にアクセスしunlockするための関数だ。

void f( synchronized_value<int> & s )
{
    apply( []( auto value ) { ++x ; }, s ) ;
}

applyは関数オブジェクトと、Variadic Templatesで任意個のsynchronized_valueを受け取る。デッドロックを起こさない方法ですべてロックして、値を関数オブジェクトに渡し、アンロックする。

便利だ。

[PDF] P0293R0: Template deduction for nested classes

クラステンプレート内にネストしたクラステンプレートの実引数推定ができるようにする提案。

趣旨はわかるのだが、すでにC++規格でも標準ライブラリのコンテナーのイテレーターはコンテナークラスの外で定義されるように規定されているので、このような提案が必要になるコードはそもそも扱いづらいので避けるべきではないか。