- 1 名前：デフォルトの名無しさん [2007/05/12(土) 08:25:15 ]
- 前スレ
[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
pc11.2ch.net/test/read.cgi/tech/1163986696/
[mustang] 次世代Javaの動向 3 [dolphin]
pc8.2ch.net/test/read.cgi/tech/1157227790/
次世代Javaの動向 ２
pc8.2ch.net/test/read.cgi/tech/1147881822/
【Java】次世代Java・J2SE1.6の動向【Mustang】
pc8.2ch.net/test/read.cgi/tech/1081698555/
- 496 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:04:38 ]
- で、何故parseInt()のパーズ失敗を例外で扱うのに反対かというと、parseInt()は
引数から返り値が一意に定まるので、たとえパーズ失敗でも例外的な状態と
言えないと考えるから。
- 497 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:06:27 ]
- >>495
なんで動的言語が関係してくるの？むしろ静的にチェックできる機能が
欲しいって話をしてるわけで、動的言語とは対極の発想だよ。というか、
短いコードが好ましいってのは動的言語特有の発想でもないでしょ。
- 498 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:07:59 ]
- > メソッド側にアノテーションで実現することになりそうだ。
メソッド側にってのは余計。構成してて放置したままだった。
- 499 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:15:42 ]
- 契約的言語。
- 500 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:21:29 ]
- アノテーションひとつで
if (n != null) { /* n アクセス */ } と
if (n == null) { return; } /* n アクセス */
のどちらかを選択（および強制）できるのなら歓迎かな。
@Overrideの親戚みたいなもんだ。
- 501 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:43:04 ]
- 例外を「例外的な状態でのみ使うべき」というのは言葉が同じだからもっともらしく
聞こえてしまうだけで、何の助けにもならない方針。
www.boost.org/more/error_handling.html
boost.cppll.jp/HEAD/more/error_handling.html
- 502 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:48:46 ]
- >>500
FindBugsをどうぞ
findbugs.sourceforge.net/manual/annotations.html
- 503 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:03:12 ]
- >>493,496
単に自分の考えと合わないってだけ？
それって自前のクラスメソッド書いて、そっち使うんじゃダメなんか？
なんつーか、>>448-449 あたりが結論になりそうな話じゃねーかと。
- 504 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:14:56 ]
- >>503
もちろん自前のクラスメソッド書いて使うことになると思うよ。
実際にJavaプログラム書くときの解決策としては。単に言語の
拡張まで含めて許されるならどういう設計にするのが良いかという思考実験。
あと、free論争とは文脈が違うので一緒にされるのはちと心外だな。
どういう方針でライブラリ設計をするかという話は使い勝手に関わって
くる。もちろん、ここで議論しても実際のJava APIの設計が改善されない
という意味では無益なのはそうだけど。
- 505 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:26:05 ]
- >>496
理解できない
すべての失敗する引数はnullが返ることで一意に定まるということ?
例外的な状態かどうかはparseInt単体でなく、呼出し側がどうしたいかでも異なるはずだ
デフォルト値が定まる場合と定まらない場合、とか
んで、とりあえず保守的にパーズ失敗を例外として扱うと言う設計でよいと思う
checkedかどうかは微妙なとこだが
- 506 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:26:52 ]
- 単に好き嫌いの問題で、パフォーマンスとか関係ないんでしょ？
free論争と大して変わらんと思うが。
- 507 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:30:33 ]
- >>504
parseInt の使い勝手を改善する事により、Java での開発効率が 10％向上するんだ！
とか考えてるなら 一生懸命考えるのも頷けるんだけど……
ぶっちゃけ瑣末な問題じゃね？
- 508 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:40:40 ]
- 例外を握りつぶすユーティリティメソッド作ればOK。
- 509 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 02:03:58 ]
- >>505
> すべての失敗する引数はnullが返ることで一意に定まるということ?
そういう意図で書いた。正確に言うと、外部の状態に依存せずに
入力*のみ*から返り値が決定される、ということ。その逆の
典型的な例としてはIOExceptionを発生させるような関数や
コンストラクタがある。これらの関数は入力だけでなく外部の
状態によって成功したり失敗したりする。
>>507
parseIntだけの問題として考えればぶっちゃけどうでもいいけど、
一般的な問題としてある関数が失敗を返り値で通知するか
例外で通知するか、というのは瑣末な問題じゃないと思う。
- 510 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:42:29 ]
- ユーティリティメソッド作ればOKってのは、思考停止以外のなにものでもない。
- 511 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:46:39 ]
- parseInt を改変しようとか考えるのは暇人以外のなにものでもない。
- 512 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:53:09 ]
- >>511
そうか？
- 513 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 10:14:54 ]
- >>511
つきあってた連中も暇人以外のなにものでもない。
- 514 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:20:14 ]
- 改変は、ちゃんと考えてbugparadeにあげるなどすれば、なにがしかの影響は与えられる。
ここで改変について語るのも、そういったヤツのインスピレーションになることもあるだろうし、本人が書き込むこともあるだろう。
無駄ではないよ。
- 515 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:39:06 ]
- なにがしかの影響って……
>>509 も parseInt に関してはどうでもいいって言ってるんだが。
そんな瑣末な問題に関わらせる事で
JDK開発者のモチベーションを下げたいって事か？
free論争ってさ、やってる当事者は引っ込みがつかなくなってるだけかと思ってたけど
案外、>>514みたいに「この議論は無駄ではない」とか思ってる人も居るのかも知れないね。
- 516 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:41:41 ]
- parseIntの例外が例に挙がって
- コードを短く書きたい
- 例外で扱う状況とは思えない
という2点の争点があると思う。
さらに後者の視点は、
- 例外を扱うべき状況を設計の美しさから考える
- 例外を扱うべき状況をException処理の重さから考える
という2つの立場がある
俺は、parseIntに例外の記述が出てきてもいいが、重いException処理が
いやだなぁ、という点から、こういうのがあればいいんじゃないかと思う。
定義済Exception/ StaticException / 短距離Exception /LightWeightException ?
今、Exception処理が重いのは、Exceptionオブジェクトの生成にある（スタックトレース生成など）
つまり、生成処理をなくしてやれば大幅にパフォーマンスは改善するはず。
なので思い切って、stackTraceとかが空っぽのExceptionで
すぐ直上のcatch節で捉える決まりで、
さらにThrowの必要があるときは別のExceptionにしなくてはいけないようなもの。
気軽に例外が投げられるようになって、正常系の処理が例外でトリッキーに実装されるように
なっちゃうかもしれないけど、こういうのってどうですかね。
- 517 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:47:27 ]
- >>515
相手にするから調子に乗るんだろ。ほっとけ。
- 518 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:05:24 ]
- >>516
> 重いException処理がいやだなぁ、という点
いやなだけなのか。
これこれこういう使い方をすると、
（パーズ失敗する）parseInt の呼び出しがボトルネックになって困る、
そして、このような使われ方をする事が多いので標準APIを改善して欲しい、
ってんなら議論の余地もあるけど、それって単なる好き嫌いの問題じゃね？
- 519 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:39:29 ]
- >>518
包丁一本で、何でも作るのって大変じゃないかな、って話です。
sourcepost.sytes.net/sourcepost/sourceview.aspx?source_id=29658
のコード書いて、Exception生成のコストを見てみました。
ウチのマシンでの結果です（かかった時間）
Try[1]:422
Try[2]:10469
Try[3]:78
Try[4]:10875
１つめが、Throwableを継承して、Overrideで色々ぶった切ったクラス。
２つめが、単なるException。
３つめが、単なるObject。
４つめが、NumberFormatException。
Objectのnewに比べて、Exceptionのが大幅に重い処理となっています。
NumberFormatExceptionもそうです。
もし、ファイルを読む処理をするときに、数字でないものも大量に含むフィールドがあれば
Exception処理が時間を食うことが予想されます。
Exceptionの機能を大幅にカットすれば、２桁のオーダーで処理を軽くすることができるわけです。
現在の仕組みを使って、実装するならこうなりますがシステムとしてサポートしてくれても
いいかなぁ、と思ったわけで。
- 520 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:53:24 ]
- >>519
> 数字でないものも大量に含むフィールドがあれば
普通はフォーマットエラー吐いて終わりでしょ。
- 521 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 13:10:14 ]
- 〃〃∩ _, ,_
⊂⌒（ `Д´） ＜ ヤダヤダ！ parseInt が例外使っちゃヤダ！
｀ヽ_つ ⊂ノ
ジタバタ
〃∩
⊂⌒( _, ,_） ＜ ぶっちゃけどうでもいいけど、やっぱりヤダヤダ……
｀ヽ_つ ⊂ノ
ﾋｯｸ...ﾋｯｸ...
⊂⌒( _, ,_）
｀ヽ_つ ⊂ノ zzz…
- 522 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 13:56:24 ]
- delphiのStrToIntDefみたいに、数値にできないときのデフォルト値が指定できればかなりいい
- 523 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:17:51 ]
- >>520
何で？全部読んで例外をチェックしないと駄目かもしれないですよ。
いや、というか例外を使うなとかいう話ではなく、
パフォーマンスを気にして例外を使うべき場面を回避しようとするのは
本末転倒だから、例外を使わなきゃ駄目なときパフォーマンスが
落ちなければそういう誤解、というか誤用がなくなるんじゃないかと。
- 524 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:45:35 ]
- >>523
「かもしれない」って……
要するに、今現在（パーズ失敗する）parseInt の呼び出しが
ボトルネックになって困ってるわけじゃないんでしょ。
単なる好き嫌いの問題にしか見えないが。
それに、誤用とか誤解とか言われても……
>>509の理論が いつでもどこでも通用する例外のガイドラインとはとても思えないし、
使い勝手、堅牢性、パフォーマンス、好き嫌いとか色々な要素が絡んでくるから
いつでもどこでも誰にでも通用する例外のガイドラインを作るのは難しいだろうし。
- 525 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:47:32 ]
- ということは例外はこれまでどおりフィーリングとわずかなドキュメントで判断していくしかないのかね
- 526 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 15:21:46 ]
- >>524
>>523 ≠>>509です。
parseIntはあくまで例です。
確かにちょっと誤解されそうなレスでした・・・
誤用というのは、Exceptionを使うまいとして
ごちゃごちゃとしたコードになってしまうような状況を指してます。
具体的にカチッとした基準に基づいた「ごちゃごちゃ」ではありませんが。
私は、parseIntに関わらず、Exception処理が軽くなればいいな、という話をしているつもりでした。
- 527 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 15:36:41 ]
- >>526
parseInt で例外生成コストが下がると嬉しいか？
それに、parseInt で Exceptionを使うまいとして
ごちゃごちゃとしたコードになるって、どんな状況？
あと、俺は Exception処理が軽くなれば良いって要望に対する返答が
「例外的な状況以外で例外使うな」って話なんだと理解してるんだが。
例外って濫用すれば goto より悲惨なスパゲッティコード書けるしね。
- 528 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 17:31:04 ]
- パースの失敗は十分、例外的状況に値すると思うが・・・。
例外処理の乱用がスパゲッティーコード招いてるんじゃなくてそういうコード書いてる自分がスパゲッティー作ってるんだと思う。
アプリケーションかミドルウェア側の設計でどうにかなると思うんだが？
- 529 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 17:37:48 ]
- >>527
InterruptExceptionって例外的だと思う？
スレッドのキャンセルを実装しようと思ったら普通に出るけど
- 530 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 18:49:35 ]
- >>528
設計っつーか、実装で吸収できるでしょ。
- 531 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:19:45 ]
- 便利なら便利なほうがいい。
- 532 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:24:49 ]
- 何を便利と感じるかは人によって違う、と。
かと言ってなんでも標準APIに入れたら標準APIメンテする人間の負担が増えて
バグが増えたり放置されたりといった悪影響も考えられる、と。
- 533 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:47:42 ]
- NICEのnullableってのは興味深いネタだったけど、
それと一緒に語られたparseIntの仕様には何の興味も湧かなかった。
つーことで、イディオム補完型（保証型）のアノテーションの充実を期待したい。
- 534 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 07:32:33 ]
- >>445
終了前のfreeは害っていうのがいるだろ。
- 535 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 07:55:31 ]
- そんなものは無い
- 536 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 22:37:51 ]
-
blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx
- 537 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 22:39:06 ]
- blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx
- 538 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 00:14:55 ]
- parseIntで100近くもダベれるお前らに脱帽
- 539 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 00:53:35 ]
- >>536
低脳な質問で悪いんだけど
「クリティカルで速度が要求される場面での数値チェックは、例外を使わないのが無難っぽいです。」
って言ってるけど、じゃぁどういう処理が望ましいんだろうな。
俺も、試しに同じ用なプログラムを10000000回処理をぶん回してみたが、
正直それほど有意差は認められなかった。
----以下結果----
StringUtils.isNumeric() : boolean で不正な文字かどうかを検知
1回目 451 ms
2回目 401 ms
Integer.parseInt() : 例外で不正な文字かどうかを検知
1回目 42822 ms
2回目 42771 ms
- 540 名前：デフォルトの名無しさん [2007/09/08(土) 01:03:04 ]
- >>539
例外を使ってるバージョンが100倍近く遅いんだが、それは
有意な差じゃないの？
- 541 名前：デフォルトの名無しさん [2007/09/08(土) 01:05:19 ]
- あ、もちろん実際にparseIntが使われる局面で1000000万回も
呼ばれることは無いだろうから、そういう意味では例外を使っても
いいんだろうけど、有意な差が無いってのは変でないの？ってこと
- 542 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:05:27 ]
- >>539
ネタにマジレス。
まず 数値チェックに parseInt 使って
> クリティカルで速度が要求される場面
が具体的にどういう場面なのかってのを特定するのが先決。
それをしないで「どういう処理が望ましいか」を考えても時間の無駄。
- 543 名前：デフォルトの名無しさん [2007/09/08(土) 01:07:45 ]
- 間違った。1000000万回 -> 1000万回
- 544 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:12:44 ]
- >>538
まだまだ続くよ
- 545 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:59:22 ]
- 巫女巫女ナース巫女巫女ナース♪
- 546 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 02:32:19 ]
- ｢まだまだ いくよぉ〜｣だな
- 547 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 03:09:27 ]
- もうちょっとだけ続くのじゃ
- 548 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 07:03:01 ]
- つうか、例外は制御構造の要だろ
ttp://d.hatena.ne.jp/smeghead/20070309/baka
- 549 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 08:05:55 ]
- 多値にしてもnullableにしても、
失敗をnullで表すのはちょっと古いんじゃないかな。
多値なら失敗(false)したら(undef, false)とundefみたいな値を返す方がいいと思う。
- 550 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 10:19:24 ]
- >>544,547
続けるなよ……
- 551 名前：519 mailto:sage [2007/09/08(土) 14:09:14 ]
- >>536
ちょっと待て、ほとんど俺が書いたコードじゃねえかそれ。
ちなみに、おれじゃねえぞ。そのblog
- 552 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 14:18:22 ]
- >>549
undefがnullとどう違うのかわからん
- 553 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 15:06:37 ]
- >>552
お前はそもそもnullは何をモデル化したと考えてるんだ？
- 554 名前：かつのり mailto:sage [2007/09/08(土) 16:03:23 ]
- 本人降臨っす。
>>519
実験用にパクらせていただきましたｗ
ちなみにStringUtils.isNumeric()は微妙ですね。
Integer.parseIntの高速版とするなら、
Integerとしての要件を満たさなければいけません。
正規表現のパターンを予めキャッシュしておいて、
そのパターンでマッチングするのが一番早いのかな。
- 555 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 16:29:24 ]
- NumberUtils#isNumberもあるけどlong型とかでも判定しちゃうな
- 556 名前：519 mailto:sage [2007/09/08(土) 17:34:45 ]
- >>554
ああ、バッチでファイル読む時は俺もそうしてるなぁ
どうせ桁数制限とか入る事が多いし
- 557 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 17:52:06 ]
- Patternのcompileってホントにコンパイルしてるの？
- 558 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 18:01:25 ]
- >>557
コンパイルの意味を、パースして実行用データ作っとくって意味なら、コンパイルしてるんじゃねぇの？
- 559 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 18:21:18 ]
- たしかに最適化オプション付きであるとはいってないからね。
Strategyパターンとか駆使してガチガチに最適化されたPatternを返して欲しいとこだ。
- 560 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 19:03:46 ]
- Javaの正規表現はDFAでしょ？確か。
DFAはバックトラックしなくていいから、
最適化は高速化ではなく使用メモリのレベル。
遷移テーブルとかその辺。
下手な自前のマッチングコードを書くより早いよ。正規表現は。
- 561 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 19:55:04 ]
- >>560
Javaの正規表現はNFA。実装読んでみるべし。
最近の言語に組み込みの正規表現ライブラリの多くはNFA(または
その変種)を採用してる。理由はNFAじゃないと扱いづらい機能
(後方参照など)があるため。
- 562 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 19:56:36 ]
- ちなみに各言語における正規表現ライブラリの実装がどのように
なっているかの概要を知りたい場合は、詳説正規表現がオススメ
- 563 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 22:35:20 ]
- >561
そか。情報サンクスコ
- 564 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 19:28:16 ]
- DFAじゃあ不便すぎる。
- 565 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 21:49:32 ]
- DFAはNFAから変換できるけど、NFAにしておく意義としては、
NFAのまま何かの機能を追加するってこと？
バックトラックする際に後方参照も同時にサポートするためなのか。
- 566 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 22:28:17 ]
- >>560
> 下手な自前のマッチングコードを書くより早いよ。正規表現は。
んなわけねーだろ。正規表現遅すぎだ。計測してねーだろ。
ただ、Web アプリとかでせいぜい項目が数百程度の
入力チェックや変換程度なら速度差は計測不能。
- 567 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 22:41:57 ]
- >>566
単純な文字パターンの検証なら正規表現の方が遅いだろうけど、
ごく一般的な業務システムプログラマが、
自前で複雑な検証コードを書くよりは速い。
きちんとロジックを書ける人なら速いんだけど。
- 568 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 23:18:56 ]
- 文脈的に parseInt でパーズ成功/失敗を予め判定するためのコードでしょ。
>>554が言うように Intergerとしての要件を満たす、
文字列が数字で構成されてるかだけじゃなくて最大値や最小値チェックもするなら
正規表現つかうより自前でやった方が早く書けるんじゃねーの？
- 569 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 23:23:20 ]
- 最大値や最小値をチェックする時点で、成功/失敗を予め判定するどころか、すでに値が求まってる気がする
- 570 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 23:56:08 ]
- >>566>>567>>568
>>560は正規表現エンジンがDFAで実装されてる場合の
話をしてると思うよ。その場合なら、下手に自前の
コード書くより早いというのは間違いでもなんでもないよ
- 571 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 00:01:33 ]
- > ちなみにStringUtils.isNumeric()は微妙ですね。
> Integer.parseIntの高速版とするなら、
> Integerとしての要件を満たさなければいけません。
だからなぁ…… 最大値/最小値チェックしないなら
ほとんどStringUtils.isNumeric()で用足りるんじゃね？
- 572 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 00:01:37 ]
- >>565
そういうこと。NFAのままにしておけば、「非正規な」機能である後方参照
やその他もろもろ、比較的容易に追加できる
- 573 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 00:13:43 ]
- >>569
例外使わないだけで 100倍程速くなるそうだから、
変換処理が 2回やる事によって 2倍の時間かかっても大した問題じゃないんじゃね？
まぁ、場合によっては大した問題になるかもしれんが。
そんなん問題になってから考えりゃいいっしょ。
- 574 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 01:42:54 ]
- 正規表現使うほうが１００倍速いよ。実装が。
- 575 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 20:17:24 ]
- C#の正規表現はグループに名前を付けられるみたいだね
- 576 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 21:14:45 ]
- >>574
StringUtils.isNumeric()では足りない部分までIntegerの要件を満たすかチェックするんだったら
正規表現でやるのは面倒くさそうだが。
- 577 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 22:50:21 ]
- 正規表現のスレでやれよ。ここには関係ないから。
- 578 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 23:04:10 ]
- >>576
桁数制限してIntegerの半分以上の範囲捨てるなら簡単だけどな
- 579 名前：デフォルトの名無しさん mailto:sage [2007/09/12(水) 00:32:10 ]
- >>575
正規表現のマッチング処理高速化のためにコンパイルすると、
メモリリークするとかＭＳＤＮのドキュメントに書いてあるけどな。
- 580 名前：デフォルトの名無しさん mailto:sage [2007/09/12(水) 00:53:38 ]
- >>579
それドトネト1.1のころの制限じゃない？
- 581 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 10:08:16 ]
- なんと言う次世代
- 582 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 10:59:42 ]
- 次世代試作機・・・。
- 583 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 13:48:51 ]
- Javaを拡張するのではなく、OSを拡張するというのはJSRにならんのかね？
例えばjinputをJava標準にするための下地にするためにとか。
- 584 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 14:16:31 ]
- JDK7 build20
download.java.net/jdk7/binaries/
download.java.net/jdk7/changes/jdk7-b20.html
- 585 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 19:49:01 ]
- そういやjdk7が出来たらOpenJDK6をOpenJDK7ベースで再構築してOpenJDK6をGPL2で配布するらしいな。
将来的には公式バイナリも完全にOpenJDKからビルドするらしい。
- 586 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 12:58:01 ]
- ７は変な機能増えすぎ
もっとシンプルに保てよ
- 587 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 13:16:10 ]
- クロージャというか関数導入するならperl見たいな複数戻り値の関数もできるようにしてくれ
- 588 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 14:09:47 ]
- 多値返せたらいいのにと思うことはよくある
- 589 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:38:35 ]
- 時々、妙に多値希望の人っているよね
そういう人はロートルだと思っておｋ？
- 590 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:39:53 ]
- 多値が返せる言語ってあるの？
- 591 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:44:03 ]
- Perlしかしらない。
ただstateとvalueみたいな多値が欲しいがために
ReultFooみたいなクラスを書くのはなんだかなぁと思うときは多い。
- 592 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 16:23:13 ]
- lispまでいくと多値というよりリストか
Object[]のシンタックスシュガーで十分なんだけどな
C#のstructなんかよりずっと有用
- 593 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 17:16:56 ]
- pythonのtupleみたいなの。
まあ、Object[]でもいいけど。
>>591みたいな
型に名前つけるのが面倒なんだよ。
- 594 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 19:17:12 ]
- Pair<A, B> みたいなクラスを作って使いまわすとか
- 595 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 19:48:49 ]
- 最近は多値返せる言語増えたよ。
javaだとどうせバイトコードレベルでは配列になるんだろうね。
- 596 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:16:58 ]
- public const<String, Boolean> getResult() {
return const { "おｋｗｗｗｗ", true };
}
こんな感じで死にキーワードを流用できないものか
|
 |
