回答編集履歴
4
文章表現訂正
test
CHANGED
@@ -14,4 +14,4 @@
|
|
14
14
|
|
15
15
|
|
16
16
|
|
17
|
-
最近別の質問の回答でも見かけましたが効率について気にするなら(中の仕組みを知っておくことに損はないものの)性能評価して実際の問題を見つけることのほうが大切なのだろうと思います。性能上問題ないことろでfalse
|
17
|
+
最近別の質問の回答でも見かけましたが効率について気にするなら(中の仕組みを知っておくことに損はないものの)性能評価して実際の問題を見つけることのほうが大切なのだろうと思います。性能上問題ないことろでfalse/Boolean.FALSEのどちらがいいとかは時間のあるときに「やってみる」ならいいものの、これに拘泥しすぎないほうがよいかも知れませんね。
|
3
記述が不正確な点を訂正
test
CHANGED
@@ -2,7 +2,7 @@
|
|
2
2
|
|
3
3
|
|
4
4
|
|
5
|
-
前者のコードは、「なんかする」部分にiがIntegerでないと都合が悪い点があると考えられます。ただ比較はi==100としたほうがいいような気がします。見やすいですし、i.equals(100)と書くとboxingによりヒープが消費されます。i==100ならiがunboxingなのでヒープの消費はなく効率面からも少しよいコードと思います。
|
5
|
+
前者のコードは、「なんかする」部分にiがIntegerでないと都合が悪い点があると考えられます。ただ比較はi==100としたほうがいいような気がします。見やすいですし、i.equals(100)と書くとboxingにより**ヒープが消費される可能性**があります。i==100ならiがunboxingなのでヒープの消費はなく効率面からも少しよいコードと思います。
|
6
6
|
|
7
7
|
|
8
8
|
|
2
追記
test
CHANGED
@@ -7,3 +7,11 @@
|
|
7
7
|
|
8
8
|
|
9
9
|
後者のfalseを返すコードはBoolean.FALSEと書いたほうが若干効率がよいかも知れません。なぜならfalseとかくとboxingのため暗黙的にBoolean.valufOf(false)が呼び出されるからです。しかし見やすさの点からいえばfalseと書きたいと自分は思います。高頻度で呼び出されるなら効率を気にするかもしれません。
|
10
|
+
|
11
|
+
|
12
|
+
|
13
|
+
---
|
14
|
+
|
15
|
+
|
16
|
+
|
17
|
+
最近別の質問の回答でも見かけましたが効率について気にするなら(中の仕組みを知っておくことに損はないものの)性能評価して実際の問題を見つけることのほうが大切なのだろうと思います。性能上問題ないことろでfalseでいいとかBoolean.FALSEでいいとかは時間のあるときに「やってみる」ならいいものの、これに拘泥しすぎないほうがよいかも知れませんね。
|
1
誤記修正
test
CHANGED
@@ -1,8 +1,8 @@
|
|
1
|
-
javaの言語仕様上の制約としてジェネリック型の要素としてプリミティブ型が使えないのでList,HashMap等々の要素にint,booleanを入れたい場合はInteger,Boolean等々を使わざるを得ません。そういう目的があ
|
1
|
+
javaの言語仕様上の制約としてジェネリック型の要素としてプリミティブ型が使えないのでList,HashMap等々の要素にint,booleanを入れたい場合はInteger,Boolean等々を使わざるを得ません。そういう目的があるならやむをえずということになるでしょう。
|
2
2
|
|
3
3
|
|
4
4
|
|
5
|
-
前者のコードは、「なんかする」部分にiがIntegerでないと都合が悪い点があると考えられます。ただ比較はi==100としたほうがいいような気がします。見やすいですし、i.equals(100)と書くとboxingによりヒープが消費されます。i==100ならiがunboxingなのでヒープの消費はなく効率面から
|
5
|
+
前者のコードは、「なんかする」部分にiがIntegerでないと都合が悪い点があると考えられます。ただ比較はi==100としたほうがいいような気がします。見やすいですし、i.equals(100)と書くとboxingによりヒープが消費されます。i==100ならiがunboxingなのでヒープの消費はなく効率面からも少しよいコードと思います。
|
6
6
|
|
7
7
|
|
8
8
|
|