07/05/02 09:35:38
野次と荒らしは2chの花
931:デフォルトの名無しさん
07/05/02 11:39:25
>>930
ｦﾀとDQNが抜けてるぞ
932:デフォルトの名無しさん
07/05/03 06:00:15
>>925
どう実装されるかはしらんが、プリミティブ型を追加するという時点でVMに手をいれないといけないのは決定だろ。
933:デフォルトの名無しさん
07/05/03 09:20:31
C99だと
struct complex {double real, imag;}
struct complex {double z[2];}
とかで実装されてるんじゃないか。
だからコンパイラの拡張のみでマシーン（VM)の方に手を入れることはない。
というか、一般人が実装のことを考える事自体が意味ないじゃん。
934:デフォルトの名無しさん
07/05/03 09:32:36
配列で大量に計算する用途だとクラスよりC#の値型のようなものがあるとベターだな。
935:デフォルトの名無しさん
07/05/03 09:58:40
>>933
えーと。
結局、プリミティブな複素数型は特に必要がなくてクラスでやってもOKって話かな？
本当に複素数型欲しいなら
現時点でGPLで配布されてる javac に複素数型導入して公開したり、
そのパッチを ksl に投稿してみるとか、
BugDatabaseに行って、RFE出すとか既存のRFEに投票するとか、
その bugID 晒して、皆に投票呼びかけたりとか、
もちっと前向きな行動した方が良いと思うよ。
ここで複素数追加みたいなネタ振られたって、
皆でどーゆー実装するのか妄想して遊ぶぐらいしかできないでしょ。
936:デフォルトの名無しさん
07/05/03 10:09:09
座標上の点の計算には便利そうだ。特に回転とか。
複素数クラスがあってもnewしまくるから遠慮してたけど、
言語に追加されるなら便利そうだけどな。
今のトレンドは言語に複素数を追加することなんじゃないか。
C,D,Pythonは既に言語レベルでサポートしてるし。
937:デフォルトの名無しさん
07/05/03 10:25:59
トレンドってほど支持する流れも否定する流れも大きくないと思うが……
938:デフォルトの名無しさん
07/05/03 10:37:45
>>933
頭悪そう
C99を使ってろ
939:デフォルトの名無しさん
07/05/03 10:53:07
>>936
ちなみに、何を作りたくて複素数型が必要なんだ？
940:デフォルトの名無しさん
07/05/03 10:57:23
>>934
C#の値型は、クラスと比べてどんなメリットがあるの？
コンパイル時に最適化されて
ランタイム負荷が小さいとか？
941:デフォルトの名無しさん
07/05/03 12:34:41
>>940
クラスのオブジェクトに比べ生成と削除のコストが低い。
値型は参照を介せずにスタックに直接値が格納されたり、
配列やクラスのメンバーとして直接その領域に値が格納されるので
ボクシングが発生しない限りGCの必要な実体が作られることがない。
このためプリミティブ型に近いパフォーマンスを発揮する。
942:デフォルトの名無しさん
07/05/03 12:45:20
>>939
必要ないんでしょ。
ってか、実際に複素数型が必要な分野のプログラム組んでる人間が
「演算子オーバーロードよりもプリミティブな複素数型」なんて言うとは考えられないし。
943:デフォルトの名無しさん
07/05/03 14:50:30
>>941
値型ってのが広い範囲を表すからいいたいことがあいまいだぞ
944:デフォルトの名無しさん
07/05/03 15:00:41
下手に構造体チックなものが登場されてもBeanの文化が壊れるから
ByteBufferで我慢が出来ないなら諦めてくれって方針で十分。
945:デフォルトの名無しさん
07/05/03 19:32:28
>>933
だから、それはプリミティブ型じゃないだろ。
946:デフォルトの名無しさん
07/05/03 20:49:44
Ｃ＃の値型みたいなのがほすぃ
って言いたかっただけなんじゃないか、と。
947:デフォルトの名無しさん
07/05/03 21:32:14
>>946
Java に C# の値型みたいなの導入すると
コンパイラ弄るだけじゃすまなくて、それこそ VMの変更が必要なりそうだし。
メソッドの戻り値で値型を使う場合とか。
それに、C# は最初から値型があったから良いけど、
Java の場合は generics 導入しちゃった後だからねぇ。
今から C# の値型みたいなものを追加したとしても
現時点でのプリミティブ型みたいに generics で使えなさそうだし。
948:デフォルトの名無しさん
07/05/03 21:52:46
Javaも遅かれ早かれVMの拡張は必要になると思うのだがいつごろ来ると思う？
949:デフォルトの名無しさん
07/05/03 22:05:05
>>948
おいおい……
バイトコードインストラクションの話ならJSR-292のinvokedynamic追加の検討中。
後は>>893がfunction type関連でVM拡張とか言ってる。
950:デフォルトの名無しさん
07/05/03 22:13:31
>>949
さんくす。複素数の議論でVM拡張は避けるべき的な話が出てたので確認してみた。
別にVM拡張前提で話をしてもかまわないわけだよね。
951:デフォルトの名無しさん
07/05/03 22:21:32
>>950
ここは「次世代Javaの動向」をヲチるスレだから、
新機能追加の要望とか、単なる妄想オナニーなら他所でやってくれ。
952:デフォルトの名無しさん
07/05/03 22:24:40
だれもVM拡張は避けろといってなくて、プリミティブ型を追加するならVM変更という話と、そんな無意味な要求は却下されるよという話が同時進行してただけかと。
953:デフォルトの名無しさん
07/05/03 22:28:41
>>951
ヲチするだけとはどこにも書いてないわけで。
しかも、最初から要望とか妄想オナニーばかりのスレで、950も過ぎてから言ったところで説得力ない。
954:デフォルトの名無しさん
07/05/03 22:32:05
>>953
今回ので言えば、既に >>935 で他所行けって出てるし。
他の話題でも他所行けってのは散々出てるし。
955:デフォルトの名無しさん
07/05/03 22:38:34
つまり、スレの流れについていけなくてわめいてるってわけか。
956:デフォルトの名無しさん
07/05/03 22:41:32
>>953
便所に落書きしても要望だとは思われないよな。普通は。
957:デフォルトの名無しさん
07/05/04 01:17:58
複素数を扱うライブラリがあれば便利だと思うが
言語仕様に含めるのはやり過ぎです。
ところで値型って、VBのByValを指しているの？
958:デフォルトの名無しさん
07/05/04 01:45:44
>>957
ここは予想や感想を述べる場所じゃないとのことなので、
そういう動向は今のところ無いということでおしまいらしい。
値型はVB.NET以降では、ユーザー定義型（Structure）、Enum、クラスを除くVBの基本データ型をさす。
VBのデータ型と.NET(CLR)のプリミティブ型は若干違うから注意。
ここではユーザー定義型（Structure）の意味で使ってる。
.NET(CLR)ではValueType C#ではstruct。
Javaだと参照型以外の型＝プリミティブ型＝値型という理解でいいのかな？（自信は無いが）
あとは質問か雑談スレへとかいわれそうだ。
959:デフォルトの名無しさん
07/05/04 03:50:43
>>956
「普通は。」ってなんだよ 9m(^x^
960:デフォルトの名無しさん
07/05/04 09:51:42
C#：全部ヒープに置いたら遅いだろ！struct導入する！
Java：エスケープ分析で自動的にスタックに置くｳﾏｰ
961:デフォルトの名無しさん
07/05/04 12:14:58
どうもsturct(値型）の話になってるようだけど、なんなら
typedef double complex[2];
でいいじゃん。どう実装されるかなんかはベンダ任せなんだけどね。
962:デフォルトの名無しさん
07/05/04 19:07:54
ベンダ任せなわけがない
963:デフォルトの名無しさん
07/05/04 20:59:25
Hさん、居るよね。
964:デフォルトの名無しさん
07/05/05 21:03:27
MさんとKさんもいるよね。