タグ

ブックマーク / kilrey.hatenadiary.org (10)

  • デフォルトって? - うっくつさん本を読む。

    ありがちダメなコードのダメな理由を書くコーナー。 char const* getNameFromID(int id) { switch (id) { case ID_FOO: return "FOO"; case ID_BAA: return "BAA"; default: return "TEST"; } }ID_FOOを受け取った場合に"FOO"、ID_BAAを受け取った場合に"BAA"を返すという関数、というところまでは良い(役に立つかどうかは別として)。問題はdefault時に返す"TEST"の存在だ。 まず「正しい動作」を確認しなければならない。このソースコードから逆算すると次の三つくらいはありえるだろう。さて、どれが「正しい動作」なのだろうか。 ID_FOO,ID_BAA以外のときは"TEST"を返す。 ID_FOO, ID_BAA以外のときは未定義。 ID_TESTのときは"

    デフォルトって? - うっくつさん本を読む。
  • エラー握りつぶし - うっくつさん本を読む。

    ありがちダメなコードのダメな理由を書くコーナー。 #include <stdlib.h> #include <math.h> #include <stdio.h> int mysqrt(int x) { if (x < 0) { return 0; } else { return (int)sqrt(x); } } int main() { printf("%d\n", mysqrt(4)); printf("%d\n", mysqrt(1)); printf("%d\n", mysqrt(0)); printf("%d\n", mysqrt(-1)); printf("%f\n", sqrt(4)); printf("%f\n", sqrt(1)); printf("%f\n", sqrt(0)); printf("%f\n", sqrt(-1)); return 0; }をコンパイルし

    エラー握りつぶし - うっくつさん本を読む。
  • 挿入ソートの話のまとめ - うっくつさん本を読む。

    gcc4.3 -O3 on Atom, N=10000の条件で挿入ソートを測った結果(ソースコードは下に)。所要時間(time)を測っただけでは振る舞いが掴めないので、cachegrindでD1キャッシュ読み回数(D1read)を数えてみた。 関数 メモリ time D1read yane0 malloc 9.79 62M wkpd0 malloc 9.82 27M yane1 static 8.09 27M wkpd1 static 11.35 28M 大規模なソートということでmallocで確保したメモリをソートする場合、最適化がよく効いている限り、どちらもほぼ同等の速度で動くようだ。 ただし、やね版はstaticに確保したメモリをソートする場合、Wikipedia版よりも約3割速く動いた。ほぼ人の言っている通りの成績だ。 〆。 とはいえ、jのオフセットや番兵のありなしで20%くらい

    挿入ソートの話のまとめ - うっくつさん本を読む。
  • 挿入ソートの話の途中経過 - うっくつさん本を読む。

    Atom/gcc -O3だとループ変数をj=iからj=i-1に変えるといった、質的ではない変更でも20〜30%の速度変化が起こり得るようだ。これはiccで比較してみた方が良いかもしれない。それらを含めた印象としては Wikipedia版もやね版も最適化がよく効いている場合には大差ない。 やね版の方が最適化に失敗することが少ないようだ。 というところ。 余談。 要素数の少ないソートを想定していたのか。巨大なソート済み配列への追加なら「当たり前だけど、二分検索+memmoveの方が速いよなあ」という結論で終わろうと思っていたのに。

    挿入ソートの話の途中経過 - うっくつさん本を読む。
  • 2009-11-18

    http://d.hatena.ne.jp/kilrey/20091111#p2の話。 function tarai (x, y, z) { if (x <= y) { return y; } else { return tarai(tarai(x-1, y, z), tarai(y-1, z, x), tarai(z-1, x, y)); } }; for (var i = 0; i < 0x10; ++i) { (tarai(12, 6, 0)); } print(tarai(6, 3, 0)); print(tarai(12, 6, 0));goとよく似ている……と思ったら実行速度までほとんど同じだった(8g & 8lと比較)。 ありがちダメなコードのダメな理由を書くコーナー。 現象。 C99のソースコード(tmp.c) #include <stdlib.h> #include <s

    2009-11-18
  • マルチスレッドのvolatile - うっくつさん本を読む。

    ありがちダメなコードのダメな理由を書くコーナー。 現象。 C99+POSIX(SUSv3)のソースコード(tmp.c) #include <stdlib.h> #include <stdio.h> #include <pthread.h> volatile int count = 0; int const COUNT_PER_THREAD = 0x100000; int const THREAD_NUM = 0x10; void* work(void* arg) { for (int i = 0; i < COUNT_PER_THREAD; ++i) { ++count; } return arg; } int main() { pthread_t threads[THREAD_NUM]; for (int i = 0; i < THREAD_NUM; ++i) { if (pthread

    マルチスレッドのvolatile - うっくつさん本を読む。
  • 日本語文法では音便や省略が重要 - 2009-10-22 - うっくつさん本を読む。

    http://d.hatena.ne.jp/kanimaster/20091022/1256217225に書いたブックマークへの追記。 「おいしいです」はやや崩した表現。「おいしゅうございます」の方がより丁寧。選択肢としては「おいしいのです/おいしいんです」も。 「おいしいのです」は書き言葉、「おいしいです」や「おいしいんです」は話し言葉。 「おいしいです」という表現は「おいしいのです」が元々の形だと私は思っている。「おいしいのです」が撥音便化*1して「おいしいんです」、さらに撥音が省略*2されて「おいしいです」となったのではないだろうか。 さらに、発声が表記通りとは限らない、という点も考慮するべきだろう。私が思いつく限りでも オイシイノデス オイシインデス オイシインデス(「ン」が弱く短い) オイシイデス という四つの発声がある。「オイシインデス(「ン」が弱く短い)」と「オイシイデス」と

    日本語文法では音便や省略が重要 - 2009-10-22 - うっくつさん本を読む。
  • C言語で多値返却 - うっくつさん本を読む。

    ちょっと古いけどhttp://d.hatena.ne.jp/yuyarin/20090825/1251136545の話。 C標準では。 C言語の仕様レベルでは多値返却にもっとも近いのは構造体の値返却だ。複数の値を返すという用途は充分に満たしている。 struct int_int_t { int x; int y; }; struct int_int_t func(void);しかし、構造体の値返却は同じ構造体を用いて受け取らなくてはならない。例えば int main() { int x; int y; <x, y> = func(); ...do somthing... <y, x> = func(); return 0; }という処理はC言語には存在しない。 ゼロ・オーバーヘッド。 受け取る側が構造体ならアドレスを受け取ってmemcpy()するだけで済むが、受け取る側が変数二つからなる多

    C言語で多値返却 - うっくつさん本を読む。
  • 意図としてのコメントはこう書く - うっくつさん本を読む。

    コードコメントに書くべきは「意図」 - プログラマーの脳みそ、ソースコードの心脳問題 - プログラマーの脳みその話。 初心者のコードでも、意図が書かれているならレビューは容易に行える。意図不明のコードほど手に負えないものはない。 「コメントとして意図を書け」という論旨には全面同意なので、意図としてのコメントはこう書く、という手法の一例を書いてみる。 目的 その関数/変数は何をするものなのかを書く。 /** * 最大公約数を求める。 */ 仕様上の制限 静的型付き言語なら型自体が入力仕様の役割を持つ。しかし、一般の用語をそのまま実装するのは機能過剰だと思われる場合、仕様上で制限を加えるのが望ましい*1。 /** * 最大公約数を求める。 * * 数学上の定義では任意個の数値に対して最大公約数を定義できるが、 * 関数は二つの数値に対してのみ適用できる。 * また高速化のため、ソート済みの引

    意図としてのコメントはこう書く - うっくつさん本を読む。
  • 2009-09-10 - 問題はエンコーディングではないのだ

    http://itpro.nikkeibp.co.jp/article/COLUMN/20090208/324377/?ST=security&P=1からhttp://d.hatena.ne.jp/tohokuaiki/20090910/encodingの話。 ベースライン。 Webアプリケーション、ここでは一般的な用法として次の条件を満たすもの、の話に限定して進めよう。 サーバ・クライアント型のアプリケーションである。 http経由で通信する。 サーバ・クライアント型。 間に通信層が挟まっている以上、通信層の信頼性を考慮しなくてはならない。 限定少数の利用者しかいない有線LANならば、パケット化けは起こるとしても、意図的な攻撃を想定する必要はないかもしれない。利用者が増えるにしたがってワームに感染したPCが混じっている可能性も高まるだろう。無線LANならば管理者の気付かぬうちに利用端末が

    2009-09-10 - 問題はエンコーディングではないのだ
  • 1