2012年12月13日 (木)「Linux KernelのLinked Listの実装が面白い件 - 愛と勇気と缶ビール」■残念ながら見たことのある実装でした(そりゃあソースが有名すぎるから)。なんでそういう変則的な実装が求められたのかが知りたいね。リストの定義が使用例(アイテム型)ごとに増えていくのを嫌ったんだろうか。マクロでは見かけは統一できてもコードサイズが増えそう？ C++だと、マクロの代わりが List<item>みたいな素直なテンプレートになって、このLinked Listのようなのは Thin Template(en.wikibooks.org)で実装するの？(あ、これも見た目は List<item>だ)■ところで container_ofの一行目の目的がわからない。ptrも __mptrも一回しか評価されないように見えるし、ptrと __mptrの値は同じだし、__mptrは char*にキャストして使われるから型変換が目的でもなさそうだし。ptrから __mptrへのキャストで値が変わることがある？■これが真相？「The first line is not intrinsically important for the result of the macro, but it is there for type checking purposes.」先月のポスト。ひと月早かったら答えが見つからないところだった。■値が同じどころか型変換が行われない(のが正常)というところまで気がついて然るべきだった。メンバ関数型やらクラスキャスト(up/down/cross)がごっちゃになってたもよう。■好きな名前をつけられるなどの他にこういうメリットもあるとか。「4. You can have multiple lists!」■■■@2014-10-09『省メモリプログラミング(Small Memory Software)』に Embedded Pointersというパターンが載っている。まさしくリストのポインタをリストされるデータに埋め込むような方法のことだ。intrusiveな設計ゆえのデメリットはあるが、リストされるデータを指すポインタと次のノードを指すポインタがひとつにまとめられる利点と、(それと同じことだが)メモリ確保が一度で済む利点がある。たぶん設計とコーディングを同時並行でやってるとデータが次データへのポインタを持っているなんてことは自然に起こっていることだろ。一度リストとしてのデータと操作を単独で確立してからそれを埋め込むようなことをしているから「あれっ？」となるわけで。
2012年12月12日 (水)最近は Sony Readerの出番がますます増えていて、重たくて開くと場所をとってページを押さえるために手が塞がる紙の本を読む機会が減っている。自炊対象外のハードカバーと大判の単行本の積読が減らない。購入量は減ってる。■本棚に並ぶ読み終わった単行本の背表紙は眺める価値があるけどね。記憶の宮殿。■明るくて暖かくてお茶が飲めるけど、実体がなかったりヒステリックだったりする笑い声にあふれたテレビがうるさい部屋の居心地が悪いのが悪いと責任を押しつけてみる。
