2013年01月30日

[java]Dolphin!(4)

どこまで書いたかな・・。


//(3)String Switch
String str1="abcde";
switch(str1)
{
case "hoge":break;
case "huga":break;
case "abcde":System.out.println(str1);break;
}


キタ━━━━(゚∀゚)━━━━!!
もうこれでしょーもない private static final int とか Enumを作らなくてよいし、
ソース分析時に、このswitchの数字の意味はなんなんだ・・・、43だけスルーとかなんなんだ・・・。
コメントねーし、ぐぬぬぬぬ(`皿´;)とかも解決!

よし、まぁ待て。落ち着け。
内部ではEnumに自動変換してそうな予感がしてしょうがない。

でゅわ、jdの出番だ。


String str = "abcde";

Object localObject1 = str;
int k = -1;
switch (((String)localObject1).hashCode())
{
case 3208229:
if (((String)localObject1).equals("hoge")) k = 0; break;
case 3213991:
if (((String)localObject1).equals("huga")) k = 1; break;
case 92599395:
if (((String)localObject1).equals("abcde")) k = 2; break;
}

switch (k) {
case 0:
break;
case 1:
break;
case 2:
System.out.println(str);
}

文字列ハッシュでswitchかーって感想だけだと、味気ないので、もうちょっと|д゚)カンサツ

if(localObject1.equals("hoge")){
}else if(localObject1.equals("hoge")){
}else if(localObject1.equals("abcde")){
}
でも良さそうな気がせんでもないし、実際昔はこう書くしかなかった。
でも、先にハッシュだけ比較するほうが計算コストが低くなるので
こういう実装なんだと思う。コンパイル時に対象のハッシュも確定できるし。

つまり、String#equals() の実装見てくれればわかるんだが
比較は大きくわけて5ステップある。

(1)自分自身か?
(2)文字列のインスタンス?
(3)文字数一致?
(4)ハッシュ一致?
(5)文字列のコンペア

(4)の処理は初回のみ実行時計算@インスタンスなので、
JDK7の実装だとハッシュ一致時のみしかラベル文字のハッシュ計算は走らないが、
旧の実装だと必ず走ってしまう。また、(2)の処理は意外にコストが要る計算である。
文字列以外が来る可能性が_でもあるなら、しょうがないけど。

ということで涙ぐましいコスト最適化がかかっているために、こういった表記なんだと思うんだね。


posted by koteitan at 11:07| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック