[過去ﾛｸﾞ] + JavaScript の質問用スレッド vol.126 + [転載禁止]©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
554(1): 2015/11/04(水)00:24 ID:??? AAS
>>547
ついで。もうコードは書かなくていいから。
細かいことを言うと、indexOf('\n')はLFのみのテキストの場合引っかからないので、最後まで見に行ってしまう。
結果、getFirstLine1はMac/UNIXの大規模テキストを食わされると極度に遅くなる。
とはいえ、良い対策は無い。
この危険性は 2/3 にはない。
だからまあ、普通は 3 を使っておけということになる。
555(1): 2015/11/04(水)00:30 ID:??? AAS
>>551
試してみたんですが、タイマーが機能せず、
同時実行無理なんですよね・・・あきらめまｓ
556: 2015/11/04(水)00:57 ID:??? AAS
>>551
本職か？
ならば俺の見解は550の通りだが、そちらの見解を聞きたい。
現実的には安全策を採って色々あるのだと思うし、
それ以前に各種ブラウザ対策でルールが埋まっている気もするが。
557(1): 547 2015/11/04(水)01:22 ID:pUq54Vxq(1/9) AAS
>>548-549
> さてgetFirstLine1だが、先述の通り、ここはB（速度）を目指さないといけない。（存在価値がない）
どんなコードでも催促のコードを書くことを目指すべきという考え方は好感が持てるものだが、正規表現エンジンの速度は最適化具合によって異なる
getFirstLine1 と getFirstLine3 のどちらが速いかは実装依存だろう
> そこで処理順なのだが、速度を目指すのだから、よくある順にショートカットにして組むことが必要になる。
その通りだが、「よくある順」を知っているのは質問者だけだ
私は getFirstLine1 の用途を想定できないのでそれは質問者に委ねることになる
具体的にはよくある文字列が「1行」「\rだけ含む」「\nだけ含む」「\r\nを含む」のどれなのかを想定できない
だから、速度重視としてはアルゴリズムか実装の最適化具合に応じて組むことになる
> 多分そちらの「構造化プログラミング」ってのはreturnを1個にしろという話だろうけど、そういうのは俺は気にしていない。
省8
558: 547 2015/11/04(水)01:32 ID:pUq54Vxq(2/9) AAS
>>550
> ただ、それ以前に、「どんな型でもちゃんと処理しろ」というのはやはり負担が大きく、どこかしらでバグるだろうから、
そんなことはない
どんな型でも安全に処理すべきだし、私のポリシーは「1: 安全、2: 速度」だ
ECMAScript は型が緩いといわれるが、それは内部的に型変換して処理しているからだ
ほとんどの演算子、関数は内部的に始めの処理でキャスト(型変換)している
従って、始めの処理で引数をキャストしておけば「どんな型でも適切に処理」することは難しくない
ここで回答する時には「例外処理ぐらいは自分でやってくれ」のスタンスで意識的に省略することがあるが、>>537の指摘は妥当なものだ
例えば、RegExp.prototype.exec は第一引数を ToString (String型に変換) するのでどんな型でも適切に処理できる
外部ﾘﾝｸ[exec]:www.ecma-international.org
省12
559: 2015/11/04(水)01:47 ID:??? AAS
>>506的なのやりたいときこんな感じにしてたわ
for (var i=0,l=text.length,;i<l;i++) {
if (text[i]=="\r" || text[i]=="\n") { break; }
}
560(1): 547 2015/11/04(水)02:09 ID:pUq54Vxq(3/9) AAS
>>554
> 結果、getFirstLine1はMac/UNIXの大規模テキストを食わされると極度に遅くなる。
> とはいえ、良い対策は無い。
確かに2回走査するのは getFirstLine1 の弱点だ
対策としては string.indexOf('\n'); の後に string.slice(0, i1) する方法が考えられる
「\n がなく、\r がある巨大なテキスト」「\nも\rもない巨大なテキスト」には対応できてないので根本的な解決ではないが、UNIXなテキストには一応対応できる
外部ﾘﾝｸ:jsfiddle.net
561(1): 2015/11/04(水)02:54 ID:??? AAS
> >>557
若干被るかもしれないが、とりあえず書いたから投稿しておく。
> どんなコードでも催促のコードを書くことを目指すべき
違う。常に何のためのコードなのかを考えろということ。
見た目のわかりやすさなのか、速度なのか。安全性ならそれはそれでいい。
> 正規表現エンジンの速度は最適化具合によって異なる
これはその通りだが、通常は軽い仕様の方が速い。（正規表現は色々出来る分遅い）
1つのindexOfとexecで両方が同一箇所でマッチする時、（今回なら\rの検索)
通常はindexOfの方が速い、というか、indexOfの方が遅くなる実装を作ることの方が難しい。
既に書いたが、ヒットしないケースでキャッシュに収まらないほどのテキストを食わされると、
省9
562(3): 2015/11/04(水)02:54 ID:??? AAS
> 空文字を引数にとる場合、do-while では速度上で問題が出るだろう
> getFirstLine1 に気が向いていたので妥協したが、while 文にした方が速いだろう
何故だ？cau4mx8d/3/とcau4mx8d/4/では速度差は出ないはずだが。（中身は同じだ）
多分ただの勘違いだと思うが、do/whileもショートカット論理で動く。
> ES 仕様で内部的に型変換してくれるのならそれを利用すべきだ
もちろんその通りだが、バグを少なくするコツは「簡単にすること」だ。
だから、単純に「どんな型が来るか分かりません」よりも「必ずstring型が来ます」の方がバグらない。
ポリシーとしては、多分、
α：各関数で型チェック、つまり各関数は複雑になりますが、個々で安全を保証します。
β：入力先頭で型チェック、つまり各関数は型決めうちでシンプル、ただし入力の最初に必ず型保証を入れる必要があります。
省13
563: 2015/11/04(水)03:02 ID:??? AAS
ああすまん、俺のCRとLFが逆だな。これまで全部。
悪いが脳内変換してくれ。まあ分かる範囲だろw
564: 2015/11/04(水)03:20 ID:??? AAS
>>560
cau4mx8d/5/ で俺はいいと思うけどね。
> 「\n がなく、\r がある巨大なテキスト」
昔のMacだけだから問題ない。
> 「\nも\rもない巨大なテキスト」
どの実装でも遅いから問題ない。
565: 547 2015/11/04(水)03:54 ID:pUq54Vxq(4/9) AAS
>>561-562
> 何故だ？cau4mx8d/3/とcau4mx8d/4/では速度差は出ないはずだが。（中身は同じだ）
空文字ならば length が 0 なので charAt を実行する必要はない
do-while なら必ず1回は実行してしまう
> もちろんその通りだが、バグを少なくするコツは「簡単にすること」だ。
だから、RegExp#exec(string) は簡単だろう？
> だから、単純に「どんな型が来るか分かりません」よりも「必ずstring型が来ます」の方がバグらない。
「どんな型でもString型に変換します」は実にシンプルな解だと思うが、何か問題があるのか？
正直、あなたの意見は抽象論が多すぎるので具体性にかけて説得力が弱いのだが
> ただここら辺は本職に確認した方がいい。
省9
566: 547 2015/11/04(水)03:57 ID:pUq54Vxq(5/9) AAS
>>562
> -1の比較回数を減らすのは実は余り効かない。それはループではないから。（関数で1回だから）
それならばループ処理ではない「よくある順」に拘る理由もなくなるはずだろう？
「よくある順」のレベルで拘る人は他にも拘るべきポイントがあると思ったのだが、「よくある順」だけ例外視する理由は何なのだ？
> これな、以前は確かにこの通りだったが結局最適化で何とかなったらしく、
スコープチェーンは ES 仕様の規定内なので最適化で何とかなるレベルではないのだが
速度差が小さくなる事はあっても差がなくなる事はあり得ないので無駄な対策ではない
> String()はイラネーみたいな記事もあって、
「String()はイラネー」は速度以前の問題だと思うが、なぜ「イラネー」なのだ？
567(1): 2015/11/04(水)04:09 ID:??? AAS
> > だから、単純に「どんな型が来るか分かりません」よりも「必ずstring型が来ます」の方がバグらない。
> 「どんな型でもString型に変換します」は実にシンプルな解だと思うが、何か問題があるのか？
問題はある。一番重要な点「バグらない」が実現できてない。
どんな型でもString型に変換するというルール自体はシンプルだが、
String型に変換した結果、バグってしまったら意味は無い。
「バグらない」を実現するためには、型というより値が想定内でなければならない。
String型であっても、想定外の値であれば、バグってしまう。
だから想定内の値（に変換される型）だけの方がバグらない。
568(1): 547 2015/11/04(水)04:20 ID:pUq54Vxq(6/9) AAS
>>567
何を持って想定外なのかわからんが、全て想定内だから問題ないのでは？
有体にいえば、getFirstLine1 の仕様を理解していないプログラマが悪い
569(2): 2015/11/04(水)04:28 ID:??? AAS
>>568
俺は一般的な話をしている。
String型ではない話をしよう。
MyHoge型を扱うコードに、YourHage型を渡したらどうなるか？
エラーにする以外何もできることはない。
570(1): 547 2015/11/04(水)04:33 ID:pUq54Vxq(7/9) AAS
>>569
俺も一般的な話をしている
あなたは静的型付き言語の仕様を期待しているのだろうが、ECMAScript では異なる型を与えられてもエラーにならないのが一般的だ
型変換では吸収仕切れない場合のみにTypeErrorとなる
/null/.test(null); // true
[].forEach(); // TypeError: undefined is not a function
571(1): 2015/11/04(水)04:46 ID:??? AAS
>>570
だから、
「エラーにならない」のと「バグにならない」は意味が違う。
一番問題なのは、バグなのに、エラーにならずに
処理が進むことだ。
572(1): 547 2015/11/04(水)04:52 ID:pUq54Vxq(8/9) AAS
>>571
バグとは想定外の挙動をする事だ
繰り返すが、想定内であれば問題はない
あなたが動的型変換の仕様を想定できていない事がおかしい
573(1): 2015/11/04(水)04:55 ID:??? AAS
>>572
バグというのは言語仕様ではなくて、アプリの
要求仕様で決まった動き以外をすることだ。
アプリの要求仕様っていうのは、作るシステム毎に
ユーザーや開発者が決めることで
言語仕様で決まっているものは一つもありはしない。
お前の言ってる、挙動が言語仕様で決まってるものであれば
それは、全く関係ない話をしている。
上下前次1-新書関写板覧索設栞歴
あと 429 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.012s