C++標準化委員会の文書: P0451R0-P0459R0

P0451R0: P0451r0: Future-Proofing Parallel Algorithms Exception Handling

並列アルゴリズムで要素アクセス関数が例外を投げた時、並列に実行されるので当然複数の例外がキャッチされる可能性があるが、この例外はexception_listという複数の例外を格納するクラスに入れてthrowされるということになっていた。

しかし、このexception_listについて、実装経験がなく規格通りに実装できるかどうかわからないとして、要素アクセス関数が例外を投げた場合は、std::terminate()が呼ばれるように変更された。

この提案では、将来の拡張のために、カスタマイゼーションポイントとしてfail()関数を呼ぶようにしてはどうかと提案している。デフォルトのfailはterminateを呼ぶ。

P0452R0: P0452r0: Binary-Binary transform_reduce(): The Missing Overload

inner_productは規格の定義上並列化できないので、並列化できる設計のtransform_reduceを提案。また、既存のアルゴリズムの流儀に従って同じオーバーロードを提供する。

P0454R0: P0454r0: Wording for a Minimal mdspan

連続したストレージを多次元配列に見せかけるラッパーライブラリ、mdspanの文面案。

名前が暗号的だ。

P0457R0: String Prefix and Suffix Checking

basic_stringとbasic_string_viewに対して、指定した文字列が冒頭、末尾にあるかどうかを調べる、starts_with/ends_withというメンバー関数を追加する。

この機能は極めてよく使う機能であり、また一般的でもある。例えばPythonやJavaの文字列ライブラリは実装しているしQtの文字列ライブラリも実装している。また、最近のQtのコードは1193件のstarts_withと953件のends_withを利用している。他の例を見ても、webkitは304件のstarts_with、142件のends_withを使っている。LLVMは113件のstarts_withと38件のends_withを使っている。

フリー関数ではなくメンバー関数にした理由としては、既存の設計と一貫性があることと、フリー関数にした場合は引数の順序という問題が発生するためである。

using std::literals ;

auto s = "hello world" ;

bool b1 = s.starts_with("hello") ;
bool b2 = s.starts_with("hell") ;
bool b3 = s.starts_with('h') ;

basic_string_viewもしくはcharを引数に取る。

今更追加するのか呆れるが、とはいえよく使う処理ではある。

P0458R0: Checking for Existence of an Element in Associative Containers

連想コンテナーに指定した要素が存在するかどうかを調べるメンバー関数containsの追加の提案。

現状では、連想コンテナーcにある値eの要素が存在するかどうかを調べるには、メンバー関数findを呼び出して、戻り値がc.end()と等しいかどうかを調べることで実装できる。

template < typename C, typename E >
bool contains( C && c, E && e )
{
    return c.find( e ) != c.end() ;
}

このコードは甚だ冗長である。初心者はこのコードを読んでも意図がわからない。また、初心者はこのコードを思いつかず、stack overflowに「連想コンテナーにinsertせずに要素が存在するかどうかを調べる方法ってないの？」という質問をする

c++ - How to check if std::map contains a key without doing insert? - Stack Overflow

この提案により、以下のように書けるようになる。

template < typename C, typename E >
bool contains( C && c, E && e )
{
    return c.contains( e ) ;
}

あまりにも今更な機能追加だが、直ちに追加すべきだ。もともと要望としてはstd-proposalsに上がっていたのだが、誰も公式に提案文書を書いて標準化委員会に提出して国際会議に出席して議論するという労力をかけるものがいなかったのだ。

委員会による設計の欠点の最たる例だ。

[PDF] P0459R0: C++ Extensions for Ranges, Speculative Combined Proposal Document

修正案をマージしたRangeの文面案。

ドワンゴ広告

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

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

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