>>150
は？
今のモダンブラウザではそんなダセー実装してないだろ
馬鹿じゃねえの

でもDOM⇔JSエンジンの循環参照がリークになるかは、ブラウザがその辺を対策して
リークしないようにしてるかもしれないし、実際にリークしてるかを誰も証明してないな

しかもページ遷移すれば全部破棄されるから気になるようなリークにもならないだろ

>>151
アンカー間違ってない？
>>149の
> じゃあ関数を返り値にする場合はローカル変数にも気を遣わないといけないのかね
はクロージャの仕様そのものだろ

間違ってないが？
使われてない変数もクロージャになるのソースは？

function hoge(){
var a = 100,b = 200;
return function(){
return function(){
return function(){
return eval('a');
}
}
}
}

function moge(){
var a = 100,b = 200;
return function(){
return function(){
return function(){
return a;
}
}
}
}

console.log(hoge()()()());
console.log(moge()()()());

chromeのデバッガでトレースすると、evalを使う場合、function scopeにbも含まれている
使わない場合、function scopeにaしかない
このことから使われない変数はクロージャに保存されないと分かる

巻数かネストされていてもどの変数が使われるのかを把握しているようですが
どういう仕組みで把握していると思いますか？

>>152
> しかもページ遷移すれば全部破棄されるから気になるようなリークにもならないだろ
ページ遷移しても開放されないのがメモリリークなんだが、全然わかってないな

また循環参照のときみたいに勝手に言葉の意味を定義するアホが現れたな
メモリリークって言葉には、その現象がどういう範囲で生じるかなんて意味は含まれていない

そして、Internet Explorerリークパターンにおけるメモリリークはページ単位で発生する現象なので、
ページ遷移すればリークしたメモリは回収される
http://msdn.microsoft.com/ja-jp/library/bb250448.aspx

>>157
お前じゃねーか、全然分かってないのw

>>158-159
クロージャの事をまるで理解してないだろ。

---
"通常、関数のローカル変数と、関数を呼び出すときに使用されるパラメータは、関数自体の継続期間中のみ存在します。クロージャを使用すると、これらの変数とパラメータは、クロージャが有効である限り未解決の参照を持ち続けます。"
http://msdn.microsoft.com/ja-jp/library/bb250448.aspx
---

この挙動はクロージャの仕様であってバグではない。
クロージャは何もしなければ、ページを unload するまで参照を持ち続ける。
当然、IE6 SP2 だけでなく、Google Chrome でも Firefox でも同じ挙動になる(unload 時にローカル変数を参照すれば開放されてないことが分かるはずだ)。
IE6 SP2 は unload 時にメモリが開放されないから、window.detachEvent('onunload', handler) で明示的に開放してやってるんだよ。

>>160
おまえほんとにアスペだよなｗ
クロージャーのことなんて話してませんよｗ
DOMとJSエンジンの循環参照の話ですｗ

>>161
それだと>>>152の上と下の文が繋がらないだろ

> でもDOM⇔JSエンジンの循環参照がリークになるかは、ブラウザがその辺を対策して
> リークしないようにしてるかもしれないし、実際にリークしてるかを誰も証明してないな
>
> しかもページ遷移すれば全部破棄されるから気になるようなリークにもならないだろ
「どちらにしても循環参照を破棄する」ならメモリリークの有無を誰も証明してない文面がおかしい
もし、証明できるなら>>152がそれを証明しろよ

>>162
その三行のどこにクロージャーなんて書いてあるんだ
DOMとJSエンジンの循環参照はクロージャだけが原因だと勘違いしちゃってる？

メモリリークは証明するも何もMSの公式発表だ

このスレでアスペと発言する人は「自分の発言が期待通りに解釈する能力がない人」という意味で使ってるよな
自分の日本語がおかしくても伝わらない事に気が付いてないようだが

>>163
今までクロージャに纏わる循環参照が問題にされていたんだからクロージャと認識するのが自然だろ
突然、なんに脈絡もなく、クロージャ以外の話をして、それが何の話かも明言してない(目的語を省略)のに周囲に理解されると思ってんの？

>>165
DOMとJSエンジンの循環参照によるメモリリークはクロージャかどうかなんて関係無いんだよ
お前が勝手に同じ問題だと勘違いして議論に紛れ込んでただけだろ

>>163
ページ遷移時に破棄されることが証明出来てないでしょ

>>167
> 新しい Web アプリケーションは、より高い標準に従います。ページはナビゲートされずに何時間も実行され、
> Web サービスを通じて更新情報を動的に取得する場合があります。複合イベント スキーム、オブジェクト指向の JScript、
> およびアプリケーション全体を生成するためのクロージャを組み合わせることで、言語機能が限界点に達します。
> これらの変更およびその他の変更により、特定のメモリリークパターンが顕著になります。
> 以前はナビゲーションによって隠されていたメモリリークパターンは特に顕著になります。

実際アスペが多いから仕方ない

そもそもie6使ってる奴がいても普通はsp3にしてるだろ
ie6sp2のシェアなんてもはやほとんどないんじゃね

http://msdn.microsoft.com/ja-jp/library/bb250448.aspx のどこにページ遷移したらメモリが解放されると書いてあるんだろう
MS IE以外のケースもの気になる

chrome使ってるとページ遷移してもメモリ解放されてないと感じるな
ページ遷移のタイミングでは解放されない、というだけだが

>>171
「サイト内の異なるロケーション間のナビゲーションは解放されたメモリをクリーンアップする～」
って書いてあんぞ？

http://ja.wikipedia.org/wiki/Internet_Explorer_6
2013年以降、Internet Explorer 6をインターネットから新規インストールしようとすると
「ダウンロードの場所情報は壊れています。」とエラーが出てしまい、
新規インストールすらできなくなってしまっている。

もうこんなブラウザのことなんてほっとけよww

このスレは攻撃的な人が多くて嫌な感じだなあ
アスペとか荒れの火種でしかない発言は控えてほしいんだけどな

アスペは不愉快だから仕方ない

アスペの方から攻撃してくるからな
つい反撃しちゃうんだよ

クロージャ作成時にその中で使う変数を再帰的に同定しているということは、
その処理はかなり重いものにならざるを得ませんね？

関数は自分が使う変数のインデックスのようなものを内部属性として持ってるのでしょうか？

evalとかが無ければ静的な文法スコープなんだから
関数の定義を外側から内側へ構文解析していくときに
どの関数がどの変数を補足してるかは決まってしまうんじゃないの？

変数には再代入出来るので、やはり動的に決めているのでは？

意味がよくわからない
再代入できるとなんで動的に決めないといけないの？

aという変数に関数が入っていて
ある関数bの中でa()を実行していたとすると
どこがでaを別の関数に差し替えされると、それに従い関数bで使用される変数も変わります

aに代入された関数はそのaを実行する場所のスコープに存在する変数を補足しません
aに代入された関数が定義された場所のスコープの変数を補足します
これが静的な文法スコープというものです

実行される場所のスコープじゃなくて
定義された場所のスコープで補足する変数が決まる
だから構文解析の時点で補足する変数が決まる
だよね？

>>179
スコープチェーンでぐぐるべし

>>184
構成によるのでは？
もう一度コード書いて再質問推奨
どれが誰かわからん

alert("string "+a+b)
a,bはint
これって50,10だとすると
string 5010になるんですね

>>184
クロージャ内でaを呼んでいたらaはクロージャが作成された空間の変数を取り込むはずだが？
はい論破

と思ったら、確かめたところ、
既に作られた関数が外側から取り込むことはないようです
ナマ言ってすみませんでした

関数が定義されたときに、
現在有効なスコープチェーンを保存しておきます。
関数が呼び出されたときに、新たにオブジェクトを生成し、
ローカル変数を保存します。
そして、この新しいオブジェクトを保存しておいたスコープチェーンに追加し、
関数呼び出し時のスコープチェーンを表す新たなスコープチェーンを生成します。

とJavaScript第六版にありました

そこにwithがあったりすると…

%指定したiframeの高さをJavaScriptで取得したいのですが、うまくいきません。
iframeでメニューとメインコンテンツを作っていて、メニューは折り畳み式になっています。
デフォルトのサイズstyleのheightしていでhtml96%のbody100%のiframe100%です。
メニューは展開するとそのiframeからはみ出すことがあり、その時は当然そのifameにスクロールバーが表示されます。
ですが、私はこの場合両方のiframeのサイズを拡大してbodyにスクロールバーが表示されるようにしたいと思っています。

document.getElementById("menu").height; //menuはメニューのiframeに付けているidです。
でiframeの高さを取得できると思ったのですが、alertで表示させてみてもなにも出力されませんでした。
どうやったら%指定したiframeの高さを取得できるでしょうか？

>>134だけどレスついてないよね？

これで、IEの場合におきるメモリリーク問題は起きなくなるってことであってるよね？

よく分からないがDOMとハンドラの間に層を作るのはなんか気持ち悪い

気持ち悪いかどうかではなくてですね

domとjsの間では循環してないから大丈夫そうだね

>>196
やっぱりそうなんですね！ よかった安心しました。

そもそも論で悪いけど、DOM-script循環参照ってそんなに気を使う必要あるかな？
1秒間に数十個レベルで要素を生成してるならともかく、通常範囲なら気にする必要はない気がする
IE6なんてもう捨てていいだろうし…

あ、すみません。
良かったの理由を書いていなかったですね。


まず、ここまでの話をまとめると、DOMとスクリプトの循環参照、
これをやることは本来問題はないわけです。
クロージャーをバンバン使っていいわけです。

問題は循環参照そのものではなく、古いIEで問題があったというだけ。
でも>>134のようにコードの書き方を工夫すれば、
クロージャーを使っても古いIEで問題が起こらない。

で、実はこれって、jQueryを使った場合のコードなんです。
jQueryを使った場合、

function init() {
　$('id').on('click', function() {})
}

のようなコードを書くんですが、みてください。DOMとスクリプトの循環参照になっていません。
jQueryは>>134で書いたように内部で独自にイベントハンドラのキューを持っているんです。

内部で独自にキューを持っているのは、そのほうが軽かったり、イベントハンドラを削除する時に
関数を渡さないでも名前空間でばっさり消せるようにするため、だろうと思っていたのですが、
もちろんそれもあるのでしょうが、メモリリーク対策もあったのですね。

jQueryを使うだけで知らないうちにメモリリーク対策された、問題ないクロージャーの
書き方をしていたってわけです。

いままで書いたコードに問題がないとわかったので良かったというわけです。

>>199
ページ遷移しないWebアプリでDOM⇔JSエンジン間で循環参照したあとにDOM要素を
削除しても、ちゃんとGCされるのか？
結局、それを誰も証明してないわけで