[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 06/02 00:24 / Filesize : 227 KB / Number-of Response : 943
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

eclipseってそんなに良いか?【エクリプス】



1 名前:デフォルトの名無しさん [04/11/01 18:12:24]
タダより高いものは無い。

207 名前:デフォルトの名無しさん [2006/03/31(金) 00:31:33 ]
小回りきかないというのは、具体的にどんな点?

208 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 01:20:34 ]
>>199

Connection refused なんだから,
そもそもどこのサーバに繋げようとしているのか?説明しろ!



209 名前:デフォルトの名無しさん [2006/03/31(金) 02:25:47 ]
名前が厨臭い
スレイプニルと同じ臭いを感じる

210 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 10:25:47 ]
>>209
そうか?SUNを隠す/消すってことだろ。


211 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 10:47:13 ]
一時的にね

212 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 10:59:25 ]
ププ >>1は現実を知らないようだな。

# Slashdot での大論争。これは今までで一番愉快な
Java 対 C++ の議論に違いありません。
C++ 愛好家は必死に「不公平だ、こっちはメモリ管理を
手動でやらなきゃいけないのに」と主張しています。
公平を期するための彼らの提案は - System.gc() の
呼び出しを山ほど突っ込んで Java 側を遅くするというも
のでした(お気づきでない方のために。Java は System.gc()
を呼び出さなくてもメモリを回収します。 System.gc() の呼び
出しを追加してもメモリ回収の速度が遅くなるだけです)。
続く抗議もすべて、このベンチマークが Java をひいきしてい
るという一点に集中しているようでした。しかし奇妙なことに、
3年前までは当時の JVM をテストしても C++ の方が速いとい
う結果が出たものです。このノイズの山を掘り返せば、有意義
なコメントが見付かるかも知れません

# さらに続く議論。この事件から生じた騒動(または余分なキャラ)
で大儲けできた人がいるかも知れませんね

# Java と .NET のガベージコレクションに関する調査
# WebSphere は自動的に負荷分散の最適化を行うことで、ハードウェア要件の低減をねらいます
#
# Java 1.5 は 20% 高速化した模様
www.javanews.jp/javap/newsletter043.html


213 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 11:13:18 ]
javaはランタイムが必要な時点で糞なんだから別にいいじゃん

214 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 11:51:15 ]
>>211
おっ、うまいな。

215 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 12:42:33 ]
>>213
JVMも同じディレクトリに置いとけば、別途インストールする必要ない。



216 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 12:50:51 ]
gc のおかげで Java の方が速くなることがあるってんなら、
C++ もテストコードでは gc 使えばいいのにね。
Java と同程度の速度で動くだろうし。

>>203
Java5ってJRE 1.5 のこと(こういう聞き方であってるのかどうかわからないけど)?
だとしたら、漏れの機械ではIBM の VM の方が目に見えて速いですよ。
少なくともEclipseの起動速度は。

217 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 14:14:00 ]
大規模化すると手動でメモリ管理することがどれだけ
大変なのか理解した方が良い。
その分のコストは一体誰が払ってくれるのかと思っているのか。


218 名前:デフォルトの名無しさん [2006/03/31(金) 14:15:35 ]
>>216
最新版SunのJVM乗で動くNetBeansと
IBM JVM乗で動くEclipseとを
比較してみてくれないか。

どちらもSun JVM上で動かした結果ではNetBeansの
ほうが圧倒的に早かった。


219 名前:デフォルトの名無しさん [2006/03/31(金) 14:22:00 ]
c++コンパイラがgcの機能をサポートした実行ファイルを作ればいいんじゃね?

220 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 14:34:03 ]
俺もIBM JVM使ってみたいなー。
IBMのケチ。

221 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 14:47:45 ]
>>219
すでにgcjというやつがある。
ネイティブに変換されるから早いと
思われているが
実際にはかえって遅くなる。
EclipseがJNIを使っている部分があるからといって
早くなるかと思えば逆に遅くなるケースも頻発
してきたことに似ている。
Javaは遅いと思っても実際にネイティブに変換してみたら
かえって遅くなったでは本末転倒。



222 名前:デフォルトの名無しさん [2006/03/31(金) 15:59:37 ]
それじゃなんでJavaはネイティブより速い場合があるんだろう?

223 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 17:57:10 ]
>>222
実行時に実行環境&実行状況にあわせた最適化が行われるから。

224 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 21:09:36 ]
>>218
NetBeans は当分使う予定が無いので、
比較だけのために入れるのはちょっと・・・
Eclipse の方が遅いっていうのなら、たぶんそうなんでしょうね。
漏れもEclipseがあまり高速なIDEとは思ってません。

>>223
実行環境で(PGOとか使える)良いコンパイラを使ったc++なら、
同等の速度が出るということ?

>>222
Java も最終的にはネイティブコードで動いてますよ。魔法じゃないんだから。
特定の幾つかの C++ が出力したネイティブコードよりも、
特定の幾つかの Java VM が出力したネイティブコードが速い、
ということ。

225 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 21:38:39 ]
C++はメモリ管理の部分で下手なコードを書けばJavaより遅くなるけど
それ以外では速度でJavaに負けることは無いよ。自分でテストして
判断したからマチガイナイ。



226 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 22:35:24 ]
ところで、eclipseをJava以外で仕事に使ってる香具師っているの?
本スレでは使ってる人もいるらしいが、Javaの開発用として使っていると書いてるのが多い。
CやC++のIDEとなると結局商用IDEを使うのが懸命でFA?

組み込み開発とかのプラグインもでてるらしいが、実用に耐えられるとは
思えないんだが…


227 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 22:38:48 ]
何が悲しくてc++のコードをeclipseで書かねばならんのだ

228 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 22:39:59 ]
C++で開発する時、Linuxでは何使うもんなの?
エディタじゃなくてIDEを使うとすると。

229 名前:デフォルトの名無しさん mailto:sage [2006/03/31(金) 22:51:15 ]
>>228
お勧めはしないがKylixかな。
問題は多々あるが…。

漏れは、結局概要をIDEで書いちまって、
細かい処理の部分は、Emacs立ち上げてかいてまつ

230 名前:デフォルトの名無しさん mailto:sage [2006/03/32(土) 00:14:07 ]
組み込み用途じゃないかぎり最近はLinux用もJavaで書いてるよ
Windowsで開発してそのまま持っていけるのは便利だよね

J2SE5.0から環境変数が使えるように戻ったのでわりといける

WebアプリとGUIやコンソールのJavaアプリはもうねtBeansのほうが便利だねぇ
JUnitとかNetBeansのほうが親切なつくりだと思うし、プロジェクト単位ではなく
mainからの実行とかはNetBeansのほうが小回りが利く


231 名前:デフォルトの名無しさん [2006/03/32(土) 00:14:20 ]
C++BuilderX

232 名前:デフォルトの名無しさん [2006/03/32(土) 04:01:38 ]
10以上のIDEを使ってきたけど、現状Eclipseが一番。
何と言っても、プラグインでIDEを好きにカスタマイズ出来るのは良い。


233 名前:デフォルトの名無しさん mailto:sage [2006/03/32(土) 04:28:18 ]
VC
VB
VS.net(C#とか)
Delphi
BCC?
Kylix
netbeans
えーと10以上も思いつかない。emacはideに入りますか?

234 名前:デフォルトの名無しさん mailto:sage [2006/03/32(土) 05:55:48 ]
JavaだけでもJBuilder、IDEA、JDeveloper、CodeWarrior、VJで合計7つ思い浮かんだ。

235 名前:デフォルトの名無しさん mailto:sage [2006/03/32(土) 05:57:10 ]
>>232
プラグイン目的なら、最近はNetBeansでもいいじゃん。



236 名前:デフォルトの名無しさん [2006/03/32(土) 06:02:39 ]
IDEなんか言語毎にあるがな
いまやCOBOLにだってあるんだぜ?

237 名前:デフォルトの名無しさん [2006/03/32(土) 09:34:06 ]
JBuilderってフォントがキモイ
読みにくい

238 名前:デフォルトの名無しさん mailto:sage [2006/03/32(土) 09:47:31 ]
>>237
それは、JBuilderのせいなのか?
Swingで使ってるフォントじゃなくて?

239 名前:デフォルトの名無しさん mailto:sage [2006/03/32(土) 10:02:20 ]
カスタマイズできるんだからデフォのフォントなんて意味ない話だな


240 名前:デフォルトの名無しさん mailto:sage [2006/03/32(土) 13:53:36 ]
ミミズだって オケラだって VBだって〜

241 名前:デフォルトの名無しさん [2006/03/32(土) 17:37:25 ]
JBuilderのGUIのフォントが読みにくいんだけど・・・

242 名前:デフォルトの名無しさん [2006/04/02(日) 13:49:54 ]
>>222
ネイティブ側のほうがJavaよりも
メモリ解放効率が悪いアルゴリズムを人間の手で手動で
書いているから。
GCみたいに自動でやればかなり高速化するのだが
複雑大規模化すると人間よりもコンピュータに
メモリ解放させた方が効率が良い。
それがネイティブよりもJavaを早くできる結果となっている。
ネイティブ側も頑張れば絶対的にJavaより早くすることは
いくらでも可能だが、開発コストがかかるのと
すべての場面に置いて確実にJavaより早くするよう
設計することを保証するのが難しくなってきている。

だからJavaって凄い言語なんだと感心するのである。




243 名前:デフォルトの名無しさん mailto:sage [2006/04/02(日) 13:51:03 ]
>>225
それでもC++で高速化するよう上手なコードを書くことは
昨今では難しくなってきているわけだが。
気が付けばJVMやJavaコンパイラはますます進化しているし

244 名前:デフォルトの名無しさん mailto:sage [2006/04/02(日) 13:52:07 ]
>>226
漏れはJavaだけでなくPHP, Perl, Ajax開発にもEclipseを
用いて職場で開発をしている。


245 名前:デフォルトの名無しさん mailto:sage [2006/04/02(日) 13:52:48 ]
>>227
CDT使ってる香具師多いみたいだが。
本スレ見ているとCDTの新バージョンマダー
とかいうレスをいくtかみたし。
話題になってる。



246 名前:デフォルトの名無しさん mailto:sage [2006/04/02(日) 13:54:06 ]
>>233
Java Studio Creatorが抜けている。

247 名前:デフォルトの名無しさん [2006/04/02(日) 18:23:19 ]
Java Studio Creatorって結構よくね?

248 名前:デフォルトの名無しさん mailto:sage [2006/04/02(日) 19:00:50 ]
>>243
いやだからベンチマークしてみろって!なんでそんなSunの
宣伝ばっか鵜呑みにしてんの?馬鹿じゃないの?

249 名前:デフォルトの名無しさん mailto:sage [2006/04/02(日) 21:55:47 ]
SunのVMはうちのベンチだとgccよりかは速いがVCよりかは遅いな。
言語による速度の違いより処理系の違いのほうがでかいレベルまでVMが進化したのは確か。
MSのCLRは試したことないけどSunと同じような主張をしてるみたいね。

250 名前:デフォルトの名無しさん [2006/04/02(日) 22:05:42 ]
>>242
C#使えば?

251 名前:デフォルトの名無しさん [2006/04/02(日) 22:10:12 ]
>>242
それってJavaがすごいというより
GCがすごいってだけじゃね?

.NETでもGCが動けば同じでは?

252 名前:デフォルトの名無しさん mailto:sage [2006/04/02(日) 22:20:32 ]
>>251
漏れがちょいちょいと書いた動画圧縮プログラムなんかは、
.Net の 1.1 (VS 2003でコンパイル) よりも C++ の方が倍近く速かったなぁ・・
C++の方は速度気にしないで stl とか使ってたんだけど。

こういう用途でもJavaも速いのかもしれないけど、あんまり試してみる気が
しないのは、やっぱりJava=遅いっていう先入観にとらわれてるんだろうな。
たいして必要性も感じないし。

253 名前:デフォルトの名無しさん mailto:sage [2006/04/02(日) 22:44:13 ]
実際Javaは遅いよ。

254 名前:デフォルトの名無しさん [2006/04/02(日) 22:45:09 ]
あー
画像処理とか動画処理ではjavaは壊滅的に遅いだろうね

255 名前:デフォルトの名無しさん mailto:sage [2006/04/02(日) 22:48:31 ]
サーバサイドのリクエストの処理は速い。
大量リクエストの並列処理では有利。

ただし、メモリはたくさん用意しておいた方がいい。



256 名前:デフォルトの名無しさん [2006/04/02(日) 23:02:01 ]
コマい仕事を大量に捌くのは早いが、重い単発の仕事はまだCの方が上か。

257 名前:デフォルトの名無しさん [2006/04/02(日) 23:41:44 ]
mallocの本質はフリーチェーンと呼ばれる使用可能メモリブロックの長い連結リストだ。
mallocのパフォーマンスは決して速くなく、しかも、クリーンアップのために
ときどき予期できないタイミングで非常に遅くなる

Javaはガベージコレクションがあるから・・・なんてしたり顔で話すC++プログラマが、
デフォルトのメモリアロケータを平然と使っているなんてことは良くある。

頭のいいプログラマは、mallocによる処理の中断の可能性を最小化するために、
いつも2の累乗のサイズでメモリブロックを割り当てる。
この方法はフリーチェーンの中のヘンな断片化の量を最小化するのだ。
…尤も、Javaの世代別GCに比べれば余りに原始的だがな。


258 名前:デフォルトの名無しさん mailto:sage [2006/04/02(日) 23:56:59 ]
>いつも2の累乗のサイズでメモリブロックを割り当てる。
>この方法はフリーチェーンの中のヘンな断片化の量を最小化するのだ。
アホか

259 名前:デフォルトの名無しさん [2006/04/03(月) 00:08:13 ]
>>257 クリーンアップのためにときどき予期できないタイミングで非常に遅くなる

嘘だろう。C/C++ で heap 領域の clean up を勝手にやるようなメモリ管理なんて聞いたことがない

>>頭のいいプログラマは、mallocによる処理の中断の可能性を最小化するために、いつも2の累乗のサイズでメモリブロックを割り当てる。

C++ の new で heap 領域を割り当てるのに一々メモリサイズなぞ指定しない。

不特定の new/delete を繰り返すことで heap 領域が断片化して、最終的に malloc に失敗することはある。それが実際に発生するのはメモリ不足になるような使い方をしたとき。普通は、そんな心配さえしない。


260 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 00:16:27 ]
あと、GCは集中的に行われる

参照されなくなったときにすぐに行われるのではなく、あとで一気に実行される
こまめにメモリ開放を繰り返すのではなく、開放するときはまとめて行うことにより
スループットが上がっていると考えることはできるかも

Javaの問題はレスポンス

Flipまで時間に余裕があるとき新世代のGCをしておきたいとか
そういうのがあってもどうにもならない
かといって完全に任せるとFlip直前に0.5msのGCがはいって処理オチということは多い

マシンパワーに余裕がある場合5ms以内の指定した時間に起こるGCは問題なくても
いつ起こるかわからないGCは1ms以下でも大問題になるってSunはわかってるんかね

まぁ並列GC使えば影響は大分抑えれるけどもこの問題はなくなるわけじゃない


261 名前:デフォルトの名無しさん [2006/04/03(月) 00:16:48 ]
だからC#使えって。
メモリ管理は工数を大幅に引き上げるため、コストがかかり過ぎる。
仕様変更た機能拡張の度にメモリの管理を見直すのは愚の骨頂。

262 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 00:33:15 ]
GCとかC#のほうがおそいんだけど・・・


263 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 01:11:25 ]
EclipseでC#開発ができるようになれば、このスレとしては解決ということか。

264 名前:デフォルトの名無しさん [2006/04/03(月) 08:39:43 ]
C#よりVB.NETの方がいいじゃん


265 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 10:37:01 ]
VB.NETではここらへんは解決したんかな?
d.hatena.ne.jp/wildcats/20060329



266 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 10:48:34 ]
そいつ嘘ばっかジャン

267 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 11:03:50 ]
>>249
プログラムやアルゴリズムによってJavaが早くなったりしないか

268 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 11:06:40 ]
>>250
プログラムを部分的にネイティブにすることによって
他の環境へ移植するときに修正コストがJavaよりもかからないこっとと、

ネイティブ部分は少ないがWinodows以外の環境に移植するときに
(たとえばMonoのように)速度が大幅に遅くなったりしないことと、


ライブラリやAPI、フレームワークがJava以上に充実して
仕事もJavaよりも増えたらC#への移行を考えるよ。



269 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 11:07:42 ]
>>254
API内部にnative使っているものもあるので以外とおそくなかったりするものもあったりする。

画像処理は、拡大縮小程度ならそんなに遅くなかった記憶がある。

270 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 11:08:08 ]
>>256
そもそもCの仕事が少ない。

271 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 11:09:26 ]
>>260
> あと、GCは集中的に行われる
> Javaの問題はレスポンス
> Flipまで時間に余裕があるとき新世代のGCをしておきたいとか
> そういうのがあってもどうにもならない
> かといって完全に任せるとFlip直前に0.5msのGCがはいって処理オチということは多い

つjava.lang.ref.SoftReference

272 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 11:10:28 ]
>>264
それだったらC#やってるほうがまし。
VB.NETには魅力が感じられない。
よくわからんがVB時代の名残でGUI向け言語って先入観がある。


273 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 13:23:22 ]
速い、遅い、って言っても、用途で変わってくるが、数値計算に限れば
ttp://www.shudo.net/jit/perf/
のSciMark2.0が参考になる。
この言語だから遅い、というよりプログラマがヘボだから遅い、というレベルの差しかない。
ただ、>>260 は同意。
100個のオブジェクトのgc (一括処理)の方が、10個ずつ10回の処理よりも合計として
速いとしても、後者を行いたいときがある。ゲームなどの実時間タイミングの要求がシビアなやつ。
次フレームまでの15msの時間内でgcとか、時間指定gcができるようになるといいんだが。

274 名前:デフォルトの名無しさん mailto:sage [2006/04/03(月) 16:15:53 ]
そもそもJavaで60fpsのゲームなんて無理だろ?
そんなタイミングがシビアなときのGCなんて気にするようなことじゃない。

275 名前:デフォルトの名無しさん [2006/04/03(月) 20:19:44 ]
VB.NET・・・(´_ゝ`)



276 名前:デフォルトの名無しさん mailto:sage [2006/04/04(火) 01:31:32 ]
>>273
一応割合指定とかあるけど1ms以下の挙動はあんまり期待できなかった


>>274
あほか
10年前は無理だったけど4年位前からできるようになったよ
今ハードウェアアクセラレーションばりばりで垂直同期ページフリッピングとか
やってくれるよ

WindowsだともちろんDirectX使ってアクセラレートされる
Swingとか通常のGUIアプリがね
画像をただdrawImageしていてもVRAMへの転送とVRAMtoVRAMの両方が行われる
次からはメモリtoVRAMへの転送が行われない
そしてこれらには優先度が合ってVRAMの容量がなくなると優先度の低いのから追い出されたり
インテリジェントに行われる


277 名前:デフォルトの名無しさん mailto:sage [2006/04/04(火) 06:54:31 ]
javaも値型オブジェクト導入すりゃいいのに

278 名前:デフォルトの名無しさん mailto:sage [2006/04/04(火) 07:12:56 ]
なんで?

279 名前:デフォルトの名無しさん mailto:sage [2006/04/04(火) 07:17:26 ]
javaもunsigned導入すりゃいいのに


280 名前:デフォルトの名無しさん mailto:sage [2006/04/04(火) 09:53:59 ]
>>276
ほんとかよ。
2Dゲームの背景にタイルを敷き詰める処理を作ってみたが明らかに遅いぞ。
これと言って変な処理は入れてないが、5fps出ない。


281 名前:デフォルトの名無しさん mailto:sage [2006/04/04(火) 10:19:38 ]
>>279
そういうクラスを実装すればいい。


282 名前:デフォルトの名無しさん mailto:sage [2006/04/04(火) 10:54:38 ]
>>280
Javaでゲーム作成スレくらいみてからいってくれ

あとそのコードさらせ


283 名前:デフォルトの名無しさん mailto:sage [2006/04/04(火) 22:25:53 ]
>>271
解決になってないぞ

284 名前:デフォルトの名無しさん mailto:sage [2006/04/04(火) 22:43:39 ]
GCのことで文句を言う前にまずReferenceを
うまくつかって解決に挑戦してみろってことだろうや

285 名前:デフォルトの名無しさん mailto:sage [2006/04/04(火) 22:48:12 ]
>>284
ゲームなどの用途でのGCをコントロールする意味わかってるの?
リファレンス使ったところでどうにもならんよ



286 名前:デフォルトの名無しさん mailto:sage [2006/04/04(火) 22:51:33 ]
>>285
まーまー。Reference 覚えたんで言ってみたかっただけだろ。
許してやれ。

287 名前:デフォルトの名無しさん mailto:sage [2006/04/04(火) 22:53:28 ]
そういやVCバリのスレでもjava.lang.ref使えば解決とかうそつき発言なやついたなぁ


288 名前:デフォルトの名無しさん mailto:sage [2006/04/05(水) 11:13:23 ]
確かに長い配列の扱うときにReferenceを使うと
高速化するのは事実だけども


289 名前:デフォルトの名無しさん mailto:sage [2006/04/05(水) 11:42:23 ]
Referenceって世代別GCと相性悪いってのしらないやつまだいるのか

290 名前:デフォルトの名無しさん mailto:sage [2006/04/05(水) 12:07:26 ]
今なら配列ではBuffer

291 名前:デフォルトの名無しさん [2006/04/06(木) 19:59:54 ]
コンパイルできねぇ。
なにこの糞死ね!

292 名前:デフォルトの名無しさん [2006/04/06(木) 20:00:27 ]
糞!糞!糞!
blog.sena.to/archives/2006/01/14/2126.html
ココと同じことやったんだが全くダメ!
糞!糞!糞!

293 名前:デフォルトの名無しさん mailto:sage [2006/04/08(土) 17:30:10 ]
>>290
マ板の 最近のJavaって軽くね? スレで答えてもらえなかったんだが、どう使うんだ?

最近のJavaって軽くね?
pc8.2ch.net/test/read.cgi/prog/1137836570/572-

294 名前:デフォルトの名無しさん mailto:sage [2006/04/08(土) 17:45:18 ]
こちらにまで出張してくるC言語厨の教えて君ご苦労様です。


295 名前:デフォルトの名無しさん mailto:sage [2006/04/08(土) 20:18:06 ]
そんなこと言わないで教えてよ



296 名前:デフォルトの名無しさん mailto:sage [2006/04/08(土) 21:19:34 ]
質問するならスレまちがえてるぞ

297 名前:デフォルトの名無しさん [2006/05/05(金) 01:51:50 ]
イクリプス
じゃなかったっけ???

298 名前:デフォルトの名無しさん mailto:sage [2006/05/05(金) 04:31:17 ]
エクリプスじゃね?
www2.alc.co.jp/ejr/index.php?word_in=eclipse&word_in2=reedeirrf&word_in3=zJPa7DCxJ15687987t

299 名前:デフォルトの名無しさん mailto:sage [2006/05/05(金) 04:35:29 ]
調査の結果

エクリプス の検索結果 約 446,000 件中 1 - 10 件目 (0.03 秒)
イクリプス の検索結果 約 303,000 件中 1 - 10 件目 (0.16 秒)

という結果になり、検索一発目にあたるのが

エクリプス→フリーソフトのEclipse

イクリプス→カーオーディオ

なのでエクリプスのほうが一般的・・・かもしれない。

300 名前:デフォルトの名無しさん [2006/05/05(金) 05:22:26 ]
俺はイクリプスって読んでる。
experienceのノリで。

301 名前:デフォルトの名無しさん mailto:sage [2006/05/05(金) 05:41:01 ]
こんなん出ましたけど

エクリプス java の検索結果 約 27,600 件
イクリプス java の検索結果 約 1,200 件

エクリプス java -イクリプス の検索結果 約 27,500 件
イクリプス java -エクリプス の検索結果 約 187 件

302 名前:デフォルトの名無しさん mailto:sage [2006/05/05(金) 05:51:45 ]
別に発音的に間違ってるわけじゃないんだから
俺はイクリプスのままで通しますね。

303 名前:デフォルトの名無しさん mailto:sage [2006/05/05(金) 05:58:46 ]
一応参考
www.excite.co.jp/dictionary/english_japanese/?search=eclipse
で発音が聞ける。

別に英語の発音にこだわって、
エクリプスって言ってる奴を粛清しようとは思ってないから安心しろ。

304 名前:デフォルトの名無しさん mailto:sage [2006/05/05(金) 06:13:11 ]
>>303
でも、2ちゃんに書き込むときはエクリプスにしてくださいね。
イクリプスだとカーオーディオのが多いようですから。

305 名前:デフォルトの名無しさん mailto:sage [2006/05/05(金) 10:01:37 ]
>>302
記述的には一般的ではないけどな。



306 名前:デフォルトの名無しさん mailto:sage [2006/05/05(金) 12:06:58 ]
>>303
いるな、英語の発音に粘着する奴。
普通の会話でカタカナをネイティブな発音でしゃべると
おかしいことに気づかないくらいアホなんだろな。

307 名前:デフォルトの名無しさん mailto:sage [2006/05/05(金) 12:08:14 ]
イクリプスって言う人のほうが多いな
wikiが立ち上がったときにかなりさわいだな、これ







[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<227KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef