タグ

ブックマーク / nanto.asablo.jp (7)

  • 行数の数え方: Days on the Moon

    行数を数えているのですが、コメント欄他のstr.split(/\n/).lengthはかっこいいけどoverkill 404 Blog Not Found:javascript - String.prototype.tr() released 当でしょうか? 実際に試してみましょう。変数 s が対象文字列を指しているものとします。 // charAt var lines = 1; for (var i = 0, n = s.length; i < n; i++) if (s.charAt(i) == "\n") lines++; // Array var lines = 1; var chars = s.split(""); for (var i = 0, n = chars.length; i < n; i++) if (chars[i] == "\n") lines++; // sp

  • JavaScript で n 進数を扱う: Days on the Moon

    2 進数や 16 進数を使いたいというとき、JavaScript では組み込みの機能を利用できます。使えるのは 16 進数だけではなく、2 進数から 36 進数 (0 ~ 9 および a ~ z を使用) まで扱えます。 n 進数文字列から数値への変換 n 進数文字列から数値へと変換するときは、parseInt 関数を使います。第 2 引数に基数 n を指定することで、第 1 引数の文字列を n 進数であると解釈してくれます。n は 32 ビット整数に変換され、その値が 2 未満または 36 を超えるときは NaN が返ります。ただし、n が 0 になるときは文字列が 10 進数表記であるとして解釈されます。 parseInt(10, 36); // 36 parseInt("10", 0x100000000 + 36); // 36 基数が明示されておらず、文字列が 0 から始まっていた

  • Fizz-Buzz in JavaScript: Days on the Moon

    一部で Fizz-Buzz 問題がはやってるみたいで。私が anarchy golf の FizzBuzz 用に JavaScript で書いたのは以下の 58 バイト。ここにいたるまでには 2 分どころではない時間がかかってるけど。 for(i=0;i++<100;)print((i%3?"":"Fizz")+(i%5?"":"Buzz")||i) 今のところ JavaScript の最短は 56 バイト。どうすれば縮められるのかさっぱり思いつかない。 ちなみに、anarchy golf をやるときには大体以下のような変換をしていた。 変換前 変換後 差

  • length プロパティのパフォーマンス: Days on the Moon

    「for 文 2.0」(IT戦記) では length プロパティの評価をループの外に出すことにより高速化を図っています。DOM の NodeList オブジェクト (document.getElementsByTagName() などで取得) や HTMLCollection オブジェクト (document.forms などで取得) の length プロパティは「生きている」(オブジェクト取得後の操作が反映される) 、すなわち誤解を恐れずいえば評価のたびに数えなおす必要があるので遅いというのも納得ですが、JavaScript のネイティブオブジェクトである配列の length プロパティはどうなのでしょうか。実際に調べてみました。 以下は 10000 個の span 要素に対する NodeList オブジェクトと配列の length プロパティのパフォーマンスを調べた結果です。数値は

  • DOM Events とブラウザの実装: Days on the Moon

    ブラウザ上でのイベント処理の仕組みは DOM 2 Events および DOM 3 Events 草案にて規定されています。しかし、DOM 2 Events で言及されていない部分など、細かい動作はブラウザごとに異なっていることもあります。そうした仕様と実装の差異を、「作って納得! DOM 2 Events」で触れなかったものも含めて、いくつかまとめてみました。 ターゲットフェーズで呼び出されるリスナ DOM 2 Events のイベントモデルにおいて、あるノードでイベントが発生すると、そのノードの祖先ノードのイベントリスナが呼び出されるキャプチャリングフェーズ、そのノード自身のイベントリスナが呼び出されるターゲットフェーズ、再び祖先ノードのイベントリスナが呼び出されるバブリングフェーズと、3 段階にわたってイベントが伝播していきます。このうちターゲットフェーズでは、addEventLis

  • IE の getAttribute / setAttribute: Days on the Moon

    DOM の getAttribute / setAttribute メソッドは DOM Level 1 から定義されているメソッドで、MSDN Library によれば IE はバージョン 4 からサポートしています。しかし、IE での element.getAttribute(name) / element.setAttribute(name, value) というのは、基的には JavaScript における element[name] / element[name] = value のシンタックスシュガーでしかありません。ですから、element.setAttribute("innerHTML", "foo") とすると、element の属性には何の変化もないが element の内容が書き換えられるという事態になります。 この (手抜き) 実装が原因で、getAttribute

  • DOM オブジェクトとメモリリーク: Days on the Moon

    IE でのメモリリーク ちょこちょこと紹介されているので知っている人も多いと思うが、IE には DOM ノードに絡んだメモリリークの問題がある。これに関しては Microsoft 自身の記事である「Understanding and Solving Internet Explorer Leak Patterns」に詳しいが、簡単にいえば DOM ノードオブジェクトに関する循環参照を作ると、IE を終了させるまでそのオブジェクトが解放されないというものだ。記事によればメモリリークには以下のようなパターンがあるという。 1. 単純な循環参照 ある DOM ノードオブジェクトのプロパティをたどっていくと自分自身に行き着く場合。以下のようなパターンが考えられる。 element.property == element element1.property1 == element2, element2

  • 1