トップページ⇒tech
1001コメント263KB

Ｃ＃って死滅しちゃうの？ Part10

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
死なねーけど、とりあえず立てとくか。前スレ は >>2
0685デフォルトの名無しさんNGNG
以上ﾄﾞﾄﾈﾄ厨の誇大妄想でした。
0686デフォルトの名無しさんNGNG
いやあ、正直.NETが使われるかとか普及するかとか言ってる時期ではないよ。
0687デフォルトの名無しさんNGNG
ﾄﾞﾄﾞﾈﾄ普及しなさそうやな
0688デフォルトの名無しさんNGNG
>>684
Longhorn?
大げさで見た目だけやん
0689デフォルトの名無しさんNGNG
しかしまあ.NETはどんどんJavaに差をつけているね。
やっぱりMSの開発力にはどこもかなわないよ。
0690デフォルトの名無しさんNGNG
死滅と叫んでたやつも2年後にはLonghorn使ってるんだと思うと…。
0691デフォルトの名無しさんNGNG
.NET、C#はLonghornがピークですです。
0692デフォルトの名無しさんNGNG
今月号のﾄﾞﾄﾈﾄﾏｶﾞｼﾞｿの記事によれば、

JavaはUNIX鯖屋以外使う必要なし。
良くて現状維持のJava、これから確実に伸びる.NET。

だそうです。
0693デフォルトの名無しさんNGNG
Javaメモリリークするから多様なプロセスが走るクライアントではまともには動かないよな｡
0694デフォルトの名無しさんNGNG
>>693
しっ。本当の事いっちゃダメ。
0695デフォルトの名無しさんNGNG
Javaはクライアントは死滅、アプレットと携帯はFlashに取って代わられ
鯖以外に生き残りようがないからなー
0696デフォルトの名無しさんNGNG
もうJavaはサーバー専用言語で問題ないでしょ。
無理にクライアントやアプレットにしてもどうせ使えないんだから。
0697デフォルトの名無しさんNGNG
MS様に任せておけばクライアントでまともに動作する
軽量高速なJavaVM作ってくれたのにな｡
ほんとにｱﾌｫな会社もあったものだ｡
0698デフォルトの名無しさんNGNG
dotNETマガジンでJavaの特集組んでたよ。
死滅確定だからお慈悲かけてもらってやんの。ﾌﾟﾌﾟﾌﾟﾌﾟ
0699デフォルトの名無しさんNGNG
Sunは素晴らしいでつ
http://www.zdnet.co.jp/news/0210/17/cead_carroll.html
0700デフォルトの名無しさんNGNG
>>696
>もうJavaはサーバー専用言語で問題ないでしょ。

いいえ。「UNIXの」サーバー専用言語です。
Windowsサーバーにこんな腐った言語要らない。
0701デフォルトの名無しさんNGNG
C#もその儲も必死だな。
0702デフォルトの名無しさんNGNG
何故、みんな判官贔屓なんだろう？
いくら成功者や大金持ちを褒め称えても、
君ら自身が成功するわけじゃーないのに（苦笑
0703デフォルトの名無しさんNGNG
>>692
UnixとUnixから派生したOSとを一緒にするなと何度逝ったら済むのだい
0704デフォルトの名無しさんNGNG
>>692-702
このあたりはJava死滅スレのコピペばっかだな。

このスレはJava死滅の話題はJava死滅スレで語れ
0705デフォルトの名無しさんNGNG
少し前に
Javaのたたきどころが無くなったためM$厨は
仕方が無くオープンソースやLinuxを必死に叩くことにしかできなくなったというレスが
現れてから突然慌ててJavaを叩くレスが頻発したな。

しかしどれも
もうちょっとM$の方針と$unらの方針を理解した方がいいんじゃないか
っていう内容のレスばかりだわな。
0706デフォルトの名無しさんNGNG
>>705
その前にお前が日本語勉強しろ。
0707デフォルトの名無しさんNGNG
>>706
いや、C#語を勉強しろ
0708デフォルトの名無しさんNGNG
つかJavaが最もマトモに動く環境ってWindowsだろ。
0709デフォルトの名無しさんNGNG
>>693-694
> Javaメモリリークするから多様なプロセスが走るクライアントではまともには動かないよな｡
C#のほうがもっとメモリリークする確率は高いぞ。
unsafeを簡単に使える時点でJava以上にメモリリークしやすいわけだが。
つかあんたらメモリリークの意味わかってんのか？
0710694NGNG
あっやっと釣れた。
0711デフォルトの名無しさんNGNG
>>708
基本部分ではね。

アプリケーションの作り方次第では
特定部分にたいする注意を怠らなければ
どこだってまともに動くわけだが。

どんな目的でどんなアプリを作るかでJavaがまともに動く環境も変わるわけだが。
Windowsのセキュリティの問題上、ServletをWindowsで動かす気にはなれんわな。
0712デフォルトの名無しさんNGNG
>>710
反論できなくなるとときの発言ですか (ﾜﾗ
0713デフォルトの名無しさんNGNG
今日も暇人多いね
0714デフォルトの名無しさんNGNG
なぜC#ではthrowsをはずしたのかもっとその議論をしたいな。
煽り釣りには興味ない。
0715デフォルトの名無しさんNGNG
>>700
だからUnixとLinuxを一緒にするなって何度言ったら(略)
0716デフォルトの名無しさんNGNG
>>700
それ以前にWindowsサーバ自体腐ってまつ
セキュリティ脆弱すぎ。金払っても脆弱はもうイヤ
0717デフォルトの名無しさんNGNG
>>711
すがすがしいな。どこでもまともに動くJavaじゃなく
どこでも動くように作ればどこでも動くJavaと訂正したわけだな。
0718デフォルトの名無しさんNGNG
throwsってよく知らないんだけどたとえばメソッドfoo()が
ArgErr, MemErr, IoErrの三つの例外が返す可能性があるとしたら
どう呼び出すの?すべてのfoo()の呼び出しに対して三つのcatchを書かないといけない?
で単にスルーしたい場合は?
0719デフォルトの名無しさんNGNG
いいかげん。Javaはサーバーサイド専用言語と認めろよ。
SwingもSWTもいらねーって。
0720デフォルトの名無しさんNGNG
>>719
これからこれから
JavaWebStartはこれから進化してゆくのさ。
Javaはサーバサイド専用言語から
クライアントサイドとあらゆるOSにも裾野を広げる言語へと
パラダイムシフトしてゆくのさ。
Swingは重要。速度の問題も時間の問題。
SwingではWindowsXPライクなスキンも使える。
Swingで作ったアプリに格好いいのがあったなあ。
0721デフォルトの名無しさんNGNG
>>718
public class ThrowsSample {
　public void foo() throws ArgErr, MenErr, IOErr {
　　//foo()の実装
　}
}

public ArgErr extends Exception {
public ArgErr(String message){
　　super(message);
　}
}

public MemErr extends Exception {
public MemErr(String message){
　　super(message);
　}
}

public IoErr extends Exception {
public IoErr(String message){
　　super(message);
　}
}
0722721 修正版NGNG
>>718
public class ThrowsSample {
　public void foo() throws ArgErr, MenErr, IOErr {
　　//foo()の実装
　}
}

public class ArgErr extends Exception {
　public ArgErr(String message){
　　super(message);
　}
}

public class MemErr extends Exception {
　public MemErr(String message){
　　super(message);
　}
}

public class IoErr extends Exception {
　public IoErr(String message){
　　super(message);
　}
}
0723デフォルトの名無しさんNGNG
>>720
進化しなくていいって。
どうせ今とたいしてかわらないんだから。
Javaに無理させんな。破綻するだけだ。
0724721 続きNGNG
public class ThrowsDemo {
　public test(){
　　ThrowsSample t = new ThrowsSample();

　　try {
　　　t.foo();
　　} catch (ArgErr e){
　　　e.printStackTrace();
　　　throw new RuntimeException(e.toString());
　　} catch (MemErr e){
　　　e.printStackTrace();
　　　throw new RuntimeException(e.toString());
　　} catch (IOErr e){
　　　e.printStackTrace();
　　　throw new RuntimeException(e.toString());
　　} catch (Exception e){
　　　e.printStackTrace();
　　}
　}
}
0725デフォルトの名無しさんNGNG
>>723
Javaを叩くにしてもちょっと詰めが甘いなあ。
0726デフォルトの名無しさんNGNG
>>723
進化するのはクラスライブラリ、API、フレームワークだけで十分。
他に進化して欲しいとしたらオブジェクト指向を超越するものに進化して欲しい。
0727デフォルトの名無しさんNGNG
>>725
叩いてない。真実だ。
0728デフォルトの名無しさんNGNG
>>726
だから、そのクラスライブラリ、API、フレームワークが進化しないんだって。
0729デフォルトの名無しさんNGNG
>>727-728
おまえ釣りばっかしてんなよ。
真面目に議論しろ
0730デフォルトの名無しさんNGNG
このスレ「メモリ・リーク」って言葉を誤用する奴多過ぎ。

アプリが一度確保したメモリーを、reallocかfreeでOSに返さない
ってのは「メモリ・リーク」とは呼ばない。(少なくとも判ってる奴は)

0731デフォルトの名無しさんNGNG
>>730
ユーザーレベルではそう呼ぶに値するだろう｡
Windowsでメモリ使用量＝最大メモリ使用量になるようなソフトは歓迎されないよ｡
0732デフォルトの名無しさんNGNG
>>730
DDoSアタックに使われるプログラムはメモリリークを起こすC,C++プログラム
を使うと聞くけど。

C,C++の配列サイズオーバーでアクセスすることによって
メモリリークが生じると解説するサイトが多いけど。
0733デフォルトの名無しさんNGNG
>>731
それメモリリークじゃねぇよｳﾞｫｹ
0734デフォルトの名無しさんNGNG
>>723
進化するとC#厨には都合が悪いのか (ﾜﾗ
0735デフォルトの名無しさんNGNG
>>733
呼び方はどうでも委員だよ｡どう呼ぼうと糞は糞だからな｡
0736デフォルトの名無しさんNGNG
>>717
いくらJavaがセキュリティに強くたってJavaにデータを受け渡し、リクエストレスポンスする側が
しっかりした機構で無いとどうにもならんよのう。
IISそのものがJavaで作られてるわけじゃないし。
IISがApache並みにしっかりしていればWindowsでもいんだけどね。
(WinにApacheいれればいいけど、それだけじゃものたりません)
0737デフォルトの名無しさんNGNG
>>735
世界中から集まってくる技術者同士ではそんな呼び方しないほうがいいよ
0738デフォルトの名無しさんNGNG
>>737
あほか?ユーザーレベルって書いただろ｡
呼び方よりその挙動がまずいって逝ってるんだよ｡てかJavaスレに帰れ｡
0739デフォルトの名無しさんNGNG
>>738
いやC++スレに帰る
0740デフォルトの名無しさんNGNG
>>731
ページングくらいしろよｱﾌｫ
0741デフォルトの名無しさんNGNG
(´-`).｡ｏO(Java使ってると分かると恥ずかしいのかな？)
0742デフォルトの名無しさんNGNG
>>731 >>738
このスレはユーザレベル限定ではありません。
0743デフォルトの名無しさんNGNG
>>741
C#やVB使ってるほうがよほど恥ずかしい。
0744デフォルトの名無しさんNGNG
>>724
ありがと｡
MemErrのエラーは上位ルーチンに丸投げしたければ
throw eだかしてfoo() MemErrと宣言すればよくって
純粋にバグがあったときだけ出る例外(AssertErr)は
宣言で明示しなければ毎回catchする必要も無い｡ということかな｡

C++の同等の機能ははっきり言って使い物になるとは思えないけど
(VCがサポートをしなかったのもうなずける)Javaのはそれなりに便利そうではあるね｡

その上で思いつくままにデメリットを妄想してみる｡
1.小物ツールでいちいちcatchしまくりたくない(プロジェクト単位でOffにできる?)
2.上位ルーチンへの丸投げの処理が半数以上を占めるとするとうんざりするかも
3.サブコードでswitch/caseする場合は無力(毎回e.errCode()の1,3,4,11に対応しなさい)
4.間にコールバック関数的な処理=ユーザーが後付で登録した処理がある場合は無力
5.で､結局明示できる例外の数はそれほど多くなく費用対効果の点で言語仕様としてthrows()導入するメリットは薄い｡

C#&VSはIDEの機能として自動的に例外の種類をXMLドキュメントに出力して
コーディング時にはカーソルのあるブロックで発生しうる例外をインフォしてくれると嬉しいのかも｡
0745744NGNG
4.は間違いか｡
0746デフォルトの名無しさんNGNG
>>744
RuntimeExceptionとExceptionとの違いわかりまっか〜？
0747744NGNG
>>746
なにそれ?
0748デフォルトの名無しさんNGNG
プログラムをある程度作ったあとから他の複数のメソッドから
頻繁に呼び出されるメソッドにthrowsで例外を追加するとひどい目にあうんですわ。
0749デフォルトの名無しさんNGNG
>>748
そんな間抜けなことする奴いるのか？
0750744NGNG
>>746
>メソッドの実行中にスローされるがキャッチされない RuntimeException のサブクラスについては、
>メソッドの throws 節でそれらを宣言する必要はありません。
RuntimeExceptionは任意にthrowsできて
逆に直接Exception継承するとthrowsを強制されるってこと?

>>748
それ思いついて書き忘れてた｡
6.途中でthrows追加すると全ソースを修正しないといけない（メリットでもありそうだけど）
0751デフォルトの名無しさんNGNG
>>747
RuntimeExceptionは実行時してみないと発生するかどうかわからない例外
RuntimeExceptionのサブクラス抜粋
NullPointerException
マ板で有名なのがこのぬるぽれす。　ぬるぽぬるぽぬるぽ！
ArrayIndexOutOfBoundsException
配列のサイズより大きいインデックスにアクセスしたときに発生。
NegativeArrayException
配列で負のインデックスにアクセスしたとき
ArithmeticException
算術でゼロ除算したとき

Exceptionはプログラミング時に発生するかどうかわかる例外。
Exceptionクラスのサブクラス
FileNotFoundException
ファイルが見つからなかったとき
MalformedURLException
URLの書式が間違ってるとき

これらを継承して例外クラスを自作するのれす。
0752デフォルトの名無しさんNGNG
>>749
例外処理をよく理解していない人たちはそういうことをします。
0753デフォルトの名無しさんNGNG
>>751
完璧にデバッグされたプログラムがあったとしたら
そのプログラムではRuntimeExceptionは絶対に発生しない｡ということ?
0754デフォルトの名無しさんNGNG
throws は例外処理に慣れてない PG に無理やり使わせる（覚えさせる）ための手段。
0755デフォルトの名無しさんNGNG
>>750
> >>746
> >メソッドの実行中にスローされるがキャッチされない RuntimeException のサブクラスについては、
> >メソッドの throws 節でそれらを宣言する必要はありません。
> RuntimeExceptionは任意にthrowsできて
> 逆に直接Exception継承するとthrowsを強制されるってこと?
3行目は説明に誤解があります。
これは、
java.lang.Error, java.lang.RuntimeException のサブクラスの例外は
throws 節なしでも throw できのでthrows節にこれらのサブクラスを追加する必要はありません。

という意味です。
0756デフォルトの名無しさんNGNG
>>753
プログラミングではすべてがRuntimeExceptionだけで
処理できるとは限らず、この世に存在する
例外はRumtimeExeptionクラスのサブクラス例外よりも
Exceptionクラスのサブクラス例外のほうが圧倒的に多く、
投げ出される例外の名前からバグの原因を突き止めやすくするため
throwsの重要性非常に高いと言うことれす。
0757デフォルトの名無しさんNGNG
>>754
そういや1995年頃は何も知らなくてExceptionでつまりまくった記憶がある。
今となっちゃ投げそうなメソッドは大体検討つくし
ドキュメント調べる癖も付いてるからいらないっちゃいらないかもな。

>>293
VJ++6 では普通に共存してたよ
0758デフォルトの名無しさんNGNG
>>757
ドキュメントもいい加減などこかの名も知れないような他人が作ったAPIを会社で使わされたときは
ドキュメントやメソッド見ただけじゃわかりません。
throws必要です。
0759デフォルトの名無しさんNGNG
>>758
そういう意味ではドキュメントとthrows宣言の信用度って同じ程度じゃないの?
0760デフォルトの名無しさんNGNG
>>758
すいません、そのようなおかしな経験を当方持ち合わせておりませんので、理解できません。
0761デフォルトの名無しさんNGNG
>>744の1-3は実際の開発ではどうなの?
0762デフォルトの名無しさんNGNG
>>759
コンパイル時に throws 強制される/されないって部分が問題なんじゃ？
0763デフォルトの名無しさんNGNG
>>751
それだと NoRouteToHostException とかの、
実行してみないと発生するかどうかわからない例外なくせに
Exception だったりする連中を説明できない。
0764名無しさん＠ＥｍａｃｓNGNG
>>757 HotJavaα版 使ってた香具師発見。
0765名無しさん＠ＬｕｃｉｄＥｍａｃｓNGNG
>>763 RuntimeExceptionって言語処理系ランタイムの例外な罠
0766デフォルトの名無しさんNGNG
>>762
ドキュメントが無ければthrowsだってろくに書かれてるとも思えないし
書かれてたとしてもドキュメントが無いなら焼け石に水｡
エラーの検出をプログラムが書く書かないに依存しているという時点で
所詮は補助的なものでしかない｡
0767デフォルトの名無しさんNGNG
IBMはC#やらないのかね｡
developerWorksの読み物結構面白いからC#版も書いて欲しい｡
0768デフォルトの名無しさんNGNG
>>763
しかし
RuntimeExceptionクラスははExceptionクラスのサブクラスなのです。
よってRuntimeExceptionはExceptionの一種であり is_a です。
0769デフォルトの名無しさんNGNG
>>767
IBMは根っからJavaの研究に熱中してるからねえ。
C#版で書こうとJava版で書こうとどちらも言語として似てるから
Javaで説明されてもC#厨にも簡単に理解できるんでない？

クラスライブラリの違いはあるけれどJavaのクラスライブラリはネーミングとかわかり
やすいからどうにかなるんでない？
0770デフォルトの名無しさんNGNG
>>766
危険な香具師やな。
どっちみちthrowsは新しいAPIやフレームワーク作るときに重要。
0771デフォルトの名無しさんNGNG
ドキュメントが嘘だったら大変や。
throwsのほうがドキュメントより信用できるわい
0772デフォルトの名無しさんNGNG
>>766
いや、Exception は throws を強制するので
>ドキュメントが無ければthrowsだってろくに書かれてるとも思えないし
という心配は無用。
0773デフォルトの名無しさんNGNG
>>767
C#の紹介文はかなり好意的に書かれてたね。
0774デフォルトの名無しさんNGNG
>>768
で、結局 >>751 が上手く説明できない、と。
0775デフォルトの名無しさんNGNG
>>773
IBM が C# を嫌うメリットはあんまし考えつかないしなぁ。
0776デフォルトの名無しさんNGNG
IBMも無視できなくなったらやるんでねえの。
0777デフォルトの名無しさんNGNG
Monoの行方しだいでしょ
0778デフォルトの名無しさんNGNG
>>775
Sunのようにあからさま敵を増やすような発言はしないのだよ
技術者を大事にしている企業だから
0779デフォルトの名無しさんNGNG
IBMは、PC、オフコン、汎用機その他、コンピュータのラインナップが
目茶目茶多い企業で、昔から、そういう沢山ある機種の間の互換性の
なさに泣かされてきたのね。だから、全部の機種に互換性のある
ソフトウェアに力を入れる傾向があると思う。
Javaを推している理由はまさにそれだし、Linuxに力を入れているのも
オープンソースだからというより、PCから汎用機まで、全てで動作する
という点が大きいんじゃないかな。

IBMぐらいのサイズの企業だったら、当然C#を使っているところもある
だろうけど、Javaと同じくらいの扱いになるためには、Windowsと
FreeBSDだけっていうんじゃなくて、AIXとかAS/400とか汎用機の上で
もC#がサポートされないと難しいんじゃないかな。
0780デフォルトの名無しさんNGNG
>>776
陰でこっそりやってるとおもわれ

しかしやるならEclipseのC#版を作らねば
0781デフォルトの名無しさんNGNG
>>779
nattoku nattoku Java tatakki ga baka ni miera yo
0782デフォルトの名無しさんNGNG
>>779
score:2 insigｈtful
0783デフォルトの名無しさんNGNG
>C#&VSはIDEの機能として自動的に例外の種類をXMLドキュメントに出力して
>コーディング時にはカーソルのあるブロックで発生しうる例外をインフォしてくれると嬉しいのかも｡

IDEに依存しすぎとはC#もうだめぽ
0784デフォルトの名無しさんNGNG
正確で過不足なく書かれたドキュメントがある場合､
例外に関するthrows()の情報量はドキュメント以下なわけだよね｡
その場合throws()のメリットはヘルプ見れば列挙してある例外郡の
ハンドリングをうっかり忘れるのを防止する｡という一点のみということでFA?
■ このスレッドは過去ログ倉庫に格納されています