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の互換性の比較。