ToDo:
かぜをひいた。 ひどい
united から銀色のカードがおくられてきた。 エリートですセレブですVIPです
WebKit の勉強会がっとかいう感じで 3回くらい発作的に登録しかけたけど そのたびにああこれ使ってる側のコードリーディングかー という
http://twitter.com/niha28/status/6657239147
そんなに ABI うんぬんは困るかなぁ… たまに使ってるぶんにはわかるけど、 仕事で使ってたんならそんなに頻度ないような… まぁ批判それ自体の言いたいことはわかるけど もうちょっとこっぴどく叩けないもんなのか。 C++ 使ってる人間とか by definition で マゾなので本気で叩くと喜んでしまうから とかそういう高度なかけひきが行なわれているという説
http://lists.gnu.org/archive/html/tinycc-devel/2009-11/msg00003.html
何度も読もうとして MELT なんか面白そうじゃんとかいうところで止まる
なんか u さんがたまにメモリ無いかんじで死んでやがるので、 大変困るので u5 の方を最初に http が届く場所にしたい。 しんどかったので、そう思っているうちに休日は終わった。 残ったのは川背さんの記録だけだ
その関係で u さんのメモリ使用量増やす原因になる rail を捨てて tiarra に移行してみようとしてみたり。 これも中途半端なのでなんとかしようしようしよう
(19:53)
だいたいわかった!
でまぁ list が必要かという話で slist じゃダメなのだろうかと kinaba さんに聞いたら大丈夫じゃねとの返答のすぐ後に やっぱダメじゃねとのこと。 後ろ向きのリンクが無いと古いヤツ使った時に 移動が O(1) でできないからねー。
じゃあどうするかなーと考えたのは、
とか。 新しい要素が追加されずに 同じ要素が参照されまくったりするとたくさんメモリを使ってしまうので、 たまに O(N) の GC を走らせるといいかもしれない。
なんかもっと賢くやって欲しいよなー
(12:45)
http://d.hatena.ne.jp/melpon/20091212/1260584012
結構聞きたかったけど遅れていったので スライドを見た。
最後の3つの質問は全部問題無いように思う。 pthread_kill だけうざそうだけど そもそも pthread_kill は根本的に使ってはいけない気がするので、 根本的にどうでもいいんではないかと思う。
(16:36)
色々思うところがある感じだった。
よくできてそうだなーと思った。 複数スレッドでタスクキュー的に使えるのーとか思ってたらちゃんとあったし、 なんか strand というのを使うと synchronized 的なこともできるみたいだった。
http://www.boost.org/doc/libs/1_41_0/doc/html/boost_asio/tutorial/tuttimer5.html
個人的に Boost.Preprocessor 使わずに プリプロセッサプログラミングを最近ちょっとやってたので、 いくつか参考になった。
個人的にはこういうのコンパイラがやってくれると 結構うれしいんだけどなぁ。 たぶん実行がむっちゃ遅くなったりリビルドが必要になったりで、 デバッガの方がマシかなぁ的になっちゃうのかなぁ。
いいハナシだなーという話だった。 あとの雑談でよく喋ってたんだけど、 ただ、個人的には shared_ptr って滅多なことではいらんと思ってるんだよな。 適当な議論で適当な会話をしていたと思うので、 なんでそう思うかを書いておこうと思う。
結論的には、たぶん ownership の概念は本当に重要だってのは激しく納得していて、 そのことからいらんと感じてるんだと思う。
というのは ownership の情報というのは プログラムを読む人からすれば大変大変貴重で重要で大事で無いと しんじゃうそういう大事な情報で、 たぶんヘタしたら public/protected/private とかより重要なんじゃないかと そういうこうなるべくとにかく重要な情報で。
ところでどこでもかしこでも shared_ptr を使ってるプログラムは 明確に何かを誰かが持っている、そういうのがあるとしても さっぱりわからなくて、このオブジェクトの生死に一番関係してる子は 誰なのーてのが不明瞭になっちゃう気がするという話。
単に auto_ptr って書いてあれば あーこの子がこのオブジェクト持ってるんだなーとわかるけど、 shared_ptr だったらわからないじゃないですか！ それは困ります本当にわからないんです
ここで文句言ってるのは 「なんでもかんでもとりあえず shared_ptr 使っとけプログラミング」 であって、まぁ weak_ptr と使いわけてる人とかは まぁ別にいいんじゃないかと思う。
あとまぁ所有権が本当の本当に複数のオブジェクトに渡っているってのは、 そもそも設計が間違ってるケースも多いんじゃないかなぁ。 もちろん僕が思い出せる範囲で言うとツリー関係の処理とかだと 本質的に誰が何持ってるかさっぱりわからんくなるので、 まぁ必要なケースもたくさんあるとは思う。 ただ大多数のケースでは本当はいらないよね、という。
同じことは GC にたいしても言えると思う。 書いてるプログラマは楽になってるんだけど、 書かれたコードからは結構大事な情報が落ちちゃってる感があるのよね。
あとはまぁ shared_ptr ってたぶん統計的に GC より遅いんでしょ それ微妙じゃね…っていう貧乏症的感情と、 手軽に書きたいような書き捨てに近い C++ コードは そもそも free しないでもいいことにしているという 個人的事情も関係があるとは思う
しかしお前そろそろ大丈夫かという日本語力だな…
それ D なら…とか思っちゃう時点で 僕のこういう方向についての C++ への愛というのは 一体本当にどこに行ってしまったのか!
懇親会で kik さんに この関数定義されてますかーてのを調べる方法があるとかいう話をしていて、 「ええそれまさにどうやってやってるんか気になったんですよね」 とか言ってて kik さんにそのコードを見せてもらったら 「あーうん前 kik さんのコード読んだ時にそのやり方を覚えたんだけど忘れてますた」 みたいな感じで記憶やばいね。
メモっておこう。
http://github.com/shinh/test/blob/master/is_defined.cc
しかしこれも D なら…
これ 7 年くらい前ならむっちゃたのしかっただろうなー とか思いつつ、そのくらい前というと… という感じで思い出すのは kinaba さんのこれだなぁ
http://kmonos.net/wlog/22.html#_2112020801
「C++のtemplateについて３日間くらい夜を徹して誰かと語り合いたい気分」というやつ。 当時の僕はこれに激しく同意していた気がする、が、 今はそう思っちゃいないわけだ。
一つはやはりこう当時は template すごくねヤバイ可能性無限超広い。 って感じがあったんだけど、 まぁなんか一通りできることとできないことを大雑把に把握できて、 ほげほげの部分はふがふが言語の何々とちょっと似ていて、 とかまぁそういうのがある程度整理されちゃったのがあるかなぁ。
そうなっちゃうと、明らかな制限が色々ある C++ よりは、 D とかみたいに必要ならガンガン機能を 足していく考えかたの方が正しい気がしちゃうようになったんだよな。 C++ template はこう、実用品としての側面とは別側面として、 どういう言語機能が未来あればいいだろうかー的な実験として 色々な実験ができたっていうのもすごいところだと思うんだけど、 しかしそろそろその実験結果を元に言語作った方がいいんじゃないかなーと 思うようになっていった、というかんじか。
ていうかその後もうプログラム言語とかどうでもよくね、 と嗜好が変化していったのがあって、 まぁどんなプログラム言語でもとりあえず 俺の生産性をひゃく倍とかにはしないとか そういうことをなんとなく思っていったからだと思う。 あとなんか、言語の違いなんかより、 ライブラリであるとか、 OS のインターフェイスであるとか、 デバッガであるとか、 printf という一関数であるとか、 そいうとこの方が生産性に影響与えてるよなーとかそいうのも。
意味不明な比較だけど、例えば C++ の template と printf なら僕は printf をえらぶと思う。
さて Boost 。 Boost 自体はこう、ユーザとしては、あまり好きじゃないんだよな。 あまりに Boost を作るために Boost が作られているというか、 実用品としての何かが色々無い気がする。 コンパイルがあんだけ遅くなるとか実用品として致命的じゃね？ あーでも最近はこう実用方向のコンポーネントも増えたと思う。
一方で次の C++ に入れるライブラリの選定とか実験とか そいう意味あいでは好きで、まぁあの人たちは メタメタしいことをやっていればいいんだと思う。
C++ 自体は今でも好きで、それは単に C++ の実用品としての側面が あまりにこうやはり好きだということだと思う。 C++ template とかは僕の中で無限の世界ではなくなってしまったので、 今は多少キツくても色々遊んでみてちょっと無理して実用に供して、 何か面白いものを見つけよう！ 的なアレはなくなってしまったけど。
あとは Cryolite さんが言ってたと思うけど、 C++ 標準委員会に出されてる論文なのかよくわからんアレとか、 そいうのはとても面白いと思う。 それは C++ のユーザ数バカみたいにいるという側面の副作用で、 よく使われてるものだから、色んな偉い人が色々集まって アレコレ議論していて、その議論は色んな蓄積に基いた 面白いものであるというような、 そういう、プログラム一般についての教訓とかを学ぶ場所としての C++ も、まだ好きだと思う。
やまぁしかし Boost 勉強会は面白くて こいうのまた勉強するのも楽しそうだなーと 久しぶりに思った。
(17:56)
というような状態を圧縮して説明すると、 「C++とかどうでもいい」 という感じになるのはどうかと思った。 説明ゴルフ。
あとはまぁ興味を失なった部分はあるものの、 かといって勉強したことが意味がなかったかというと 別にそうではないと思っていて、 C++ から学んだものは本当に多いと思う。 それが他の言語からも得られると言われればそうかもしれないし、 もっと効率の良い方法があると言われればそうかもしれないけど。
(18:49)
とりあえずネットとかの記録と勝負しようとしても 絶望的な差にへこたれるだけなので、 身近でやる人いないかなーと色々声かけてみたら 結構会社でやる人が多くてしかもそれなりに速くて エンジニヤとかゲームやる子多いんだなーと思った。 しかし僕の求める僕よりちょっとうまい目標的な 感じには今のところなってないようなので困る。 しかもたいていの人と比較して僕の方が暇人なので、 なかなかたやすく追いついてきてもらえないかもという予想もある。
というわけで頭おかしい記録群と比較してみる…
http://eventer.jp/kawase/personal.php?name=
全体的に絶望的なんだけど、 無茶苦茶短いヤツはあまり意味が無いから無視して、 一応どうしようもない大差がついてないのを見ると…
つー感じか。 後者2つはあんま意味があるものでもないしきついなー
(21:18)
週末は十分な時間が無かったので F57 はとりあえず放置。 下半分行けそうな感じなんでまぁ時間さえあれば行けると思う。
へたれタイムアタックは F0 が最初のところが ちっとも安定しないのがほげほげ。 途中は段差延長がけとかしないでもこれ上届くんだなぁ。 だからと言って段差使わんとどうしようもないが
そんなことより grep と LRU がどうこう調べる
(01:17)
まぁなんらかのキャッシュが作りたいとして、 基本は hash map なわけだけど、 1000要素を越えたら一番古いヤツを消せるものができると嬉しいとする。
まぁ普通に考えると hash_map と hash_map::iterator をデータとして持っていて 最終更新時間が一番古いのが top に来るヒープがあればいいのかなーと思うんだけど、 まぁなんか二つデータ構造持つとかは2つが inconsistent になったりすると悲しいので、 なんか1つでなんとかできる構造があればすごいんだけど、 まぁなんか無いのかな。 無さそうだけど。
あともう一個思うこととして、 単に一番古いのを覚えておくために O(N) のメモリを 別に使うってのはなんかイヤだよなーということで、 それを最小化したければ、 hashmap を open hash で作っておいて ヒープの方に入れるデータは index にしておけば 1要素あたりの消費メモリが sizeof(void*)==8 より小さくなっていいのかなぁとか。
ところで今やってみて気付いたんだけど sizeof(unordered_map<int, int>::const_iterator)==16 なのね。 なんかこう 64bit 環境ですごいイヤなことの一つとして ポインタのサイズのせいで細かいオブジェクトがたくさんあるようなものの メモリ使用量が結構増えるってのがあって、 うーんそういうの的にやさしくない感じだなぁ。
(02:33)
そういえば会社で教えてもらった格言にすごくいいのがあったのでメモ
http://elise.com/quotes/quotes/shawquotes.htm
http://blog.malaysiacrime.com/2009/07/the-unreasonable-people/
The reasonable man adapt himself to the world. The unreasonable man try adapt the world to himself. Hence, all progress depends on the unreasonable man.
まともな人は世界に自身をあわせようとする。 まともじゃない人は世界を自身にあわせようとする。 よって、全ての進歩はまともじゃない人に依っている。
って感じか。 reasonable でいいよ
(01:37)
(05:33)
スタックをポップ
Shibuya って書いてあるから渋谷だと思ってたのにだまされた。 おかげで宮川さんのやつは聞けず。
メモをおこしておく。どっちかというと TODO 的な
他に思ったことを思い出す
(00:30)
http://www.aqi.co.jp/product/higurashi_jan/am/
http://www.aqi.co.jp/product/higurashi_jan/home/comicalize_2.html
こんなメディアミックスがー
僕のひぐらしのなくころに歴: 立ち読みでマンガを一冊、最初と最後だけ読んだ→ネタバレサイトでおおまかな結論だけ読んだ。僕ネタバレとか全然気にしないんだよねぇ
(00:34)
これを読んだ: http://d.hatena.ne.jp/yaneurao/20091126#p1
個人的にはまぁ wikipedia の記述でいいんじゃねと思った。 理由は反論されてるコメントとさして変わらず。 やねうらお先生の書いてる 「速度を気にするからこそ qsort でなくわざわざこれを使うわけで、 速いアルゴリズムを紹介すべき」 というのもまぁもっともだと思うんだけど、 しかし速度を気にする人はここが遅いなら書いてある程度の 最適化は自分でするんじゃないかなとも。
あとまぁ個人的には wikipedia のコードの方がわかりやすい。
一応ソートされてる配列に対して適当にはかってみたら、 2倍弱程度速かった。 たぶんキャッシュとかは関係なくて単純な命令数の差かなぁ。
http://github.com/shinh/test/blob/ccc56678832a0254670534266acad1a913b92c88/ins_sort.c
ざっとコンパイルされたコードの命令数を数えたところ、 ソートされてる場合のループあたりの命令数は 7命令と14命令だったと思うので、 まぁそんなもんなのかな。
(00:47)
sdl-fan-jp で youtube に色々動画があると教えてもらったのでひととおり見た。
特に bashrc が面白かった
http://www.youtube.com/watch?v=NBCnGUVi3zo
人の環境は面白いなあ。 最近突然 bash に乗り換えたい欲があるんだよね
(00:49)
F58 クリア。 結局ステージ後半が簡単で、 PS でクリアしたことがあったかどうかはよくわからんなぁ。 なんとなくステージ後半も記憶に残ってるような気がするし… プラクティスではクリアしたことありそうではある。 本番でのクリアは無いと断言できる。
メモ。
コンベア地帯がとにかく難しかったんだけど、 慣れると最初のところはどうやって失敗してたかすらわからんなぁ。
あとはドア的には F57 だけか。 こっちはコンティニュー一回までだからそれなりに練習しないといけない。 でも F57 は慣れれば割とラクだった記憶があるので なんとかなるだろう
あとなんかネットの記録とか見てもすごすぎてやる気が湧いてこない (昔は湧いてきたと思うんだけどね…)ので、 手頃な相手がいるといいなぁということで、 適当に会社で回りの人に真剣にタイムアタックしましょう！ と勧誘しまくったがどうもやってくれなさそうな感がある。
にはさんに期待したが
http://twitter.com/niha28/status/6168402003
なんてこった
http://twitter.com/niha28/status/6169184133
あとそういえばフラたんにも DS で出たよ! って教えたけど TAS った後は全くやってねーとのことだった。
(02:10)
次回チャレンジで F49 上行けるだろうなーと予想してたのだけど行けなかった。 予想通り2連リュックは3回くらい成功したのだけど、 なんかその後死んだりタニシにぶつかったり。 下の台の当たりうる位置に敵がわんさか出てきて ゆっくり調整できないし、 タニシの位置もいやらしいし、 案外2連の後も難しいのであった。
まぁ次くらいで行けるだろう。 あとあの 148 は扉の数とステージ数の合計なんだな。 それで計算があう。
あとはちょっとタイムアタック的にいくつかの面をクリアしてみた。 マジメにやったのは F0 くらいで、 51秒台が出た。
あと木金とだらだらしてて 定期的に回ってくるらしい、 webkit のコードを chrome に持ってくる仕事が微妙に残ってたので だらだらやりながら仕事してたらなんかコミットログが埋まっていた。 thanks giving とかなんとかで向こうは休みだからだろうなぁ。
http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=summary
(01:39)
クリアした！
2連目のリュック以降はデカい振り子作るなって話だな。 ただ焦りすぎて扉の右のリュック取り忘れたから もう一度行かないといけない。
これで 146/148 で F57 と F58 が残ってるだけか。 F58 は何度コンティニューしてもいいはずだから、 しばらく電源切らんでクリアしちまうかな。 このステージだけはクリアしたかしてないか 記憶が定かじゃないんだよな…
(02:48)
これと F58 のクリアを入れると、うーん 146 までしかいかんな。
なんかまだ奥に分岐があるんかな…
(01:54)
F50 => F30 超簡単と言いつつ F42 に相当てこずった。 1日に2回やるもんじゃないね。
F49 は結構練習してもできない。 リュック1個目はかなりうまくいくようになってきたけど、 2個目がむつかしいなぁ。 2個目から登るのは簡単なのかな。 まぁ2時間程度練習すればできるようになる気がするので明日。
旬 SE で F57 クリアしたってことは F57 もまぁ練習すればできるはずなんだけど、 安定する感じがしない F56 と連戦な上に F27 でも消耗しがちだし大変だなぁ。
数足りないのはそもそも 148 もドアあるわけないので、 リュックの数とかも含まれてると予想することにした。
しかし世の中には海腹川背ゴルフというのがあるのだね… これは面白い切り口というか低歩数クリアとかに通じるものがあるね。
http://www.youtube.com/watch?v=o05lDSLziUA
(03:04)
122/148 。いつのまにかだいぶ終わってきつつあるな
(02:01)
| 前 | 2025年 1月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 | |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ yutak [>キャッシュ Javaにはそのものズバリ "LinkedHashMap" というクラスがあります。この手のLRUキャ..]
_ もわ [HashMapの各ノードがprevとnextを持ったリンクリストにもなっているんじゃないでしょうか。今手元のJava..]
_ kinaba [Java なら http://commons.apache.org/collections/apidocs/org/..]