06/08/31 09:15:02
>>828
> >>807
> >だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
> >>805のような動的実行コード生成をC, C++でもやればいいだけの話。
> >で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
> >OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。
> if(SSE２命令が利用可能か？) {
> // SSE２命令を利用したインラインアセンブラによるコード
> }
> else {
> // SSE２命令を利用しないインラインアセンブラによるコード
> }
> これのどの辺りが動的実行コード生成になるのか説明してくれんか？
> 無知は怖いね。
無知晒し上げ
886:デフォルトの名無しさん
06/08/31 09:31:54
最近、各種OSは、
securityがらみでdata領域を実行出来なくする方向だけど、
JIT/HotSpotはそれじゃ困るやね。
887:デフォルトの名無しさん
06/08/31 10:01:01
>>883
.いや、たぶん実用にはならないだろうなあとは試してみて俺も思ったけど
まだそういう処理系は無いという前提で話が進んでいるように見えたので、
一応そういうものはあるということが言いたかっただけ
888:デフォルトの名無しさん
06/08/31 11:34:40
>>884
なんかcocoaとかで見る名前だね。
あたりまえか。
何でこれがSunにおいてあんだ？
889:デフォルトの名無しさん
06/08/31 11:44:02
>>885
ﾄﾞﾄﾈﾄ厨笑えるw
890:デフォルトの名無しさん
06/08/31 11:59:42
>>888
OPENSTEP
891:デフォルトの名無しさん
06/08/31 12:44:51
>>886
デフォルトが実行不可になるってだけで、
別途実行可能な領域を確保する方法は用意されている。
たとえばUNIX系ではmmap()にPROT_EXECフラグを付けて領域を確保すればいい。
というか、IA32アーキテクチャではNXビットがサポートされるようになったごく最近まで
PROT_EXECフラグの有無にかかわらず常に実行可能になっていたってだけで、
他のアーキテクチャでプログラムしていた連中にとっては今更って話だろうね。
892:デフォルトの名無しさん
06/08/31 15:09:33
Java6.0っていつリリースされるの？
893:デフォルトの名無しさん
06/08/31 19:36:00
>>888
これSunがSolarisにポートした幻のOPENSTEPのやつだな
俺リアルで使ってたけど、、
894:デフォルトの名無しさん
06/08/31 19:56:15
>>1の「分離」とかSockets Direct Protocol
はMustangで実現してなくないか？
dolphinで?
895:デフォルトの名無しさん
06/08/31 19:58:30
>>892
そのうち
896:デフォルトの名無しさん
06/08/31 20:45:38
That house?
897:デフォルトの名無しさん
06/08/31 21:11:58
次のjavaではインライン・アセンブラが出来るようなる
らしい・・・
898:デフォルトの名無しさん
06/08/31 21:49:05
>>892
Java6.0はリリースされない
リリースされるのはJava6
899:デフォルトの名無しさん
06/08/31 22:14:09
>>897
ネタだろうけど、あえて反応してみる。こんな感じか？
public class HelloWorld {
public static void main(String[] args){
asm("getstatic java/lang/System.out:Ljava/io/PrintStream;");
asm("ldc \"Hello, World\"");
asm("invokevirtual java/io/PrintStream.println:(Ljava/lang/String;)V");
}
}
しかし、もし仮に本当にJavaにインラインアセンブラが搭載されたとしても、goto
使えるくらいしか利点が無さそう…
バイトコードレベルでは、大した最適化もできんし、JITコンパイラの最適化を阻害する危険もあるしな
900:デフォルトの名無しさん
06/08/31 22:45:40
>>899
>>897はネタの匂いがするけど
それだったらJava標準でなくてもすでに誰かが
作ってそうだ。
Java 6ではそれと似たような方式でスクリプト言語をサポートしていたし。
結局、Jakarata OROと同じように文字列のエスケープは避けられないというわけで。
外部ファイルに置いた場合だけエスケープしなくて済むってほうが言語としてまともだね。
901:デフォルトの名無しさん
06/08/31 23:43:59
コンパイラサポートすんだから普通にやるんじゃないか。
902:デフォルトの名無しさん
06/09/01 00:06:39
>>892
2006年10月以降？
URLﾘﾝｸ(journal.mycom.co.jp)
903:デフォルトの名無しさん
06/09/01 06:18:20
>>902
ありがとう！
904:デフォルトの名無しさん
06/09/01 09:52:57
この秋といってたけど、１１月以降が濃厚だな。
905:デフォルトの名無しさん
06/09/01 11:13:19
Java6の魅力はＧＵＩまわりの強化くらいかね。
アノテーションが増えたって言うけど、どんなもんが増えた？
新たにGenerics対応したクラスも出る？
906:デフォルトの名無しさん
06/09/01 14:30:24
> JVMはどうやってガベコレを実装してるの？
JVMにはJava言語用に作られたGCがあるだけで、C言語には使えないよ。
907:デフォルトの名無しさん
06/09/01 14:41:41
>>906あんまり正確じゃないなその表現は。
908:デフォルトの名無しさん
06/09/01 15:37:41
いつになったら.NET並の速度になるん？
909:デフォルトの名無しさん
06/09/01 16:00:38
javaと.netは目指しているものが違うから同じように比べてもねぇ
910:デフォルトの名無しさん
06/09/01 18:50:50
>>908
CLR の仮想関数呼び出しは遅すぎで使い物にならないわけだが。
Pure Java と Pure C# なライブラリを比較すると
明らかに JVM >>>>>>>>>>>> CLR であることがわかる。
911:デフォルトの名無しさん
06/09/01 19:32:29
>>908
ドトネト並みっていってるが、
ドトネトだってJavaより遅いのは遅いぞ。
どっちもVM上で動いているんだから。
どっちも遅いんだし。
比べるならC/C++とのほうが重みがある。
ドトネトだとVMの性質がJavaと異なるし
得意分野、得意分野が微妙にことなる。
912:デフォルトの名無しさん
06/09/01 19:39:22
Java6 mustang = null;
Java5 tiger = new Java5();
tiger.swing++;
tiger+=derby;
tiger+=webServer;
Java6 mustang = (Java6) tiger;
こんな感じかな？
913:912
06/09/01 19:40:07
最初の一行いらないね。失礼。
914:デフォルトの名無しさん
06/09/01 20:48:22
NETが日本で最も普及しているプログラム言語
ｽﾚﾘﾝｸ(tech板)
915:デフォルトの名無しさん
06/09/01 21:17:57
>>912
Java5型はオブジェクトの型なのか文字列型なのか数値なのか
どっちみちString型の猿まねはできないし++や+=を使えるのは
Stringオブジェクトか数値型だけなのでエラーになるわな。
916:デフォルトの名無しさん
06/09/01 21:18:20
>>914
つまらんし、根拠がない
917:デフォルトの名無しさん
06/09/01 21:28:45
>>915
オペレータオーバロードｷﾀ━━━(ﾟ∀ﾟ)━━━!!!!
918:デフォルトの名無しさん
06/09/01 21:51:25
>>911
わからないでもないが、同じバーチャル・マシンという環境で比べた方が公平だと思うぞ
Cはネイティブ・マシンだろ
またガベコレがどうしたこうしたとかなのか？
919:デフォルトの名無しさん
06/09/01 21:52:39
ネイティブ・マシン……
920:デフォルトの名無しさん
06/09/01 22:02:58
そういや、Stringには++使えないんだった。
つーかJavaに演算子オーバーロードなんて期待すべきでないし
勧めるべきじゃない。
C++の二の舞になったC#と同じ道を歩む。
あれは大失敗だった。
921:デフォルトの名無しさん
06/09/01 22:05:07
>>918
同じVMといってもな、VMは各種ベンダによって速度が異なるし。
IBMが作ったのとSunが作ったのとではJVMの速度やライブラリによる速度も変わってくる。
その辺りも厳密に考えないと逝けない。
そう考えると、面倒だし議論するだけ無駄だと思うんだが。
そういう比較は、こだわると、FFとドラクエとを比較するくらい実にくだらない議論になると思うよ。
922:デフォルトの名無しさん
06/09/01 22:20:11
>>921わかってるじゃん。
923:デフォルトの名無しさん
06/09/02 00:26:08
>>905
1.2～1.4のようにデスクトップアプリが大幅にパワーアップするようなのはあんまりなさそうだ
5.0以降デスクトップに力入れてますといってるけど、小粒なのが多くて
むしろ力入れてないのではと思いたくなる
924:デフォルトの名無しさん
06/09/02 02:48:50
public class Java6 extends Java5{
Swing swing = getSwing().add(new AntiAlias());
DB db = new Derby();
public Java6() throws NotReleasedException{
try{
openSource();
}catch(Exception e){
log.error("やっぱり無理だった");
}
throw new NotReleasedException("もうちょっとまって");
}
}
925:デフォルトの名無しさん
06/09/02 03:40:53
しかし.NETのCLRが「速い」というのは初めて聞く意見なんだが、
なんか速くなったのか？ ずっと「遅い遅い」と言われ続けてたと
思うんだが。
926:デフォルトの名無しさん
06/09/02 10:27:07
>>920
演算子のオーバーロードは便利だよ。演算子オーバーロードじゃなくても、
クラスごとに演算子の動作を定義できるのは便利。
C＋＋のはいけてないけど、pythonのように、演算子ごとに対応するメソッドを
用意する方法ならわかりやすいし、実装も簡単（コンパイラに手を入れるだけで済む）。
Javaユーザは、Javaにない機能はすぐに「あんなものイラネ」とかいいだすから嫌い。
927:デフォルトの名無しさん
06/09/02 10:38:16
>>926
> Javaユーザは、Javaにない機能はすぐに「あんなものイラネ」とかいいだすから嫌い。
激同
で、いらないっていいながらJavaに実装されるといきなりﾏﾝｾｰし始めるからもっと嫌い。
Javaは好きだがJavaをまともに使えるのはほんの一握り。大抵は基礎の無い阿呆ばっかだ。厨の割合が高過ぎる。
928:デフォルトの名無しさん
06/09/02 10:40:06
少なくともBigなんちゃらや日付時間関係は演算子使いたいよな
文字列だけ砂糖付きはずるいぞ
929:デフォルトの名無しさん
06/09/02 11:06:01
> 厨の割合が高過ぎる。
そういう業界だろｗ
930:デフォルトの名無しさん
06/09/02 11:30:59
>>928
BigDecimalが対応されたらクライアント用でも業務系での地位は確定するな
931:デフォルトの名無しさん
06/09/02 12:11:19
>>926
>>927
そんなもの別にJavaユーザに限った話じゃないでしょ。なんですぐにそういう話になるかなあ
C++ユーザだってよく、Javaに対して、GCなんてイラネとか言っているのは耳にする
ある程度普及した言語には、厨や信者が一定割合でつくというだけの話だと思う
932:デフォルトの名無しさん
06/09/02 12:17:23
>>926
演算子っつーと、[] も演算子だよな。
数値計算しないから + や - のオーバーライドはできなくても個人的には困らんけど
MapやListで list.get(0) や map.get("key”) が list[0] や map["key"] と書けるようになるとうれしいなあ。
933:デフォルトの名無しさん
06/09/02 12:30:06
listのほうは難しい気がするがmapのほうは現行の構文とかさならないからできそうな気がするんだけどね
とおもったけどキーがIntegerとかでintわたしてオートボクシングとかされると配列とみわけがつかんか
934:デフォルトの名無しさん
06/09/02 13:41:26
>>926-927
大丈夫か？MSや.Netマンセーなのか？
例えば、そんなのオレは面倒とかを除けば、
やってる事は同じなんだけど、そういうの気がつかないのかな。
プロパティとかインデグザとか。
delegate, eventはいいね。なんともMSらしい。
935:デフォルトの名無しさん
06/09/02 13:45:56
コンパイラをいじれば、
いつでもできるんじゃないの。
ただ実質同じことだし、
そういう要求をかなえてまで、
面倒くさいぞー系の蛆が溢れると、
Javaの品質が下がるからまだ今もやらないってこと。
936:デフォルトの名無しさん
06/09/02 17:43:09
>>926
Genericsは、「あんなものイラネ」と言われたことないよ。
937:デフォルトの名無しさん
06/09/02 17:46:46
>>936
Genericsイラネ
938:デフォルトの名無しさん
06/09/02 17:50:21
>>937
C厨
939:デフォルトの名無しさん
06/09/02 17:58:10
>>933
なんでlistだと難しいのかくわしく。
940:デフォルトの名無しさん
06/09/02 17:58:15
JavaもtoStringは演算子オーバーロードできるしな
例えばインタフェースベースの演算子オーバーロードなら
interface Calculateableみたいなのを用意して
Numberと同じメソッド定義しておけば、目的を見失うことも無いだろう。
941:デフォルトの名無しさん
06/09/02 18:04:28
>>939
配列と区別がつかないからだろ
942:デフォルトの名無しさん
06/09/02 18:33:17
個人的には言語仕様の拡張はしなくてもいいから
VMの性能とデスクトップ周りの強化をしてほしいな・・・
943:デフォルトの名無しさん
06/09/02 18:36:08
>>942
それは着々と進んでるだろ。
944:デフォルトの名無しさん
06/09/02 20:03:27
>>941
区別はつくよ。むしろなんで区別がつかないと思うのか聞きたいところだ
945:デフォルトの名無しさん
06/09/02 20:26:27
128bit Java
946:デフォルトの名無しさん
06/09/02 20:45:46
>>926
おまえは何も解ってない。
ストラウストラップが警告した事項を
947:デフォルトの名無しさん
06/09/02 20:45:57
>>944
もちろんコード全体を見りゃ区別はつくさ
objs[i]と書いてあるときにobjsは配列かListか
すぐには判断できない場面があるわけだ
両者が共通の性質やAPIを持つなら区別できなくても問題ないけどな
実際には配列は固定長だし、APIもlengthでサイズを知るなど異なるわけ
配列を廃止するならともかく両立させるのは混乱の元
948:デフォルトの名無しさん
06/09/02 20:47:03
>>926-927は同一人物による書き込みだよな
949:デフォルトの名無しさん
06/09/02 20:48:17
>>932
[]は単項演算子みたいなもんだからいいんだよ
+や-となると２項演算子なので
演算子の優先順位を意識するのが大変になるんだよ。
それに他人が作った奴の演算子が混ざったらどうなると
思ってるのか。
950:デフォルトの名無しさん
06/09/02 20:49:15
>>932
> MapやListで list.get(0) や map.get("key”) が list[0] や map["key"] と書けるようになるとうれしいなあ。
その程度のことのためだけにそんな演算子を付加するのか。
C#のget/setと変わらないくだらん機能だな
951:デフォルトの名無しさん
06/09/02 20:52:14
>>940のやり方なら間違った演算子定義は出来ないからいい。
問題があるとすれば右辺値の一番左の値がプリミティブじゃなかったときくらい。
952:デフォルトの名無しさん
06/09/02 21:28:30
>>942
俺的には、Java3Dの強化をなんとかして欲しいな。
953:デフォルトの名無しさん
06/09/02 21:29:01
>>947に激しく同意できる。
C++の二の舞になったら終わりだ
954:デフォルトの名無しさん
06/09/02 21:30:17
統合アーカイバプロジェクト並みの圧縮ファイル対応とか
デスクトップ周りでやらなきゃいけないことは、まだまだ沢山あると思う
デスクトップ周り専門のApacheみたいなグループが登場しないと無理だが
955:デフォルトの名無しさん
06/09/02 21:33:18
BigDecimalで演算子を使えるようにしてくれって要望は、
BigDecimalクラスをラッパークラスとするプリミティブなbigdecimal型を
用意するっていうC#のdecimal型でどうにかするって手もあるが、
あれは、128bits限定だからな。
BigDecimalのコンストラクタにMathContext.DECIMAL128を設定した
精度しか得られないしな。
956:デフォルトの名無しさん
06/09/02 21:34:11
>>954
圧縮ファイルで一体何をしたいんだ？
つか、Jakarta Commonsにそれっぽいのないか？
もしくはSourceForgeにありそうだが
957:デフォルトの名無しさん
06/09/02 21:39:17
何がしたいって聞くようなことか？
958:デフォルトの名無しさん
06/09/02 21:41:01
Commons Compressだったかがβすら出ずに存在したような気がする
959:デフォルトの名無しさん
06/09/02 22:24:20
>C#のget/setと変わらないくだらん機能だな
Java7の拡張の候補にプロパティが入っているのだけどな。
960:デフォルトの名無しさん
06/09/03 00:04:24
入ってたとしても、C#と全く同じってことはなかろうと予測
961:デフォルトの名無しさん
06/09/03 00:27:08
>>959それどこの記事でわかるの？
962:デフォルトの名無しさん
06/09/03 00:32:42
>>959がデマだったりすることはよくある。
あの文体は、いつものJavaスレを荒らしてるドトネト厨だから。
3年も4年も前からJavaスレや死滅スレで大暴れしてる変態。
963:デフォルトの名無しさん
06/09/03 00:35:56
やっぱりドトネト棒ってハズレだったんだね。
コーヒーの方が大人だね。
964:デフォルトの名無しさん
06/09/03 00:42:45
>>961-963
まずこのスレを「プロパティ」で検索してみたらどうなんだ？
965:デフォルトの名無しさん
06/09/03 00:45:38
URLﾘﾝｸ(journal.mycom.co.jp)
にしっかりと「プロパティのサポート」が発表されたと書いてあるんだが。。。
プロパティサポートといっても、それがget/set生成みたいなもの
なのか、式言語みたいに「obj.property」というようにアクセスできる
ようにする、という意味なのか、groovyの「@Property」みたいに
@Property size
とか宣言できるようにするのか、といった具体的な話はまったくない
わけだけど。
966:デフォルトの名無しさん
06/09/03 00:48:13
>>962
>>963
こういうやつらっていつになったらJavaの世界から消えてくれるんだろ
967:デフォルトの名無しさん
06/09/03 01:05:16
>>963
ドトネト棒って語呂と名前がｳｹﾙw
968:デフォルトの名無しさん
06/09/03 01:08:17
>>965
その、アノテーションっぽい気がした。
@Propertyならいいねえ。
get/setはねえちょっと。
getter.setterに相当するメソッドに
@Propertyアノテーションをつけるのが妥当って感じだね。
969:デフォルトの名無しさん
06/09/03 03:11:05
>>967それも棒の先には「おまえらは、ハズレ」って書いてあるんだろうだしｗｗｗ
970:デフォルトの名無しさん
06/09/03 10:27:31
>>946
「ストラウストラップが警告した事項」って具体的に何？
>>947
おいおい、Javaは静的な型があるんだから、別にコード全体を見るまでもなく、変数の宣言部分をみれば配列かListかはすぐに判断できるし、別に混乱なんかしないだろ。
この程度で混乱なんかしないでくれよ。
>>949
[]は単項演算子じゃなくて、+や-と同じ２項演算子だよ。
それに演算子の動作を自分で定義できることと、演算子の優先順位は関係ないよ。
PythonもRubyも演算子の動作を自分で変えられるけど、優先順位は変えられない。だから別に混乱しない。
>>950
でもELでは[]でアクセスできるようになってるよね。「その程度」のことであれば、
ELでも[]でなくてgetter/setter使えばいいはずだし、もっといえばEL自体必要ない。
Javaユーザは「[]なんてイラネ」といっておきながら、ELの[]は便利とかぬかすから嫌い。
971:デフォルトの名無しさん
06/09/03 10:39:13
>>970
言っている事自体はだいたいまともだが
> Javaユーザは「[]なんてイラネ」といっておきながら、ELの[]は便利とかぬかすから嫌い。
とJavaユーザを一緒くたにして煽るのはやめてくれ。ELの[]が便利と言っている層とJavaには[]は
イラネと言っている層がどれくらい重なっているのか調べたわけでもないだろう？
972:デフォルトの名無しさん
06/09/03 10:43:14
そもそもJSP上でaddなんてしないんだから[]で何の問題も無いだろ
粘着にレスすんなよ
973:デフォルトの名無しさん
06/09/03 11:30:35
>>970
いっとくが、JavaとELとは全く別の言語だ。
Javaユーザが[]はイラネといってるのはJavaの文法にいらねといってるだけで
ELの文法に[]がいらねといっとるわけではなかろう。
そんなこともわからないでJavaエンタープライズアーキテクトを侮辱するとは
身の程知らずもいいところだ。
974:デフォルトの名無しさん
06/09/03 11:50:25
JavaとELとが別言語なんてのはだれだってわかってる。
だからなんでわざわざELなんて用意されたかを考えろや。
Javaそのままだと書きにくいからELが用意されたんじゃないの。
Javaの書きにくさのひとつとして list.get(1) や map.get("key") があり、
これが list[1] や map["key"] とかけたらいいなといってるだけ。
ほんとうにlist.get(1)やmap.get("key")が書きやすい/読みやすいなら
ELでもそれをつかえばいいだけ（ELにはメソッド呼び出しないけど）。
「JavaとELとが別言語」なんて話がずれるだけじゃん。
975:デフォルトの名無しさん
06/09/03 12:13:34
>>971
> とJavaユーザを一緒くたにして煽るのはやめてくれ。
一緒くたにしている馬鹿には馬の耳に念仏では?
976:デフォルトの名無しさん
06/09/03 13:45:49
ｽﾚﾘﾝｸ(tech板)
次スレ
977:デフォルトの名無しさん
06/09/03 14:06:08
>>970
ストラウとラップは演算子のオーバーロードを
誤った使い方をするとろくなことがないぞってことを言ってるんだよ。
誤った使い方をしなければいいといっても
誤った使い方をする奴は腐るほどいるし。
それで複数の会社組織が独自に演算子を定義して
デスマって酷いことになるわけだ。
978:デフォルトの名無しさん
06/09/03 14:07:23
>>974
じゃあさ、お前にはなんでJakarta Velocityみたいなのが
用意されたのかわかるの？
プリプロセッサではなくVelocityが用意された理由を。
979:デフォルトの名無しさん
06/09/03 15:24:48
[]のオーバーロードは欲しいな。
980:デフォルトの名無しさん
06/09/03 15:35:42
ListだったらどうせIterator経由でアクセスしない？
List.getなんて滅多に使わなくないか？
981:デフォルトの名無しさん
06/09/03 17:07:07
んだな
982:デフォルトの名無しさん
06/09/03 17:47:33
しかもIteratorにはfor(:)の砂糖が既に入ってるしな
983:デフォルトの名無しさん
06/09/03 19:27:06
うむ、そうだ
984:デフォルトの名無しさん
06/09/03 20:02:49
次世代は無糖でｗ
985:デフォルトの名無しさん
06/09/03 20:23:27
new ArrayList=("あああ","いいい","ううう");
みたいに出来んかな。
public ArrayList(String... varArgs);
こんな感じのコンストラクタで。
986:デフォルトの名無しさん
06/09/03 21:05:54
>>985
それもだけど、
ArrayList#addAll(Collection<? extends E> c);も、
c.toArray();で配列に直してから使ってる。
ArrayList#addAll(E[] c);がないのはもったいない。
987:デフォルトの名無しさん
06/09/03 21:46:14
>985
Arrays.asListでいいんでないの？
988:デフォルトの名無しさん
06/09/03 21:55:40
あーたしかにコレクションをパっとつくりたいと思ったことはあるな。
とくにテストコードで。
今だと
List strList = Arrays.asList( new String[]{"test1", "test2"});
とかやっててくどいとは思う。
一方で、Javaの、文法はシンプルに、機能はクラスライブラリで、という
スタンスは嫌いじゃない。文法拡張するときは「そんな砂糖いらね」という
抵抗があったほうがちょうどいいと思うぞ。やたら拡張するよりはね。
989:デフォルトの名無しさん
06/09/03 23:11:48
>>987
確かに5.0のArrays.asListは
public static <T> List<T> asList(T... a)
だからまあ悪くないんだが、返ってくるのが変更不能リストなのがイマイチ
変更可能リストを返すメソッドが欲しいな。コードはこんな感じで
public class ListUtil {
public static <T> List<T> list(T... a){
List<T> newList = new ArrayList<T>();
for(T t : a) newList.add(t);
return newList;
}
}
使うときはstatic import使えば、
list("A", "B", "C", "D")
のようにするだけで変更可能なリストが作れるので便利
990:デフォルトの名無しさん
06/09/03 23:21:03
>>985
まるでPerlやPHPまんまだな
991:デフォルトの名無しさん
06/09/03 23:24:05
>>989
それもPHPまんまやないか
992:デフォルトの名無しさん
06/09/03 23:32:02
>>991
意味不明。PHPで、array(...)などとして配列が作れることを言っているつもり？
そんなもん別にPHP(やPerl)独特のものでもなんでも無い。
なんで厨はすぐに自分の知っている(好きな)言語の機能のパクリかのように言いたがるかなあ
993:デフォルトの名無しさん
06/09/04 00:30:14
なになに、どっちにしろ型の概念が曖昧な
スクリプト言語に共通する書き方だよな
994:デフォルトの名無しさん
06/09/04 00:52:40
>>980
for( : )使うことが多いけど速度の差も結構あるし
何番目かを意識したりループの中で挿入とか削除とかもある
for( : ) 使うのが80％くらいかな
995:デフォルトの名無しさん
06/09/04 01:05:58
O'Camlなみに型推論しる！
996:デフォルトの名無しさん
06/09/04 03:09:08
あのー・・・
997:デフォルトの名無しさん
06/09/04 07:23:57
>>989
Arrays.asListってlistの様に振る舞うけど、
結局は配列のままのwrapper返すんじゃないの?
998:デフォルトの名無しさん
06/09/04 07:32:05
>>997
確かそう。
これをArrayListに追加するときは、>>986のようにまた配列にもどして使うのでもったいない。
999:デフォルトの名無しさん
06/09/04 08:09:13
>>989
new LinkedList(asList(a, b, c, d))
でいいやん。
1000:デフォルトの名無しさん
06/09/04 08:17:59
asXxxはビュー(実態は変わらず見方を変えたもの)を返す、ってことだな。
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。