2014-02-post-Issaquahのレビュー: N3900-3909

2014-02-post-Issaquah mailingsが公開された。

最新のドラフトは、N3936となった。

[一発目から気分の悪いPDF] N3900: WG21 2014-01-31 Telecon Minutes

2014年1月31日に行われた電話会議の議事録。

[二発目にも気分を害するPDF] N3901: Minutes (February 2014) WG21 Meeting No. 57 N3902: Minutes (February 2014) PL22.16 Meeting No. 62

2014年2月15日に、米国ワシントン州Issaquahで開かれた国際会議の議事録。

N3903: C++ FCD Comment Status

FCDに対するNBコメントへの返答一覧。

スイス(・∀・)＜ C++14はバグ修正リリースとマイナー新機能のはずだろ。標準規格の品質を下げる新機能を全部外せ。互換性をぶち壊す変更をいれんな。

(´・ω・`)＜　すまんかった。std::dynarrayとstd::optionalはドラフトから外すわ。

ああ、ああああ。std::optionalが消えてしまう。なんということだ。スイスのせいで・・・スイスのせいで・・・

一方、std::dynarrayは、スタックからネストされた確保という概念に、もう少し議論が必要なので、外すのは妥当である。

このように、国家を代表するNBコメントは、とても強い力を持っている。日本のC++WG JPがNBコメントを送れる状況ではないのは、残念でならない。

イギリスからのNBコメントである、「u8"À"はu8"\u00c8"となり、これをUTF-8エンコードすると、char[3]が、{ 0xc3, 0x80, 0 }と初期化されることになる。しかし、charは0x80を表現可能であると保証されていない」というコメントに対しては、UTF-8のオブジェクト表現は、それぞれUTF-8エンコードのコードユニットの値をもち、0から255までの値は、charとunsigned charで、相互に変換可能な表現方法が存在するという規程が設けられることになった。

最初からUTF-8文字型として、char8_tを規定していればよかったのに。

1759を参照。

また、C++14では、連続したメモリ確保を、一括したメモリ確保に変えることを、実装に許す制限緩和が入った。問題は、そのような制限緩和を行った結果、従来は小さなメモリーリークだったコードが、大きなメモリーリークに変化してしまう可能性がある。

// 大きなメモリーリークになってしまう例
class P {
  int x;
};
class Q {
public:
   Q(){ throw 42; }
private:
   int x[LARGE_NUMBER];
};
{
   P* p1 = new P();
   Q* q1 = new Q(); // bang :-(
   // don't get here
   delete q1;
   delete p1;
}

このコードは、bangの時点で、例外が投げられる。C++11までのように、すべてのnew式で、独立してメモリ確保がされるのであれば、Qで確保されたメモリは、オブジェクトの構築中に例外が投げられたことにより解放されるはずである。しかし、もしPとQのメモリ確保がまとめられるのであれば、Qを構築する部分のメモリもPと一緒に確保されてくっついているので、そのままリークしてしまう。

もちろん、このコードは、もともと間違いであるが、小さなメモリーリークを大きなメモリーリークにしてしまう変更はいかがなものか。そのため、そのような場合に対応するために、何やら変な条件が付け加えられた。

1786を参照。

[title要素のないHTML] N3905: Extending std::search to use Additional Searching Algorithms (Version 4)

現在、STLのアルゴリズムには、std::searchがある。しかし、検索アルゴリズムというのは、ひとつではない。特殊な文脈では、もっと効率的にうごく検索アルゴリズムがある。たとえば、Boyer-Mooreが有名だ。

一般に、これらの検索アルゴリズムは、検索を行う前に、検索準備のためのパターン構築処理を行う。この前処理にはコストがかかるが、検索をかける現実のデータには、たいてい偏ったパターンが存在するので、うまくはまれば検索を高速ができる可能性があり、前処理のコストを考えても、通常の愚直な検索にくらべてお釣りがくることもあるのである。

この論文では、このような検索アルゴリズムを、汎用的にサポートするために、std::searchに新しいオーバーロードを追加することを提案している。新しいオーバーロードされたsearchは、Search Objectという追加の実引数を取る。これは、検索に使われる前処理された結果生成される、何らかのオブジェクトだ。検索する際には、そのオブジェクトを使って検索を行う。

論文では、デフォルトの追加検索アルゴリズムとして、Boyer-Mooreと、その改良版であるBoyer-Moore-Horspool（オリジナルよりメモリ使用量が低いが、worst-caseパフォーマンスでオリジナルに劣る）を追加する提案をしている。

// N3905提案の例

// 従来の検索
auto iter = std::search( corpus_first, corpus_last, pattern_first, pattern_last ) ;

// 従来のコードの新しいインターフェース版
auto iter = std::search( corpus_first, corpus_last, std::make_default_searcher( pattern_first, pattern_last ) ) ;

// Boyer-Mooreによる検索
auto iter = std::search( corpus_first, corpus_last, std::make_boyer_moore_searcher( pattern_first, pattern_last ) ) ;

Boyer-MooreとBoyer-Moore-Horspoolは、比較関数とハッシュ関数の両方を必要とする。

論文筆者によるリファレンス実装が、GitHubに上がっている。

mclow/search-library

[PDF警告] N3906: ISO/IEC PDTS 18822, File System, National Body Comments

Filesystemライブラリに対するNBコメント集。回答は次の会議の後以降になるだろう。

N3908: C++ Extensions for Library Fundamentals, Working Draft

標準ライブラリのTS(Technical Specification)のドラフト。TSは正式な規格とは分離される。C++に対する実験的な拡張案を、すこし正式に提案する程度の位置づけという感じだ。これはC++標準規格とは別物で、実際にC++の正式な規格に入るわけではない。

[江添フレンドリーではないPDF] N3909: A SFINAE-Friendly std::iterator_traits, v2

iterator_traitsをSFINAEフレンドリーにする提案。

SFINAEフレンドリーの解説については、本の虫: 2014-01-pre-Issaquah mailingの簡易レビュー Part 1を参照。