元スレ+ JavaScript の質問用スレッド vol.120 +

JavaScript覧 / PC版 /

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

101 = :

循環参照するって言ってる奴が、
循環参照しているという証拠を持ってくれば
いいだけの話だと思うがね。

なんだかんだ言い訳ばかりして最後には
証拠示せずに自分で考えろと言って逃げるだけだし。

102 = :

> 通常のオブジェクト同士の循環参照の話じゃないんだ

なんかまた変なコト言い出してる・・・

103 = :

>>96
JavaScriptのローカル変数はC言語とかみたいにスタックに積んでるわけじゃないからな？
スコープから抜けたときに必ず解放されるわけじゃない
>>64みたいに、スコープを抜けてもローカル変数を参照可能なクロージャーが生き残る場合には、
クロージャーと一緒にそのローカル変数の存在も維持されるぞ？

104 = :

説明じゃなくて、なんかツールかコード使って
循環参照しているって証拠出して。

105 = :

そもそもまともな(参照カウンタ方式じゃない)GCを実装してるプログラミング言語は循環参照なんて問題にならんぞ
iOSとかが糞すぎるんだよ
そしてJavaScriptの場合に問題になるのは古いIEのバグみたいなもので
DOM要素とJavaScript側の要素が相互参照してるときにだけ
相互参照を検出して解放する仕組みが働かないってだけのことだ

106 = :

GCが流行りだした頃は、
自分でdeleteしないなんて！って言われたもんだ。

かってにdeleteされることが嫌で自分で明示的に
deleteするべきだって主張していた人もいた。

だが今は、GCに任せるのが主流となった。

循環参照も同じで、自分で明示的に循環を断ち切らなくても
どこからも参照されていなければ、自動的に消える。

だから明示的にdeleteするのと同じで、循環参照であっても
自動的にdeleteされるのだからGCに任せることに何の問題もない。

107 = :

JavaScriptでも循環参照なんて気にしなくていいよ
古いIEとか無視でいい

108 = :

[['a', 'aa'], ['b', 'bb'], ['c', 'cc']]
のような多次元配列を作るにはどのようにすればいいのでしょうか？
ar = new Array();
aa = ['a', 'aa'];
bb = ['b', 'bb'];
cc = ['c', 'cc'];
ar.push(aa);
などでは実現できません

109 = :

> [['a', 'aa'], ['b', 'bb'], ['c', 'cc']]
> のような多次元配列を作るにはどのようにすればいいのでしょうか？

ar = [['a', 'aa'], ['b', 'bb'], ['c', 'cc']]

110 = :

>>108
var arr1 = [],
arr2 = [],
aa = ['a', 'aa'],
bb = ['b', 'bb'],
cc = ['c', 'cc'];

arr1.push(aa, bb, cc);
console.log(arr1); //[Array[2], Array[2], Array[2]]

arr2 = aa.concat(bb, cc);
console.log(arr2); //["a", "aa", "b", "bb", "c", "cc"]

111 = :

多次元配列、教えてくれてありがとうございました

112 = :

お前ら今日休みだな
昨日に比べてスレの勢いが全くない

113 = :

循環参照しないはもする派もプロファイルで数字を貼ってよ

114 = :

俺はわかるけどお前は勉強不足だからわかってないとか文系みたいな主張はいらねえんだよ
相手を納得させたいのなら数字を出せ

115 = :

>>90-91
いい加減なこと書くな

(function(global){
'use strict';
global.a = 100;
console.log(a);
global = null;
}(window));
console.log(window.a); // 100

116 = :

ｗｗｗ.

117 = :

お前ら今日何してた？
引きこもり？
それともJSの勉強？

118 = :

横山緑と鮫島の放送見てた

119 = :

循環参照をよく分かってないのに態度がでかい人がいるスレ

120 = :

循環参照とただの参照を混同している気がするね。

121 = :

>>115
それがどうかしたの？

JavaScriptのオブジェクトは参照型だから
>>115の例ではwindowとglobalは同じものを指すってだけだよ。
循環参照は関係ない。

122 = :

よくわからんけど、ちびくろサンボみたいな感じ？

123 = :

循環参照の例が全部イベントハンドラ関連でどうでもいいだろ
イベントハンドラなんて、ずっと束縛され続けるんだから

普通、循環参照っていえば↓これ
var obj0 = { value: 0, next: null };
var obj1 = { value: 1, next: null };

obj0.next = obj1;
obj1.next = obj0;
console.log(obj0, obj1);
↓
{ value: 0, next: { value: 1, next: [Circular] } } { value: 1, next: { value: 0, next: [Circular] } }

ちゃんと[Circular]って認識してる
認識してなかったら、無限ループでハングアップする

124 = :

問題になるのはページ遷移無しで動的にDOM要素を入れ替え続けるような
単一ページWebアプリとかの場合だよ

「古いIEにおけるDOM要素を含む循環参照によるメモリリークパターン」のことを
JavaScript厨が省略して「循環参照」と呼ぶから話がややっこしくなるんだよね
>>40みたいに

125 :

>>123-124は>>120みたいだな
DOMとスクリプトの循環参照は別だというのにソース出ててもなにも見てないと見える

126 = :

>>125は循環参照の本来の意味を理解できてないのね
>>123と>>124はただの参照の話などしていない

128 = :

>>127
省略せずに正しく「DOM要素とスクリプト要素の循環参照」と言えや
ただの循環参照と言ったら>>123みたいなことで、JavaScriptではこれは全く問題無い

129 = :

>>127みたいなのを循環参照っていうんでしょ？

130 = :

>>129
その>>127のページの最初の図で示してる状況は
JScriptスコープの変数とHTMLの要素が循環参照してるのが問題になるということ
それを「Internet Explorerリークパターンの内の循環参照パターン」と呼んでいる

仮にその図の変数obj3と変数obj4が互いに参照しあうような状況があったとする
その状況も「循環参照」だ。しかし「Internet Explorerリークパターン」では無い

131 = :

>>124
> 問題になるのはページ遷移無しで動的にDOM要素を入れ替え続けるような
> 単一ページWebアプリとかの場合だよ

そういうアプリでは動的にDOM要素を削除するので
その時に循環参照は断ち切られる。

132 = :

>>131
おまえ釣りだよな？
古いIEでは、DOM要素がスクリプト要素と循環参照してると、
そのDOM要素を動的に削除しても循環参照が残るせいでGCが領域を回収できないって話をしてるんだよ

133 = :

>>132
IEのバグの話はしていない。
そんなのJavaScriptの問題じゃなくて
特定のブラウザの問題じゃないか。

134 = :

>>132
> 古いIEでは、DOM要素がスクリプト要素と循環参照してると

ということなら、こういうコードは問題ないよね？

一見クロージャーを使っていて循環参照しているようだが（実際にしているが）
循環参照しているのは、DOM要素とスクリプトではなく、スクリプトとスクリプトである。

一旦addClickEventをかましてcallbacks変数に蓄えることで、
間接的にイベントハンドラを登録している。本当のイベントハンドラの登録はinit時の一回のみ。

function init() {
　var e = document.getElementById('id');
　e.attachEvent('onclick', onclick);
}
init();

var callbacks = [];
function onclick() {
　for (var i = 0; i < i.length; i++) {
　　callbaks[i]();
　}
}

function addClickEvent(callback) {
　callbacks.push(callback);
}

(function main(global) {
　global.addClickEvent(function() {console.log(global) }
})(window);

135 = :

dom要素がJSを参照するってどんな状態？

136 = :

DOM要素に関数登録するだろ

137 = :

話が変わってきたな。DOM要素につけたコードと
循環参照してるのが古いIEでメモリリークするのであって
循環参照そのものが悪いわけではなく
>>134みたいなコードなら問題ないわけか。

139 = :

jQueryのバリデーションのライブラリ探してるんだけど、今は何が良いの？
exValidationっての見たけど開発が止まっているようだ
最後の更新が3年前
validation-Engineってのは最終は2ヶ月前らしいけど
日本語対応してるのであればやっぱこの2つのうちどっちかなのかな？

141 = :

あ、ありがと
移動します

142 = :

>>128
勿論、そのほうが親切だけど、あの文脈ではDOMとスクリプトの循環参照しか思いつかないでしょ
>>83のようにぐぐればすぐHITするし、>>47にもURLが載っているし、誤解した人は調査不足でしかないと思うよ

で、問題あるかといえば、現在ではないけど
・バグを誘発しやすいから避ける人もいる
・無駄にクロージャを生産すべきでない
という2つの理由から敬遠してる
少なくとも>>64に関してはどちらも当てはまる

143 = :

懐かしい話題だったのでメモリリークパターンについてまとめました。
http://d.hatena.ne.jp/think49/20141005/1412514367
>>40,42 辺りの Function,prototype.call で循環参照を回避するパターンの答えにもなっているかと。

144 = :

jsとdomで循環参照するとメモリリークするとか
そんな話はじめて聞いたって思ったらie6sp2でだけ起きるのか

145 = :

一顧だにする必要ないな。

146 = :

http://d.hatena.ne.jp/babu_babu_baboo/20100417/1271465430

いわゆるクロージャを生成した時点で、関数 (innerFunc) は、変数 (e) を、
いつでも参照できるようになっている。なので循環参照が成立する。

これマジ！？
クロージャは外側の全ての変数のGCを止めるの？

147 = :

http://msdn.microsoft.com/ja-jp/library/bb250448.aspx

これを読むと、バグというより仕様だったのかな？
恐ろしい仕様だなあ

148 = :

>>146
それがクロージャの性質だし、その為に使う
この性質が分かっていない人が多いから無駄にクロージャを生産するな、といわれる

149 = :

関数の中で使われている変数だけが保存されていると思ってたけど。
じゃあ関数を返り値にする場合はローカル変数にも気を遣わないといけないのかね
面倒くせーな

150 = :

>>149
そんなことも知らずに使っていたのか
文句いう前に勉強しろよ