N2670: Minimal Support for Garbage Collection and Reachability-Based Leak Detection (revised)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm
GC をサポートするほげほげ。下記が詳しい。
N2802: A plea to reconsider detach-on-destruction for thread objects
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2802.html
joinable thread のデストラクタで detach するのはやめてくれという話。全くです。 terminate() でいいと思う。
N2497: Multi-threading Library for Standard C++ (Revision 1)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html
pthread_self() が ostream::<< できるのが嬉しい。 thread::hardware_concurrency() とかも地味に良いなあ。
Mutex は普通のと、同じスレッドが何度もロックできるヤツと、 timeout できるヤツと。 reader/writer lock は無いのかな…
N2756: Non-static data member initializers
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2756.htm
欲しいよねえ。
N2751: Towards support for attributes in C++ (Revision 5)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2751.pdf
__attribute__ の標準化。 [[]] て…
[[attr1]] class C [[ attr2 ]] { } [[ attr3 ]] c [[ attr4 ]], d [[ attr5 ]];
attr1 applies to declarator-ids c, d
attr2 applies to the definition of class C
attr3 applies to type C
attr4 applies to declarator-id c
attr5 applies to declarator-id dうーむ。
[[attr1]] int [[ attr2]] * [[attr3]] ( * [[attr4]] * [[attr5]] f [[attr6]] ) ( ) [[attr7]], e[[attr8]]; attr1 applies to the pointer-to-pointer to function f, and to e attr2 applies to the return type of int attr3 applies to the return type * attr4 applies to the first * in the pointer-to-pointer to f attr5 applies to the second * in the pointer-to-pointer to f attr6 applies to the function variable f attr7 applies to the function (**f)() attr8 applies to e
うーむ…
N2347: Strongly Typed Enums (revision 3)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf
全然関係ないけど、 enum の名前出力とかできるといいんだけどなぁ…
N2750: User-defined Literals (aka. Extensible Literals (revision 4))
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2750.pdf
冗談みたいな提案名だよなぁ。
user-defined-literal:
user-defined-integer-literal
user-defined-floating-literal
user-defined-string-literal
user-defined-character-literal
user-defined-integer-literal:
decimal-literal ud-suffix
octal-literal ud-suffix
hexadecimal-literal ud-suffix
user-defined-floating-literal:
fractional-constant exponent-partopt ud-suffix
digit-sequence exponent-part ud-suffix
user-defined-string-literal:
string-literal ud-suffix
user-defined-character-literal:
character-literal ud-suffix
ud-suffix:
identifierあれ、文法定義はこれでいいのかな? string-literal って double-quote ついてるアレじゃないのかな?
追記: なんか全然何言ってるかわからん系の勘違いでした。
なんか欝陶しい問題が色々あるよ話。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2747.html
N2748: Strong Compare and Exchange
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2748.html
てか cmpxchg 入るのかぁ。そもそも失敗ってどういう時に起きるかとかわかってない。
N2427: Atomic Types and Operations
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html
こっち先に見ろって話だな。
load-locked store-conditional machines つーのでも実装できるからねーとか書いてある。まぁそういうものがあるらしい:
N2664: C++ Data-Dependency Ordering: Atomics and Memory Model
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm
下記も見るとなんで必要か…とかがわかるかも。
http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2176.html
r1 = x.load(memory_order_relaxed); r2 = hoge;
だと r2 = hoge が先に実行されるかも!
r1 = x.load(memory_order_acquire); r2 = hoge;
だとそれは絶対起きない。
r1 = x.load(memory_order_consume); r2 = hoge;
も似たようなもんだけど、 compiler が optimize をやめるだけで順序を保証できるようなマシンだと optimize をやめるだけですむので、こっちの方が速いかもね。
と理解した。えっと memory_order_acquire は何故必要なの…
N2754: Example POWER Implementation for C/C++ Memory Model
POWER による実例。 x86 で見せておくれ。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html
N2671: An Asynchronous Future Value: Proposed Wording
Io とかにあるような Future 型、っぽい。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2671.html
時間つきたので結論
PDF はやめてくれ。
