はじめてのにき(2014-03-13)
_ GTR 天才的な連鎖を組む同僚が、GTRと称して面白い形を組んでたんだけど(かめさんの連鎖が元ネタらしい)、それを会社で適当にいじくりまわしてたらかっこいい形ができた http://www.inosendo.com/puyo/rensim/??400000570007760045766074745674554574545565466655 右発火で "GTR" として発火すると9連、左発火で "GTR" の部分を折り返しとして使うと 8 連全消し。この形だけ見ると、この後がすごく組みやすそうなので、すごくよい形な気がしちゃうけど、同僚いわくスキなく "GTR" の部分を組むのはかなり難しいとのこと。左から3列目の赤を一段下に置いて、 "座布団L字" ぽくなることも多いとかなんとか。 しかしこういうのを見ると GTR ってのはよくできたロバストな形なんだなぁとか思う。空から GTR みた
はじめてのにき(2013-11-12)
_ -fPIC と -fPIE 最近こういうこまかい調べたことをメモってなくて、たぶんよくないなあと思っている。というのは数年後忘れてるんで… 現状、 fPIC はたぶん fPIE より必ず強い制限というか、つまり fPIC でビルドすれば PIE として使えるバイナリになるけど、 fPIE でコンパイラしたバイナリはたぶん so として使えない場合がある。 両者の違いは TLS の扱いと自分の中での関数 call 。前者は shared object 用であるところの -fPIC の方が遅いけど generic なコードができるというか、 executable 用であるとわかってれば多少 optimize できる、っていうのが Ulrich の TLS 文章に書いてある。 自分の中での関数 call は -fPIC だと PLT 経由になるけど、 -fPIE だと直接呼び出しになる。まぁ
コード読むと良い - はじめてのにき(2013-06-10)
_ コード読むと良い そういえばそんな偉そうなことも言った気がする。けど別にコード読むのが特別良いとは思ってない。まぁ他の人が僕に比べてコード読まないと感じることは多い。そうそう shi3z さんの最適化の話とかすごいたくさんはてぶとかついてて、 twitter でもたくさんコメントされてたのに、誰もかけ算の回数数え間違ってると指摘してなくて、あの時もいやーホントみんなコード見ないもんだなと感心した。いや、僕も途中とかめんどくさいから最適化された後とされるコードしか見てないけど。 けど僕もそんな四六時中読んでるわけでもなくてもっともりもり読んでる人もいるし、あと読む派の人も色々ある気がする。 読む派の色々は、最初から最後まで全部読んでく人と、おおまかな設計とかを調べるのが好きな人、気になるとこの実装だけ細かく読む人、みたいなのがある気がする。僕は最後の派閥で、おおまかな設計の把握とかはあま
はじめてのにき(2012-04-09)
_ boost context http://partake.in/events/313b563f-acf7-47b9-908c-ee0461b77fc0 に行った。 @ytomino さんが boost_fcontext_align で -16 しているとさわいでいたので読んでいた。ごにょごにょと読んでいた結果として、これを読んでるコードは ss_base のアラインにしか使われておらず、これは確保した直後のメモリ領域をアラインする用途にしか使われてないから 16B ほど無駄な領域がある程度で無害なんじゃ、と思った。 なんかうさんくさいコードがあるとそのコードを読むわけで、うさんくさいコードを残しておくと他の人のコードリーディングをうながせるので素晴らしい、という持論が証明された感じである。 github とかにコード上げる人はうさんくさいポイントを残しておくといいよ! とアドバイスした
はじめてのひき - ClassNaming
この世は荒野なので関数とかクラスの区切りなんかに悩みます。適当にいじってください。 略語と camel case toXML か toXml かという問題 先頭以外は全部に小文字にしろ派 toXml Graphics3d Md5 Sha256 UserId? Uid GccRunner? XmlHttpRequest? Md5 とか Graphics3d は抵抗がある人が多そう。 3d は glVertex3d では double の意味なのでややこしいという意見が。 略語は全部大文字派 toXML Graphics3D MD5 SHA256 UserID UID GCCRunner XMLHTTPRequest 略語が終端に来ると読みやすいように思うけど、まだ他の語が続く場合は読みにくいと思われる。特に XMLHTTPRequest のように略語が続くとキツい。 3文字以下なら全部大文字
TCC で遊んだ話と x86-64 とはまじしん一ろう- TCC で遊んだ話と x86-64 と
1/64 >> First Last TCC で遊んだ話と x86-64 と はまじしん一ろう
はじめてのにき(2010-09-14)
_ duck typing http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1146611996 via http://twitter.com/kmizu/status/24476568147 見てて、あれ、俺 duck typing が嬉しいと思ったことあったっけ… と思った。 なんかやたらと元質問者に同意するんだよね。 Ruby では… 真剣に無い気がする。なんかわざわざ interface ぽい class 書いたりしてる気がする… そりゃ inspect とか to_s とか to_str の恩恵は受けてるけど、まぁ interface があってもいいよなー コンパイル時 C++ … これは interface 的なもの作る手段無いから、しょうがなくやってるだけって気がする… OCaml … OO したこと無い はて
はじめてのにき(2010-07-06)
_ 1.5倍とか http://www.kmonos.net/wlog/111.html#_2334100705 なんかこの話は gus さんと何度かしたのでなんか書く。 結論としてはなんか C++ が残念な気がするという話なんだけど、 メモリアロケータの実際とか自信無い面があるので少しあやしい。 全く測定とかはしてないし。 まず、要素数が少ない時。 この時はどうせメモリアロケータ的に 穴もへったくれもなくてサイズごとのプール使ってるんじゃないのか。 そしてキリのいい数字の方がサイズごとのプールにちょっきり入りそうだし、 倍々でいいんじゃないの。 次に要素数多い時。 なんか mmap しはじめるはず。 ということで使い捨てたメモリは munmap されるだろうし やはり依然として穴とか関係ない感がある。 ただやはり瞬間的に要素数 * 3 のメモリが必要になるわけだし、 このへんになると直感
C++ の吐く機械語 はまじしん一ろう - C++ の吐く機械語
1/25 >> First Last C++ の吐く機械語 はまじしん一ろう
まかーになりました
説明 まかーになったので、その記録とか作ったソフトとかを。 作ったもの sevil 好きな位置にウィンドウスイッチしたり、 ウィンドウをキーボードから動かすためのもの。 ついでにアイコン化とかそのへんもできます。 ソースコード (ver.1.0) (for Snow leopard and Leopard) 。 ソースコード (ver.0.3) (for Tiger) 。 説明とか 。 少し遅いのが難点なのですが、今のところまぁ快適です。 sevilwm が元となっています。 w3mimg w3mimg は OSX の環境に対応してません。 だから作りました。 ソースコード (ver.1.0) (for Snow leopard) 。 ソースコード (ver.0.2) (for Tiger) 。 screen ユーザーやタイトルバーの幅が違う人は各自 w3mimg_cocoa.m の 先頭
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
glibc signature quiz
コードを愛でる - コードを愛でる
http://shinh.skr.jp/binary/fsij061115/index.cgi?i=0