本の虫

著者:江添亮
ブログ: http://cpplover.blogspot.jp/
メール: boostcpp@gmail.com
Twitter: https://twitter.com/EzoeRyou
GitHub: https://github.com/EzoeRyou

アマゾンの江添のほしい物リストを著者に送るとブログ記事のネタになる

筆者にブログのネタになる品物を直接送りたい場合、住所をメールで質問してください。

C++標準化委員会の文書: P0320R0-P0329R0

[PDF] P0320R0: Thread Constructor Attributes

pthread attributesに相当するstd::thread::attributesを追加する提案。これにより、移植性が高い方法でスレッドのスタックサイズや優先度などを設定できるようになる。

例えば、スタックサイズを指定するには以下のように書く。

std::thread::attributes attrs;
attrs.set_stack_size(4096*10);
std::thread t(attrs, func);

現在の提案ではスタックサイズの指定しか規定していないが、プラットフォームごとの設定も、thread::attributesを拡張することにより、自然な形で追加が可能だ。また、native_handleもサポートされているので、プラットフォームごとのコードも書きやすい。

WindowsのWin32 APIやインターフェースがだいぶ違うので、Windowsでこれを実装するのはすこし面倒だそうだ。

P0322R0: P0322r0 : exception_list

Parallelism TSにある並列実行中の例外をすべてexception_ptrで保持してくれるexception_listというライブラリは便利なのでParallelism TS専用にしておくのはもったいない。汎用的に使えるよう設計すべきだということでexception_listをユーザーが構築できるようにする提案。

exception_listはimmutableな設計になっている。

std::exception_list l ;
// push_back相当
l = std::exception_list( l, std::current_exception() ) ;

exception_listにはムーブがない。コピーはある。そのため、push_back相当のことするには、既存のexception_listのオブジェクトと追加するexception_ptrをコンストラクターに渡して新しいexception_listのオブジェクトを作る必要がある。

[PDF] P0323R0: A proposal to add a utility class to represent expected monad (Revision 2)

標準ライブラリにexpected<T,E>を入れる提案。optionalはexpected<T,bool>とみなすこともできる。さらに、expected<T,E>はvariant<T,E>の特殊なものとみなすこともできる。

expected<T,E>は、T型のオブジェクトかE型のオブジェクトのいずれか保持する。通常はT型のオブジェクトを保持し、エラー時にはE型のオブジェクトを保持している。

他の言語では、eitherという形で存在している機能だ。

P0324R0: One Concept Definition Syntax

関数コンセプトを廃止して変数コンセプトに一本化する提案。

// 関数コンセプト
template <typename T>
concept bool FC() {
    return constraint-expression;
}

// 変数コンセプト
template <typename T>
concept bool VC = constraint-expression;

問題は、現行のコンセプトTSはC++17に入らない見込みなので、あまり深く学ぶ意味がない。

P0325R1: Propose to adopt make_array into the IS

make_arrayを規格に入れる提案。

// std::array<int, 3>
auto a = std::make_array( 1, 2, 3 ) ;

便利だ。

[PDF] P0326R0: Structured binding: customization point issues

構造化束縛のcustomization pointはstd::tuple_sizeとstd::tuple_elementだったが、これは<utility>に依存する。utilityはfreestanding implementationではないので問題だ。そこで、構造化束縛のためのcunstomization pointを新たに作る。

関数の名前は、product_type_sizeとproduct_type_getになる。メンバー関数か、フリー関数として定義しておけば、range-based forのbegin/endに似たADL経由で見つけてくれる。

[PDF] P0327R0: Product types access

P0326と同じ提案だが、設計が少し違う。std::product_type::sizeとstd::product_type::getになっている。また型情報を得るためのtuple_element相当のstd::product_type::elementもある。

[PDF] P0329R0: Designated Initialization

C99にあるDesignated Initializationに似た機能。ただし省略ができない。


struct A { int a, b ; } ;

// すべてがdesignatorであるか、使わないかの二択
// C++: ill-formed
// C99: well-formed
A a = { 1, .b = 2 } ;

// designatorの順番は宣言順でなければならない。

// well-formed
A a = { .a = 1, .b = 2 } ;

// C++: ill-formed.
// C99: well-formed.
A a = { .b = 2, .a = 1 } ;

// designatorの重複は認められない
// C++: ill-formed.
// C99: well-formed 
A a = { .a = 1, .a = 1 } ;

// 配列の初期化はできない

// C++: ill-formed.
// C99: well-formed
A a = { [2] = 2 } 

// ネストはできない。
// C++: ill-formed.
// C99: well-formed.
A a= { .a.b.c.d = 0 } ; 

// リスト初期化はサポートしている
A a = { .a = { } } ;

目的はreadabilityを上げることのみ。

ドワンゴ広告

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

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

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