2010-08-29

post Rapperswil mailingが公開された

ISO/IEC JTC1/SC22/WG21 - Papers 2010

最新ドラフトは、N3126になった。もっとも、このドラフトには、今回のRapperswill会議で、変更すべきだと決定された変更の全ては含まれていない。まだ、細かい文面を考案中だからだ。

また変更点を確認して、いま執筆中の参考書の、すでに書き終えた部分との齟齬を確かめる作業が始まる。

N3103: Security impact of noexcept

単なる例示のためのペーパー。noexceptとマークされた関数が、例外を外に投げた場合、直ちにterminateする。このルールが守られない場合、具体的なある実行環境で、セキュリティ上の問題を引き起こす。したがって、かならず実装はterminateしなければならない。

N3106

min/max/minmaxにおける、文面の変更間違いの修正。

N3108

std::basic_stringの最適化手法として、現在主流の、small-string optimizationというものがある。詳しくは解説しないが、まあ、以下のようなものだと思ってくれればいい。

// charの文字列を格納するクラス
class String 
{
    char * ptr ; // 動的に確保するストレージへのポインター
    size_t size ; // ストレージのサイズ
    // 文字列長が十分に小さい場合、こっちを使う
    char small_string_buffer[8] ;
} ;

std::stringに格納する文字列が、わずか数文字というのは、よくあるケースである。そのような場合、特別にsmall_string_bufferを使えば、わざわざ動的にストレージを確保する必要がなくなる。

さて、std::basic_stringは、コンテナーの要件を満たしている。ところが、新しいswapの定義を満たそうとすれば、このsmall-string optimizationが使えなくなる。このため、std::basic_stringに限り、swap後のイテレーターが無効になるという条件を付け加えて、このような最適化ができるようにする提案。

N3109: US 108

C++0xにrvalueリファレンスを付け加えた目的とは、rvalueに対するMove semanticsのためである。auto_ptrのようなlvalueに対するMove sematnicsを提供するライブラリは、deprecatedである。そのため、unique_ptrのコンストラクターは、rvalueのauto_ptrだけを引数に取るようにする。lvalueのauto_ptrを引数にとるコンストラクターは削除する。

N3110: Problems with bitmask types in the library

iostreamのビットマスクとかアホすぎだから、付け焼刃的になんとかしようという提案。iostreamは設計自体が腐っているので、どうせアホなことには変わりないのだが。

N3112: Proposed Resolution for CH 15

Pittsburgh会議でMoveコンストラクターとMove代入演算子の意味を変えたが、その変更が、ライブラリの既存の文章に影響を及ぼしている。それに対する修正。

N3113: Async Launch Policies (CH36)

asyncのlaunchには、三つのオプションがある、async、sync、anyである。anyとは、asyncでもsyncでもない実装依存の方法ということになるのだが、そんなあやふやな定義では、ベンダーはまともに意味のある実装を提供することはできないし、ましてやユーザーは、ポータブルなコードを書くことができない。そのため、これを実装依存の識別子ということにする。

また、syncという名前は誤解を招きやすいので、deferredと改名する提案。

単に私の英語力が拙いだけなのかもしれないが、defferredといい、futureといい、どうも同期周りには、非ネイティブには、一見して意味の分かりにくい名称のライブラリが多い気がする。

N3114 - throw() becomes noexcept

タイトル通り、ライブラリのthrow()をnoexceptに変更する提案。

N3122: Observers for the three handler functions

C++0xには、マルチスレッドという概念が入る。そうなると当然出てくる問題は、データ競合(data race)である。このため、operator newとoperator delete、さらにCライブラリのcalloc/malloc/realloc/freeは、データ競合を引き起こしてはならないと規定された。

この制約は、ユーザーによるoperator newとoperator deleteのオーバーロードの際にも、当然守らなければならない。しかし、set_new_handlerは、値を変更しつつ、先の値を得るという仕様である。とすれば、set_new_handlerの仕様には、何らかの排他的処理を講じなければならないが、ユーザーコードとライブラリコードとの間での共通の排他的処理というのは無理である。とすれば、ユーザーコードのoperator newの中から、set_new_handlerが使えないではないか。

この問題に対処するため、new handlerをgetするためだけのライブラリが追加されることになった。get_new_handler()である。むしろ、今までないのが不思議だったのだが。さらに、get_unexpected()とget_terminate()も追加されるようになった。

また、set_unexpected()とset_terminate()は、nullポインターを私手はならないというルールを緩和することにした。しかしこれは、set_unexpected()とset_terminate()にnullポインターを指定するというコードの挙動を未規定(undefinedではなく、unspecified)にしてしまうのだが。

N3123: Bringing result_of near to INVOKE

result_ofの文面を、INVOKEを使って記述するようにした。

N3124: C and C++ Alignment Compatibility

alignment指定の文法を、attributeからspecifierに移す提案。これにより、alignasというキーワードが導入される。これは、specifierである。以下のように記述する予定。

alignas(16) char buffer[128] ;

N3125: Omnibus Memory Model and Atomics Paper

現在の企画の文面におけるメモリーモデルと同期処理の問題点を、ML上で議論していた。そのまとめ。

N3128: C++ Timeout Specification

clockとtimeoutの文面は、あまり宜しくない。というのも、ディレイというものが発生するからである。割り込みの間隔、関数から戻る、スレッドのスケジューリングなどのディレイを、quality of implementationと呼ぶ。また、プロセッサーやメモリーのコストを無駄に上げないためのディレイを、quality of managementと呼ぶ。とすれば、現実の環境におけるタイムアウトの実時間というものは、目的の時間 + quality of implementation + quality of managementで表されるはずである。規格でも、この概念を取り入れた文面に差し替える。

N3129: Managing C++ Associated Asynchronous State

Associated Asynchronous State周りの文面が分かりにくいので、新たなる用語を定義して、その用語を用いて文面を書き直す提案。

N3130: Lockable Requirements for C++0x

文面の細かな修正。

N3131: Compile-time rational arithmetic and overflow

Compile-time rational arithmeticが、結果は表現できるとしても、計算過程でオーバーフローを起こす場合はどうすればいいのか。たとえば、ratio_multiply<ratio<INTMAX_MAX,2>,ratio<2,INTMAX_MAX>>は、最終的に、ratio<1,1>と計算される。しかし、その計算過程で、オーバーフローを起こす。

提案は、以下の通りである。最終的な結果が表現可能であれば、合法である。実装は他のアルゴリズムを使うことによって、オーバーフローを回避することが推奨される。

N3132: Mathematizing C++ Concurrency: The Post-Rapperswil Model

この論文はすごい。すごいが、私はこの内容を理解出来ない。さしずめ、毎回髪型とヒゲが別人のように変わる、くらいおらいと (Cryolite)さん辺りなら泣いて喜ぶのではなかろうか。

内容は、FCDにおいて合意されたC++のメモリーモデルを、数学的に記述し、さらに、英語による対訳をつけたものである。

N3136: Coherence Requirements Detailed

Coherence Requirementsの追加。

C and C++ Liaison: Compatibility for Atomics

C言語とC++との間のatomicの互換性の比較。

4 comments:

Anonymous said...

規格は読んでないんですけど"新しいswapの定義"をというのはコンテナをswapしたあともイテレーターは有効なままであるということなんですかね?
どういう人が喜ぶのか・・・。

個人的にはイテレーター自体ハマりやすくてあまり好きじゃないですね。各コンテナのイテレーターが無効になる条件を覚えてる人なんているの!?って感じです。

江添亮 said...

コンテナーのswapというのは、
コンテナー内部のストレージやメンバー、Compare(setやmap)、PredとHash(unordered)、allocatorを交換するだけで、
コンテナーの各要素に対しては、コピーもムーブもswapもされません。
したがって、コンテナーのswap後も、イテレーターを有効のままに保つというのは、それほど難しい要求でもないんですね。
basic_stringのような最適化は、通常の汎用的なコンテナーの場合、役に立ちません。

別にライブラリの全仕様を覚える必要などないでしょう。ただ、必要になったら、必要な情報を調べられる能力があればいいのです。

Anonymous said...

>したがって、コンテナーのswap後も、イテレーターを有効のままに保つというのは、それほど難しい要求でもないんですね。

それはわかるのですけどそれを規定することによってどうメリットがあるのか想像力が足りないためわからないんですよね。
こういう規定の積み重ねが、
「さすがBoost!おれたちにできない事を(以下略」
につながってるんですかねぇ

江添亮 said...

規定できるものは規定しておかなければ、ユーザーがポータブルなコードを書くことが、到底不可能になってしまいます。