私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.134 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
まあ、理屈上は内部でsetTimeoutみたいに扱えばいいだけだとも思えるんだけどね
>>400,402
sleepを使う合理的理由がないから
sleepを使う合理的理由がないから
「真のプログラミング言語にはSleepなど必要ない」ワロタwww
ruby信者のruby擁護みたいな言い種wwwww
ruby信者のruby擁護みたいな言い種wwwww
sleep代わりにpromiseじゃだめなの?
直接的ではないにしろ事足りよね
直接的ではないにしろ事足りよね
>>404
スリープを使うメリットは
メモリの使用量を減らしたいときとか
ブラウザが固まらないようにとか
任意のタイミングで処理を実行したりとか
とにかくあれば便利だ
まあ、私が初心者というのもあるけど
ジャバスクリプトは、すごくやりづらいです
スリープを使うメリットは
メモリの使用量を減らしたいときとか
ブラウザが固まらないようにとか
任意のタイミングで処理を実行したりとか
とにかくあれば便利だ
まあ、私が初心者というのもあるけど
ジャバスクリプトは、すごくやりづらいです
>>407
これはひどい転嫁。
ブラウザが固まらないようにsleep??
pythonなど他の言語でも10秒sleepしたら10秒固まるのでは?
任意のタイミングで処理を実行??
まさにsetTimeoutやsetIntervalの出番では?
これはひどい転嫁。
ブラウザが固まらないようにsleep??
pythonなど他の言語でも10秒sleepしたら10秒固まるのでは?
任意のタイミングで処理を実行??
まさにsetTimeoutやsetIntervalの出番では?
>>407
sleepとpromise(コールバックなど含む)の違いは、
sleepは他の処理が終わってようが終わってまいが、
指定された時間ただ待つだけ
promiseなどは他の処理が終われば即座に
それがわかるわけで待つやり方としてはこっちのほうが良い
他の処理の完了を効率よく待つのはsleepでは実現できないんだけど
なんでsleepがいるの?
sleepとpromise(コールバックなど含む)の違いは、
sleepは他の処理が終わってようが終わってまいが、
指定された時間ただ待つだけ
promiseなどは他の処理が終われば即座に
それがわかるわけで待つやり方としてはこっちのほうが良い
他の処理の完了を効率よく待つのはsleepでは実現できないんだけど
なんでsleepがいるの?
>>405
> 「真のプログラミング言語にはSleepなど必要ない」ワロタwww
実際そうじゃね? ただ単に待つだけの処理なんて意味ないよ
他の何かが準備できるまで待ちたいなら、
他の何かが準備できたら通知してくれる方が良い
他の何かが準備できるのを待つことに対してはsleepはいらないんだから、
じゃあ他に何にsleepを使うのかと
> 「真のプログラミング言語にはSleepなど必要ない」ワロタwww
実際そうじゃね? ただ単に待つだけの処理なんて意味ないよ
他の何かが準備できるまで待ちたいなら、
他の何かが準備できたら通知してくれる方が良い
他の何かが準備できるのを待つことに対してはsleepはいらないんだから、
じゃあ他に何にsleepを使うのかと
さすがに「ちょっとしたデバッグのために」とかじゃないよな・・
それこそコンソール使えばいいし
それこそコンソール使えばいいし
何のためにsleepを使うか
重い処理をやってるときに途中途中で画面に反映したいとき
setTimeoutでもなんとかなるけどsetTimeoutの再帰呼出では迂遠になるケースがある
処理Aと処理Bの間にちょっとウェイトを入れたいとき
アニメーションとか。setTimeoutでできるんだけど重なると面倒だしsleepの一行でできると楽
重い処理をやってるときに途中途中で画面に反映したいとき
setTimeoutでもなんとかなるけどsetTimeoutの再帰呼出では迂遠になるケースがある
処理Aと処理Bの間にちょっとウェイトを入れたいとき
アニメーションとか。setTimeoutでできるんだけど重なると面倒だしsleepの一行でできると楽
というか他言語でのsleepも原則「他処理にいったん明け渡したい」用途がデフォじゃない?
待つ用途で使うというよりも
待つ用途で使うというよりも
>>415
例の前者のほうはループ必要だけどサブルーチン化は原理的には必要ない
setTimeoutやsetIntervalはサブルーチン化を強いられる
しかも再設定と離脱の仕組みを入れなきゃいけない分、どうしても複雑になるだろう
例の後者のほうはループ不要
例の前者のほうはループ必要だけどサブルーチン化は原理的には必要ない
setTimeoutやsetIntervalはサブルーチン化を強いられる
しかも再設定と離脱の仕組みを入れなきゃいけない分、どうしても複雑になるだろう
例の後者のほうはループ不要
まあそういう風にやっちゃえば良くもあるんだけどね
ms待機とms以上待機とは厳密には違うということもあるけど実際そうそう問題にならないし
ただ、言語側で用意しようよという話
ms待機とms以上待機とは厳密には違うということもあるけど実際そうそう問題にならないし
ただ、言語側で用意しようよという話
使いやすいところにsleep()があって気軽に使えるようになると
全体的にみればページロード完了までの所要時間が伸びるから
それを嫌ったのが実際のところじゃないかと
全体的にみればページロード完了までの所要時間が伸びるから
それを嫌ったのが実際のところじゃないかと
>>413
> 何のためにsleepを使うか
>
> 重い処理をやってるときに途中途中で画面に反映したいとき
sleepなんだからそこで処理は止まりますよ?
画面に反映する処理もしませんよ
だってsleepして止まってるんだから
ほんと何言ってるんでしょうかw
> 何のためにsleepを使うか
>
> 重い処理をやってるときに途中途中で画面に反映したいとき
sleepなんだからそこで処理は止まりますよ?
画面に反映する処理もしませんよ
だってsleepして止まってるんだから
ほんと何言ってるんでしょうかw
昔のゲーム宜しく
sleep(10); //これを挟むとなぜか動く
でもやりたいんか
sleep(10); //これを挟むとなぜか動く
でもやりたいんか
別にsleep使えばいいじゃん
自分で1行で定義すればasync関数内でそれっぽく使えるんだからさ
勿論setTimeoutというか、ブロッキングが気になるなら
requestIdleCallbackのようなものも検討していいケースもあると思うよ
でもsleep=悪ってことは無いと思うね
例えば同じように悪だと言われるevalよりも遥かに有用なテクニックだろうよ
自分で1行で定義すればasync関数内でそれっぽく使えるんだからさ
勿論setTimeoutというか、ブロッキングが気になるなら
requestIdleCallbackのようなものも検討していいケースもあると思うよ
でもsleep=悪ってことは無いと思うね
例えば同じように悪だと言われるevalよりも遥かに有用なテクニックだろうよ
>>425
昔のゲームはOSなど無いに等しくハードウェアを直接操作していた。
そしてハードウェアの特定の命令は処理に時間がかかり
命令を出してから一定時間たたないと処理が終わらないことがあった
そういう場合はちゃんとハードウェアの仕様として最低Nミリ秒待つなどと書かれていた
しかし今の時代ハードウェアはOSやドライバが処理し、そのような処理に
一定時間かかるような、割り込みによって完了が知らされるようになった。
これにより処理が終われば通知されるため、スリープのように待ちすぎるようなことも無くなった。
もちろんブラウザでもOSやドライバ、それらを経由して
何かの処理に時間がかかるような場合は、コールバック関数が呼ばれることとなった
そのためブラウザでsleepは不要となった。またsleepは処理が止まり、
表示されたページも固まるのでユーザーインターフェースとしても不適切であり
避けるべきものとなった
昔のゲームはOSなど無いに等しくハードウェアを直接操作していた。
そしてハードウェアの特定の命令は処理に時間がかかり
命令を出してから一定時間たたないと処理が終わらないことがあった
そういう場合はちゃんとハードウェアの仕様として最低Nミリ秒待つなどと書かれていた
しかし今の時代ハードウェアはOSやドライバが処理し、そのような処理に
一定時間かかるような、割り込みによって完了が知らされるようになった。
これにより処理が終われば通知されるため、スリープのように待ちすぎるようなことも無くなった。
もちろんブラウザでもOSやドライバ、それらを経由して
何かの処理に時間がかかるような場合は、コールバック関数が呼ばれることとなった
そのためブラウザでsleepは不要となった。またsleepは処理が止まり、
表示されたページも固まるのでユーザーインターフェースとしても不適切であり
避けるべきものとなった
10秒じゃなくて10ミリ秒だろ
つうか今でもJSみたいなイベント駆動じゃなくて
その対極に位置するポーリングタイプの言語環境では
ビジーループ回してsleepしながらポーリングするっていうのは普通になされていること
例えばゲームではコントローラーの状況をループでずっと確認し続けて
前回と変わっていれば変化があったと見なす
そういうのは普通に行われていること
つうか今でもJSみたいなイベント駆動じゃなくて
その対極に位置するポーリングタイプの言語環境では
ビジーループ回してsleepしながらポーリングするっていうのは普通になされていること
例えばゲームではコントローラーの状況をループでずっと確認し続けて
前回と変わっていれば変化があったと見なす
そういうのは普通に行われていること
ゲームじゃなくても今のPCハードでも
イベントが軸になってるフレームワーク使わないで普通にcで書くと
sleepさせないで重い処理すると「応答がありません」ってなるんじゃないんか
イベントが軸になってるフレームワーク使わないで普通にcで書くと
sleepさせないで重い処理すると「応答がありません」ってなるんじゃないんか
>>430
えっ? 自分の書き込み良く読み直してごらんよ。
直前のdomを操作する処理がもし同期処理なら、hogehogefunction()とそのまま呼んでもdom更新後に実行されるでしょ。
そうではなく非同期だからsetTimeout でくるむテクニックがあるわけで。
えっ? 自分の書き込み良く読み直してごらんよ。
直前のdomを操作する処理がもし同期処理なら、hogehogefunction()とそのまま呼んでもdom更新後に実行されるでしょ。
そうではなく非同期だからsetTimeout でくるむテクニックがあるわけで。
最近のブラウザで言うと正確には操作の時点で同期処理とは限らないよ
例えば要素の形を変えたりするような操作は非同期である程度まとめて扱われる
もしgetClientRectsを読んだりするとその時点でブロックして構築・計算される
例えば要素の形を変えたりするような操作は非同期である程度まとめて扱われる
もしgetClientRectsを読んだりするとその時点でブロックして構築・計算される
「操作の時点で同期処理とは限らない」ってことは、同期なものも非同期なものもある、ってことだよな
DOM「操作」そのもので、非同期なもの・非同期になる場合って
具体的にどのブラウザの何?
getClientRects()は操作側じゃなくて描画側の今現在の状態取得なんだから例として不適切では
DOM「操作」そのもので、非同期なもの・非同期になる場合って
具体的にどのブラウザの何?
getClientRects()は操作側じゃなくて描画側の今現在の状態取得なんだから例として不適切では
>>437
仕様を読めば分かると思うが、JavaScriptはHTMLパーサに割り込んで同期的に処理されるぞ
仕様を読めば分かると思うが、JavaScriptはHTMLパーサに割り込んで同期的に処理されるぞ
>>437
> sleepを使う言語の多くにおいて描画スレッドは別だろ
そうだよ? だから描画スレッドでsleepは使えないって言ってるんだが?
だから何度も言ってるけど、(描画スレッドで)sleepしたら処理が止まるだろ
画面書き変わらなくなるぞ
> sleepを使う言語の多くにおいて描画スレッドは別だろ
そうだよ? だから描画スレッドでsleepは使えないって言ってるんだが?
だから何度も言ってるけど、(描画スレッドで)sleepしたら処理が止まるだろ
画面書き変わらなくなるぞ
入力フォームが整数かどうかチェックする関数ってないですか?
isNaNは文字列だとダメみたいだしありそうなのに出てこない
isNaNは文字列だとダメみたいだしありそうなのに出てこない
type number で stepを1にしておけばデスクトップでは整数入力になるでしょ
その後念の為数値を|0すればいいんじゃない
その後念の為数値を|0すればいいんじゃない
>>444
文字列なんだから普通に正規表現でいいんじゃないの
文字列なんだから普通に正規表現でいいんじゃないの
> あんな意味不明な文字列かけるの理系のエリートだけじゃないの?
バレターカ
バレターカ
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.114 + (1001) - [97%] - 2014/5/3 10:45
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.104 + (1001) - [97%] - 2013/1/28 4:00
- + JavaScript の質問用スレッド vol.124 + (1001) - [97%] - 2015/7/16 1:30
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.113 + (1001) - [95%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.119 + (1002) - [95%] - 2014/10/3 15:30
トップメニューへ / →のくす牧場書庫について