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

JavaScript覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

851 = :

>>844
それぞれ最適化の手法がちがうんだからケースによって差が出るのは当たり前だろう
随分不毛な言い争いが続くとおもってたら吉火狐信者が暴れてたんだな

V8やnode.js、これらは今のweb界隈の宝だよ
いつ消滅してもだれも困らないFireFoxにしがみつくのは勝手だが質問スレ荒らすのはやめような

852 = :

>>850
おまえ本当に発達障害かなにかか？
ここまできても話のコアがまったく分かってないな
チョコレートケーキはケーキがベースであり、焼き菓子もベースなんだよ
どちらかを振り回してもう一方を否定してる姿が滑稽すぎるって話だよ

要するにおまえが哀れってことな

853 = :

>>849
申し訳ないがよく理解できない
エンジン内部でjsコードをコンパイルして実行するときに
あるオブジェクトのあるプロパティの操作とか固定のものを内部でキャッシュしたりしてて
ベンチのような特定の何かを超回数ループだとキャッシュが効くから早くなるけど
そうでなければキャッシュが効くなくなる
という感じでいいのかね

854 = :

>>852
何が言いたいのか全くわからん。
ベースにこだわりたいんか？

BlinkとWebkitは（2014年時点ですでに）半分以上
違うものだってのがいちばん重要な点だろ

ベースのベースのベースのベースは
ぜんぜん違うものなんだよ。

855 = :

> チョコレートケーキはケーキがベースであり、焼き菓子もベースなんだよ
この例えも変だし。
これはベースじゃなくて単なる包含関係
カテゴリにすぎない

856 = :

>>853
V8はプロパティに高速でアクセスする隠しクラスをJITに仕込んでいるんだが、
それが静的型付けを前提にしているからプロパティを付け足すだけで低速化するって話

最小構成で環境が固定されてるベンチでなら速く動くが、フレームワークやライブラリ挟んで規模を広げた実際の環境では極端に遅くなる仕様だよ

857 = :

>>854
webkitベースじゃん
バカなの？

釣りかとおもったが真正の吉外かよ

858 = :

>>856
実際に他のブラウザと比較してどの程度の速度ななるのかデータはないの？

859 = :

フォークとベースは違うものだよ。
ベースは日本語で基礎を意味する言葉だが
その言葉の通り、ある製品の基礎になっていれば、それはベース

あるライブラリを使用した別のライブラリは、あるライブラリをベースとしていると言っていい。
例えば、jQuery Mobileフレームワークは、jQueryをベースとしてる。

しかしフォークの場合は違う。BlinkがWebkitを含んでいるわけじゃない
BlinkそのものがWebkitと同等のもの。
だからBlinkはWebkitをフォークして作られたものであってベースとはしていない

860 = :

>>857
BlinkはWebkitをベースとしていない
Webkitをフォークしたものだ。
そして2014年時点で半分以上入れ替わっている。

861 = :

>>856
先生、念のため質問させて下さい
「膨大な量のelement.style.***へのアクセスの高速化とかで
　役立っていてベンチ最適化現象はただの波及効果」
って線はないもの？
実用性なのかベンチ特化性なのか判断できない自分

逆にそういう仕組みだと大きいオブジェクト/配列を作って
データを追加していったりするとアホ程重いとかになるのかな
prototype作って回せといわれればそれで終わりな気もするけど

862 = :

>>859
>>860
いい加減見苦しい

863 = :

ただの偏屑かよ

864 = :

>>862
見苦しいのはお前だよ

865 = :

>>858
わざわざ書いてやったんだから>>849をChromeで動かしてみろよ

867 = :

上の方で出てた無名関数とかの話ってES2015を使えるような環境だと普通にクラス構文使えるし特にメリットなさそうなんだけどどう？

868 = :

Wevkit切り捨てはモバイルサイト切り捨てといってるようなものだが、今時珍しい考え方だな

869 = :

javascriptって数ある言語のなかでも一番テクニカルで難解な言語なのに、スレに居座るのは素人丸出しの池商多いよね

870 = :

JavaScriptは繰り返しをループでも再帰でも書けると思いますが、
こういうときは再帰の方がいいよとか、その逆があれば教えてください
今気になってるのは条件によって途中でループを抜けたいためにforeachが
使えないような繰り返しは、単にforやwhlieでまわすより再帰の方が
すっきり書けるのかなとかそれくらいなんですが

871 = :

>>870
スタックの無駄遣いだろ

872 = :

>>868
今はBlink or Webkit2
Wevkitのシェアは０

873 = :

>>870
ループで纏まりきらなくなってきたら複数の関数の再帰に分割すると良いことがある

874 = :

>>869
理解しなくてもそれなりに使えるって事はある意味理想的なんじゃないか?
つうかJSの挙動マスター出来てたとしても、
ここで暗黙の型変換利用したトリッキーな技使います、セミコロン省略します、プロトタイプベースOOPします、とか言うと大批判間違いなしでしょ。

875 = :

>>870
再帰を使うぐらいなら、for,while,for-ofを使うけどね
関数を使いたいなら、Array#someを使えばいいじゃない

876 = :

>>875
obj = {children:[obj,obj...]}

function sendChildren(obj){
　for(let child of obj.children){
　　sendChildren(child);
　}
}

こういう処理を再帰無しで書くにはどうすれば良いの？

877 = :

パフォーマンスの問題だろ
あんまりループをネストしたりして余りにでか過ぎる関数作ると殆ど最適化してくれ無くなるからな
反対に極めて小さな関数で有れば完全に埋め込んで最適化かけてくれる
一方再帰中に全変数で最適化のためのマイクロタイプが絶対に変化しないようにするのはちょっと大変

878 = :

>>876
それのどこが「条件によって途中でループを抜けたい(>870)」なの？

879 = :

>>876
無限ループ内で自分でスタックとか管理してオブジェクトを見渡せば出来る

880 = :

>>876
仮想コードにしても動くコードにしてから張り付けて貰えないもんかね
こっちに足りない部分を補完させて「それは違います」なんて言われても困るし、面倒くさい

881 = :

>>876
仮想コードにしても動くコードにしてから張り付けて貰えないもんかね
無駄な手間を回答者に押し付けるなといいたい

882 = :

投稿できてないと思って二重投稿してしまった、すまん

883 = :

多次元配列の一次元化アルゴリズムをここの奴らに聞いても無駄だよ

そのコード僕ちゃんのブラウザに貼り付けても動かないぞって底が知れるような文句付ける奴ばかりだから

884 = :

> そのコード僕ちゃんのブラウザに貼り付けても動かないぞって底が知れるような文句付ける奴ばかりだから
お前さんは>>876のコードが動くブラウザを使っているのか？

885 = :

>>876
element.children[0].children[0] なら [0,0,0] のように index 値を管理すれば再帰なしでも書けると思うよ

886 = :

>>884
抽象化されたコードくらい頭の中で実行しろよ

お前がほざいてることは数学の授業で「yって何ですか、電卓にyなんてありませんよ」と訊くくらいレベルが低いと知れ

887 = :

え、お前らこの程度のコードをわざわざコンソールに貼って実行してるの？
ちょっとドン引きなんですけど

888 = :

また自分より下を作ろうと必死なカスがわいてるのかよ

889 = :

>>886
>>876は無限にchildrenを参照し続けるだけで止まる気配がないんだが(多次元構造を参照したいという意思だけは伝わるがね)
このレベルの質問者にアドバイスだけで作れるわけはないが、動くようにコードを補完してやるのが面倒くさい
「アドバイスしか出てこない→質問者が分からない」という未来が透けて見えるぞ

890 = :

あと、まあ抽象化されたコードだkで伝わるというなら、抽象的な回答だけで質問者に伝わらないと公平でないよな
それで伝わるとは思えん質問だから解決するわけがないんだが

>>887
コンソールで実行するまでもなく動かない事は自明じゃないかね

891 = :

>>889
馬鹿なお前の為に書いてやったぞ

const obj = {children:[{children:[]},{children:[]}]};

function sendChildren(obj){
console.log(obj);

for(let child of obj.children){
sendChildren(child);
}
}

sendChildren(obj);

無限に参照し続けるってむしろお前がどんな補完したのか気になるわ

892 = :

>>891
const obj = {children:[{children:[1]},{children:[2]}]};
にして実行してみな

893 = :

無限に参照はいいすぎたが、「無限に参照し続けるうちに例外で止まる」が正しいな
childrenはDOM関連の仮想コードだろうから、childrenが空でないと動かないコードなど役に立たん
で、これを修正していくと>>876から大分離れたコードになる
初めから「面倒くさい」としかいってないんだが、なぜ馬鹿にされるんだろうな

894 = :

>>892
オブジェクト配列の入れ子なのに何で終端を数値配列にしてんの？

895 = :

お前らアホの相手するのやめろよ
スレのレベルが下がる

896 = :

傍から見てると良く分からん
childのいずれか1つにプロパティchildrenが無かったらそこでエラー吐いて止まる？
全てのchildにプロパティchildrenがあったらエラーにならず普通に終わる？

897 = :

>>894
オブジェクト配列しか存在しないと誰が決めたの？

898 = :

>>893
お前本物の馬鹿っぽいから優しく教えてやる
バグってんのはお前の補完（笑）した部分だし、普通に変数の省略部分を展開してやれば>>891の通りちゃんと動く

それとfor of文で無限とか実装的にあり得ないからよそでは言うなよ、確実に笑われるからな

899 = :

>>896
childのいずれか一つが「child.childrenが存在しない」もしくは「child.childrenがイテレータではない」だったら例外で止まる

900 = :

>>897
obj ← これが数値を示すように見える？

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ

類似してるかもしれないスレッド

• + JavaScript の質問用スレッド vol.132 + (1001) - [91%] - 2018/4/19 11:00
• + JavaScript の質問用スレッド vol.113 + (1001) - [88%] - 2014/1/25 12:46
• + JavaScript の質問用スレッド vol.133 + (1001) - [88%] - 2018/6/8 10:45
• + JavaScript の質問用スレッド vol.113 + (1001) - [88%] - 2014/3/15 21:30
• + JavaScript の質問用スレッド vol.130 + (974) - [88%] - 2016/10/26 14:18
• + JavaScript の質問用スレッド vol.123 + (1002) - [88%] - 2015/4/27 23:30
• + JavaScript の質問用スレッド vol.131 + (1000) - [88%] - 2017/1/25 8:01
• + JavaScript の質問用スレッド vol.123 + (966) - [88%] - 2020/10/20 2:30
• + JavaScript の質問用スレッド vol.103 + (1001) - [88%] - 2012/11/9 15:30
• + JavaScript の質問用スレッド vol.130 + (1001) - [88%] - 2017/11/25 20:45
• + JavaScript の質問用スレッド vol.102 + (1001) - [88%] - 2012/9/11 17:30
• + JavaScript の質問用スレッド vol.131 + (1004) - [88%] - 2018/3/7 13:30
• + JavaScript の質問用スレッド vol.142 + (984) - [88%] - 2020/8/27 19:15
• + JavaScript の質問用スレッド vol.122 + (116) - [88%] - 2018/5/2 18:30
• + JavaScript の質問用スレッド vol.122 + (1004) - [88%] - 2015/2/14 4:45