ToDo:
http://shinh.skr.jp/m/?date=20091213#p05
このへんの挑発に乗ってくれたりしたので ぽこぽこ記録を潰してくれて、 さらにそれを潰しかえしたりする状態になって、 とても理想的に近い状態になってくれたのだけど、 ひたすらやっていたら腕がいたい。 しょうがないのでなぜかそのへんに転がっていた湿布をはる。
(04:16)
なんかこれよくわからんのは、 なんで一回でルートまで持っていっちゃうのかなーということ。 参照されるたびに splay を 1 step だけやるとかの方が 直感的に(本当に完全に直感だけど)平均的に速そうなイメージがあるのだけど。
ちゃんと調べたらどっかに書いてあるんだろうけど
(01:11)
http://yhara2.blogspot.com/2009/10/pro.html
golfer.pro とか取って Java で import pro.golfer.saru とかやりたいなーとか思ったけど 取られていた
(01:12)
とりあえずクリアタイムが1分切ってないステージは 相当遅いはずなので適当にアップデートしてまわる。 めんどかったのは
F49上とかF51左はできる気がしない。 あとF58とかはどうしようもない感があるけど 最初だけ奇跡的にうまくいけばなんとかなるのかなぁ。
(15:29)
http://twitter.com/mametter/status/6847358362
密接な関係にあるのはそうなんだろうけど、 具体的に今時の shellcode が何がどうなってるかとか 知らないからどの程度危険なのかとかよくわからんので気になる。
Safari ならいくつか現行で落とせるバグを把握してるんだけど、 そのうちいくつくらいが実際に邪悪なことに使えるのかな
(16:16)
終わった! ついでに色々整理した。 トップページに 257 個 <li> が並んでるサイトってどうかと思うよ! w3m user の僕は便利なんだけどねえ。
さて2つ目は version 情報とか。 これは update で変わりうるので、 直接実行サーバに聞くべき情報なんですよね…
(01:05)
http://d.hatena.ne.jp/shinichiro_h/20070129#1170022534
2年だと思ったら3年だった…
いいかげんユーザごとの統計が欲しい。 さて何が欲しいか!
ユーザのページはなんか JS でできてるからまぁあれでいいか… 良くないかもしれんが…
じゃあとりあえずこの2つか。
(22:59)
昨日のりはマシだけど まぁ休める日に休んどかんと回復する気配がないということで 会社休んで適当に build sheriff とかやりつつ F57 終了。
上は簡単だと主張してたけど7回くらいは上で死んだね。 まぁでもクリアタイム45分程度だったので まぁわりとさっくりだった。
リュック取ってないとかひどいなーと思いつつ F49 やったら奇跡が起きて一回で渡れた。 他のステージにも4つくらい取り残しリュックがあったことに 驚いたけどまぁ全回収。
ついでにイカと戦ってたら全捕獲できたので コレクション系のは全部そろった。 イカは F40 で戦うべきのようだった。 3回目出現時に自分に即座に当たってくるイカがいなくて、 出現個所にルアー連打で2匹程度回収できるパターンを なんでもいいから作ればやりやすいみたいだった。
(23:09)
かぜをひいた。 ひどい
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)
| 前 | 2025年 9月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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 | ||||
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ kinaba [償却時間計算量（最悪な操作列が来た時の平均計算量）を O(log(n)) にしたかったからじゃないかと思ってました。..]
_ shinh [あーなるほど。えーとでもすぷれー木をバランスが一番とれてない状態にするのって大変そうな気がするんですが、えーとそうな..]
_ kinaba [Wikipediaとかにありますが、小さい方から順番に１個１個アクセスしていくと一番崩れた状態になります。わりとよく..]
_ shinh [あーなるほど。 root まで持ってく splay を前提に小さい方から順番にアクセスしていくと悲惨な状態になるのは..]