C++標準化委員会の文書 2015-04-pre-Lenexaのレビュー: N4470-N4482

Variadic lock_guard

std::mutexなどのlock/unlockするオブジェクトが複数ある場合は、ロックする順番を工夫しないと、デッドロックしてしまう。そこで、標準ライブラリには、ロックする順番を実装依存の方法でデッドロックを起こさないようにしてくれるstd::lockがある。

また、標準ライブラリには、std::lock_guardという、RAIIラッパーがある。

問題はこの2つを組み合わせるのが結構ダルい。

std::mutex m1, m2 ;

void f()
{
    std::lock( m1, m2 ) ;

    std::lock_guard<std::mutex> l1( m1, std::adopt_lock ) ;
    std::lock_guard<std::mutex> l2( m2, std::adopt_lock ) ;
}

そのため、lock_guardをVariadic Templatesにして、任意個のlockを受け取れるようにする提案。

std::lock_guard< std::mutex, std::mutex > l( m1, m2 ) ;

ぜひ入るべきだ。

N4471: Template parameter deduction for constructors (Rev. 2)

クラステンプレートのコンストラクターからテンプレート実引数を推定する提案。

template < typename T >
struct S
{
    S( T ) ;
} ;

// めんどくさい
S<int> s1(0) ;
// N4471提案
S s2(0) ; // S<int>

ぜひ入って欲しい。

ただし、単純にコンストラクターから推定できない場合もある。

vector<X> v1 = { ... } ;
auto v2 = vector( v1.begin(), v1.end() ) ; // v2はvector<X>になってほしい

この場合は推定できない。提案では、typed constructorを導入するという案がある。

template<typename T, typename Alloc = std::allocator<T>> struct vector {
  // Option 1: Typed constructor in primary template only
  template <typename Iter> vector<iter::value_type>(Iter b, Iter e);
};
// Option 2: Typed constructor given globally
template<typename Iter> vector<typename iterator_traits<Iter>::value_type>(Iter b, Iter e);
template<typename Iter> vector(Iter b, Iter e) -> vector<typename iterator_traits<Iter>::value_type>

これはちょっとやり過ぎな感がある。

N4472: constexpr goto

constexpr関数の中でgotoの使用を認める提案。

現在、constexpr関数の中でgotoを使うことはできない。しかし、条件分岐やループは使うことができる。gotoが使えないのは本当に技術上の制約なのか。はた、単なる好みの問題なのか。ネストされたループから抜けるにはgotoを使うのが最も手っ取り早いし、広く使われている。gotoは本当に禁止すべきなのか。

N4473: noexcept(auto), again

noexcept(auto)復活論。

noxcept(auto)例外指定は、関数の本体が例外を投げる可能性があればnoexcept(false)に、例外を投げなければnoexcept(auto)になる。

[PDF注意] N4474:Unified Call Syntax: x.f(y) and f(x,y)

統一関数呼び出し記法の提案。

x.f(y)に対して、もし呼び出しが妥当ではない場合、f(x,y)を試みる。

p->f(y)に対して、もし呼び出しが妥当ではない場合、f(p,y)を試みる

f(x,y)に対して、もし呼び出しが妥当ではない場合で、xに対して->が定義されている場合、x->f(y)を試みる。そうでなければx.f(y)を試みる。

begin/end/swapと言った共通の処理をするのに、メンバー関数で実装されているのかフリー関数で実装されているのかがわからないため、。ジェネリックコードから使いにくいという問題を解決する。

ただし、これを真面目に考えると、"hello".puts()や2.0 .sqrt() (スペースは必要)も合法になる。

std::FILE *型の変数fpにたいして、fp->fclose()などが呼び出せるので、静的解析ツールによる補完がやりやすくなるという意見もあるが、for_eachなども補完されてしまうの、果たして便利だろうか。論文はこの懸念を載せていないが。

[Bjarneは論文をPDFで書くのをやめろ] N4475:Default comparisons (R2)

デフォルトの比較演算子を暗黙に生成する機能の提案。

クラスのデータメンバーが比較可能なとき、クラスのメンバーごとの比較を行う比較演算子を自動で生成できる機能。

ポインター型のデータメンバーがある場合は==と!=を生成しない。mutableは比較しないという、批判論文の意見は無視した形の提案となっている。

私はポインターもmutableメンバーも等しく評価されるべきだと思う。

[Bjarneは論文をPDFで書くのをさっさとやめろ ] N4476: Thoughts about Comparisons (R2)

比較演算子の自動生成に対する様々な戦略について考察している。

[BjarneはとにかくPDFをやめろ] N4477: Operator Dot (R2)

operator .をオーバーロードできるようにする提案。プロクシークラスが書けるようになる。

N4478: Networking Library Proposal (Revision 5)

ネットワークライブラリの提案。Boost.Asioが土台になっている。

N4479: Merge Fundamentals V1 into V2

提案されているライブラリ拡張のLibrary Fundamentals V2をV1にマージするという文書。NB投票の際に混乱を防ぐためにV1とV2は分割していたそうだ。

N4480: C++ Extensions for Library Fundamentals, DTS

N4481: C++ Extensions for Library Fundamentals, Version 2, Tentative Working Draft

ライブラリ拡張提案のドラフト

N4482: Some notes on executors and the Networking Library Proposal

ネットワークライブラリにおけるexecutorについて、別の論文で提案されている、軽量実行媒体との用語のすり合わせや、最新の会議での合意内容とのすり合わせ、また先行研究への言及。