C言語を死滅させよう

このエントリーをはてなブックマークに追加
290仕様書無しさん
コンパイル中...
yakyu.c
D:\tomoki\C言語\project1\yakyu.c(93) : error C2018: 文字 '0x81' は認識できません。
D:\tomoki\C言語\project1\yakyu.c(93) : error C2018: 文字 '0x40' は認識できません。
D:\tomoki\C言語\project1\yakyu.c(93) : error C2018: 文字 '0x81' は認識できません。
D:\tomoki\C言語\project1\yakyu.c(93) : error C2018: 文字 '0x40' は認識できません。
D:\tomoki\C言語\project1\yakyu.c(93) : error C2018: 文字 '0x81' は認識できません。
D:\tomoki\C言語\project1\yakyu.c(93) : error C2018: 文字 '0x40' は認識できません。
D:\tomoki\C言語\project1\yakyu.c(93) : error C2018: 文字 '0x81' は認識できません。
D:\tomoki\C言語\project1\yakyu.c(93) : error C2018: 文字 '0x40' は認識できません。
D:\tomoki\C言語\project1\yakyu.c(107) : fatal error C1004: 予期せぬ EOF が検出されました。
cl.exe の実行エラー

yakyu.exe - エラー 9、警告 0

何度も確認しましたが間違いはないはずなのこうなってしまいます。どうすればいいですか?
291仕様書無しさん:03/02/02 23:10
>>286
そのころには「Java を死滅させよう」「C# を死滅させよう」スレが立つんだろう。
きっと。
292仕様書無しさん:03/02/02 23:13
>>290
Cなんか使ってるからだよ。
293仕様書無しさん:03/02/02 23:15
>>292
いや 0x8140 といえば、お決まりの…
294仕様書無しさん:03/02/02 23:16
>>290 ははは、マジレス禁止でお願いします
295290:03/02/02 23:21
続きはこちらでお願いします(w
http://pc2.2ch.net/test/read.cgi/tech/1042640474/547-
296仕様書無しさん:03/02/02 23:31
*
297仕様書無しさん:03/02/03 01:57
>>296
肛門
298仕様書無しさん:03/02/03 22:36
>>291 すでにム板にたっている
「死滅しちゃうの??」シリーズ
299仕様書無しさん:03/02/03 23:02
インプレスより好評発売中!
300仕様書無しさん:03/02/04 09:36
イソプレスだろ
301仕様書無しさん:03/02/04 22:56
SQLを死滅させて欲しい。なんでデータ取り出す命令が文字列なんだよ。
302仕様書無しさん:03/02/04 23:01
>>301
いみふめ。
303仕様書無しさん:03/02/04 23:50
バイナリ形式にコンパイル済みの問い合わせをしたいんだろ。
JavaでJDBCのPreparedStatement使え。
コンパイル済みだから、速いぞ。
304仕様書無しさん:03/02/05 00:50
create view ...
305仕様書無しさん:03/02/05 10:18
>>303 JDBCをつかうならJ2EEのEJBがチョベリグ〜♪
306仕様書無しさん:03/02/05 10:19
>>303 ストアドプロシージャもつかうともっとグ〜♪
307仕様書無しさん:03/02/05 10:20
>>301 それは不可能です。
なんでHTML、XMLが文字列なんだよ、といっているのと同じように
308仕様書無しさん:03/02/06 00:48
>>307
何でテキストなの?
309仕様書無しさん:03/02/06 22:42
これからは日本語でコーディングする時代だろ?
310仕様書無しさん:03/02/06 23:03
ひまわり栽培係の方ですか?
311仕様書無しさん:03/02/06 23:12
>>309 日本語はあまりに冗長すぎて大変だ。
漢字使えばそれだけ情報量が増える。
英語のように少ない種類の部品でより多くのことを表現できる方がいい。
有機化学にたとえれば、酸素、炭素、水素だけで非常に多くの性質が異なる物質を作ることができる。これらの物質のバリエーションはたった3個の元素だけで数億にも及ぶ。
日本語はひらがなだけでもアルファベットより余計な情報が多い。
312仕様書無しさん:03/02/07 17:27
>>311
そんなものはコンパイラの性能だろ。
ソースの情報量が増えても、これだけ大容量メディアがあるんだから

詭弁第6条
一見関係ありそうで関係ない話を始める
    「ところで、カモノハシが卵を産むのは知っているか?」
に該当する。
313仕様書無しさん:03/02/07 17:28
>>312
打つのが大変
314仕様書無しさん:03/02/07 17:47
perlを使いましょう。
315仕様書無しさん:03/02/07 18:01
/* C言語 >>1 漏れ */
316仕様書無しさん:03/02/07 18:55
>>311-313
オマエラ話が噛み合わなさ過ぎ
会話にすらなってねーじゃねーかよ
アフォか?
317仕様書無しさん:03/02/07 20:13
>>312
ソースを構成する情報が増えることによって困るのはコンパイラではなく人間なのだが
318仕様書無しさん:03/02/07 20:31
いや、もちろん、自然言語としての日本語を解釈してプログラムを生成して
くれるというなら、そりゃあ便利だけども。
そういう話じゃないよな?
319仕様書無しさん:03/02/07 23:22
>>312 え? おれのレス詭弁に見えた?

コンパイラの性能云々の問題じゃないぞ。
メディアとかじゃないよ。
というか、英語より日本語の方が省略できるから逆に容量節約になるぞ。
そのかわり解読しにくくなる。

例えば、C++とJavaとC#で可能な限りソースコードをスパゲティ化したとしよう。

さて、どれが最もスパゲティコードを作りやすいか、
どれが最も巨大なスパゲティコードになるか。

これの答えは恐らく
C++ > C# > Java
だろう。

理由としてはC++はポインタ演算、参照型記号、構造体、メモリ操作、
実装の多重継承、プリプロセッサ、グローバル変数、グローバル関数、
関数ポインタ、テンプレート、演算子のオーバーローディング、C言語の旧ライブラリ使用可、
などの使用を許している分、スパゲティ化しやすい。

C#はunsafeでポインタ演算などができる。構造体も使え、演算子のオーバーローディングも使用できる。
Javaではこれらの使用を禁止している。テンプレートはJDK1.5から限定的に使用可能。

Javaはすっきりしている反面C/C++/C#とくらべソースが大容量化しやすい。
320仕様書無しさん:03/02/08 00:08
>>319
その比較対象にBASICとFORTRANとCOBOLとCも入れてくれ。
321仕様書無しさん:03/02/08 01:07
>>319
平均的な実行速度考えた?
322仕様書無しさん:03/02/08 01:57
>>319
お前はJavaで
try中のtry中のtryに対するfinally中のthrowを捕まえるcatchの中からのthrow
を見たことがないからそんな事が言えるんだ。

スパゲティ職人の手にかかればどんな言語もスパゲティ。
323仕様書無しさん:03/02/08 02:06
>>322
おまえのは日本語さえもスパゲッティだな。
324322:03/02/08 02:17
>>323
当然わざとやってるわけだが。
・・・冗談で突っ込んでたんならゴメン。
325仕様書無しさん:03/02/08 03:28
>>320 COBOLそんなによくしらぬので除外。

C++ > C > C#(usafe使用) > BASIC > C#(unsafe不使用) > Java

ここにCOBOLを入れたとしても少なくともJava, C#よりスパゲティ化しにくいとはいえないだろう。

>>321 速度は 大体
C++ > C# > Java

double型演算や、IBM製JavaVMを使った場合でのFFT以外のほとんどの数値計算速度では
C++ > Java > C#
となるらしい。

>>322 そんなことやるJavaPGは元コボラーJavaPGくらいです。
try三つネストは痛い。
tryにreturn入れる奴より痛い。
例外クラスを自作しないでExceptionだけしか書かない香具師も痛い。
326仕様書無しさん:03/02/08 07:26
この業界にC言語ができないやつがいるの?
327仕様書無しさん:03/02/08 07:52
>>326
いくらでもいるでそ。
328仕様書無しさん:03/02/08 09:22
たぶん業界の範囲がすごく狭いのでしょう。井の中の蛙。
329仕様書無しさん:03/02/08 09:29
「Cが使える」と自称する奴の中で本当に使える奴が何割海豚も疑問。
330仕様書無しさん:03/02/08 10:44
>>325
tryにreturnを入れるのがどう痛いのか解説してくれ!
331仕様書無しさん:03/02/08 10:46
>この業界にC言語ができないやつがいるの?

Cを経験してないやつならゴロゴロいるな(w
332仕様書無しさん:03/02/08 10:48
>tryにreturnを入れるのがどう痛いのか解説してくれ!

例外をマクロで実装していた時代の記憶で語っているものと思われ。
333仕様書無しさん:03/02/08 18:16
>>326 ブビ厨
334仕様書無しさん:03/02/08 18:18
>>330 めっちゃくちゃ痛いじゃないか。
catch文が無視されるんだぞ。
こりゃイタイイタイ病

しかもfinallyがあると先にfinallyを実行してからreturnを実行するんだぜ。
アイタタタ....
335_:03/02/08 23:56
ネイティブな言語は残るだろう…
C、Del(Pascal)とか…
336仕様書無しさん:03/02/09 00:13
cppも残るぜい!まだまだ現役だあ!やっほーい!
337仕様書無しさん:03/02/09 01:09
ぬるぽは残ります
338仕様書無しさん:03/02/09 02:29
>>334
それの何が問題なのか説明してもらいたいんだが…。
339仕様書無しさん:03/02/09 03:27
>>338 「Javaの鉄則」という本を読めばわかるよ。
そんなに分厚い本でもないので、立ち読みだけで
理解できると思う。

オブジェクト指向を極めるにはこれくらいは気をつけておかないと
痛い目を見ると言うことさ。
340仕様書無しさん:03/02/09 10:14
Cははやいのさ。
341仕様書無しさん:03/02/09 10:21
>>339
オブジェクト指向とは関係ないところだと思うが。
342仕様書無しさん:03/02/09 12:34
制御系、組み込み系 以外でC言語使用している
ソフト開発って現在あるの?
343仕様書無しさん:03/02/09 13:08
>>341 例外処理はな。
例外がクラスになっているのだよ。
Exceptionクラスを継承して独自の例外クラスを作るのだよ。
直接はオブジェクト指向とは関係なくとも

オブジェクト指向を極めるには例外の使いかたを間違えると
いつまで経っても洗練された堅牢なプログラミングができないのだよ。
344仕様書無しさん:03/02/09 13:10
で、例外がどのようにして物体指向と関係しているのかと
345仕様書無しさん:03/02/09 13:20
>>344
物体指向ってなんですか
346仕様書無しさん:03/02/09 13:20
>>343
オブジェクト指向でない言語では例外処理を適当に書いても問題無いと。
347仕様書無しさん:03/02/09 13:32
>>343
try
{
スレに書き込み();
}
catch
{
あぼーん();
}


class 通報スマスタ : Exception
{
}

これでいいのか?
348仕様書無しさん:03/02/09 15:17
>>347 通報スマスタクラスがつかわれてねーぞ
349仕様書無しさん:03/02/09 22:19
>>347
訳わからん。
もっとわかりやすい記述できるように頑張りな。
350仕様書無しさん:03/02/10 00:19
>>344
オブジェクト指向やUMLで言われている
オブジェクトとは物体ではなく

森 羅 万 象 を意味するものだぞ。

だからJavaやC#ではすべてのクラスの
スーパークラスはObjectクラスなのだ。

UMLPressにプラトンの哲学にたとえてクラスがイデアという表現があったな。
351仕様書無しさん:03/02/10 01:51
スレタイが気に食わん。
352仕様書無しさん:03/02/10 07:01
C言語を引退させよう
353仕様書無しさん:03/02/10 11:17
>>352 無理。無謀
354仕様書無しさん:03/02/10 11:47
>>352
COBOLが先だろ
355仕様書無しさん:03/02/10 11:57
FORTRANモナー
356仕様書無しさん:03/02/10 12:28
>>355 まだ無理。
MATLABやMathmaticaですらFortranに完全完勝はしていない。
357仕様書無しさん:03/02/10 21:23
>>351 ム板には死滅シリーズや"馬鹿になる"シリーズのスレタイがいくつかある。

C#, Java, C, Delphi, VBなどなど。

研修でC言語やらされる会社は多いんだな。
358仕様書無しさん:03/02/10 21:33
K&Rスタイルが気に食わん
359仕様書無しさん:03/02/11 00:13
>>358
だから何?
360仕様書無しさん:03/02/11 00:18
おいしいものを食べて元気を出そうと思った
361仕様書無しさん:03/02/12 00:06
>>349
もっといいのに書き直してよ

無理か?
362仕様書無しさん:03/02/12 00:39
>>301

XML を処理するAPIが言語を超えて統一されているのと同じで
SQLも プログラムでSQL文字列生成->文字列を解析してクエリを生成
なんてことやらず、データ取り出しオブジェクトを生成->オブジェクト情報からクエリを生成
なんてのがあってもいいんじゃねーか。ってことでございます。
363仕様書無しさん:03/02/12 00:45
364仕様書無しさん:03/02/12 00:49
むう。PCめ、勝手に書きこむな。改めて、
>>361

JAVAを勉強してて、思ったことだけど、
例外をthrowするのは結局、同クラス内なのよね。
作るアプリにもよると思うけど、

たとえばファイル処理例外で致命的なものは
統一したクラスに例外をthrowしたいと思うんだけど、
そういうことを書いた参考書が無い・・・
JAVAにはできないってこと?
365仕様書無しさん:03/02/12 00:53
>>364

RuntimeException は catch せずともコンパイルは通してくれるけども。
366仕様書無しさん:03/02/12 00:56
>>365
返答ありがとうです。

ファイル処理例外は、例としてあげただけで、
要するに、アプリ側で、例外処理専用クラスを作って、
それに共通する例外処理の大部分を処理させたいってことです。
367仕様書無しさん:03/02/12 01:01
>>366

ならそのアプリ専用のその処理を行うクラス(例えばファイル処理)とかを定義してやりゃどうか。
368仕様書無しさん:03/02/12 01:09
>>367

try {
処理;
}
catch (例外) {
if (例外==共通処理できる例外)
throw 例外;
}

と書いても呼び出し元にしかthrowできないじゃないすか?
throw 例外;
と書くのではなく、委譲した例外処理クラスを呼び出すってことすか?
だったらそれを、言語としてサポートして欲しかったってことっす。

throw (例外, 例外処理クラス)

見たいな文法を見とめて欲しかった、ていうか。
欲張りですね。すんません。
369仕様書無しさん:03/02/12 01:21
欲張りっていうか全てのエラー処理を一箇所にまとめて書くというニーズがないんじゃないの。
なんとなくN88BASICのon error goto/resume nextの悪夢を思い出したよ。
370仕様書無しさん:03/02/12 04:08
>>368 Vectorを使え,
catch節で例外オブジェクトをVectorに溜め込め
371370:03/02/12 04:09
>>370 "Javaの鉄則"に載っている技
372仕様書無しさん:03/02/12 04:27
>>368
そんなあなたにAspectJ。
373仕様書無しさん:03/02/12 04:31
メソッドシグネチャにthrows節を書くことをサボるのは、
他人の迷惑なのでやめましょう。
374仕様書無しさん:03/02/12 04:37
>>373 ということはC#は非常に迷惑な言語ってことやな。
throwsを消して最悪。もう迷惑、あの言語死滅。M$は失敗した。
375仕様書無しさん:03/02/12 04:37
ここって Java のスレなんですか?
376仕様書無しさん:03/02/12 07:33
>>370
わざわざ古い実装を勧める必要はないだろ。
今ならVectorじゃなくてArrayListを勧めれ。
過去の資産との互換性が気になるひとは、メソッドの引数をVectorからListに替えるとかすればいい。
そうすりゃどっちも通るようになる。

>>375
違う。奇跡的にJavaの質問にマジレスがついてるだけ。
このスレの趣旨はあくまで、Cを使わない方向でいくこと、らしい。
377仕様書無しさん:03/02/12 07:50
>>375

1.仕事が減ってるJava厨の白昼夢スレです。
2.Cができないリアル厨もいます。
3.知ったかぶりブビ厨もいます。
4.プッってこのスレを見てるまともな人は思ってます。
5.C・C++もJAVAも自称厨の中で本当に使えるヤシは1割くらいです。


378仕様書無しさん:03/02/12 07:59
こうやって生真面目に答えてくれる人が居るんだから 2ch も悪くないと思う。
379仕様書無しさん:03/02/12 08:01
●ロボットを受け入れる日本人の精神構造

日本人は、昔から愛用品や非常に大切にしているものに対して、その中に塊が
宿り始めると信じる傾向がある。それは、以前であれば縫い子さんが大切に使
った針から現代においては工場で愛用される大小の機械まで例外ではない。一
年に一度この折れた針を集めては供養と称し、豆腐などに刺してその労をねぎ
らったり、工場の機械にニックネームを漬けては特殊な感情の表現をするので
ある。
 また、スポーツにおいては、例えば野球では”一球入魂”などといって自分
の投げる球に魂を入れ、自分と魂を一体であるかのように考えているフシもあ
る。そればかりか、各種の道具や機械を作ることからスポーツに至るまで、本
来るまで、本来は単なる作成手法であったり、ルールに則って行うゲームに過
ぎなかったりするもののはずが、刀鍛冶が刀を作る際の神事に近い儀式のよう
になったり、たかがお茶を一杯飲むだけなのに茶道になってしまったり、ベー
スボールのはずが野球道になってしまったりなどしている。
 日本人は、いつのまにか、物、行為、ルールなどあらゆることにおいて、−
それを使い続けたり、または、極めようとしたときに、−本来の目的とは異な
った精神主義の世界を作り上げてしまう。全てのことに魂が宿っていると信じ、
そのこと1つ1つを成就するために、修行僧のごとく振舞うのである
380仕様書無しさん:03/02/12 08:03
●ロボットを受け入れる日本人の精神構造

日本人は、昔から愛用品や非常に大切にしているものに対して、その中に塊が
宿り始めると信じる傾向がある。それは、以前であれば縫い子さんが大切に使
った針から現代においては工場で愛用される大小の機械まで例外ではない。一
年に一度この折れた針を集めては供養と称し、豆腐などに刺してその労をねぎ
らったり、工場の機械にニックネームを漬けては特殊な感情の表現をするので
ある。
 また、スポーツにおいては、例えば野球では”一球入魂”などといって自分
の投げる球に魂を入れ、自分と魂を一体であるかのように考えているフシもあ
る。そればかりか、各種の道具や機械を作ることからスポーツに至るまで、本
来るまで、本来は単なる作成手法であったり、ルールに則って行うゲームに過
ぎなかったりするもののはずが、刀鍛冶が刀を作る際の神事に近い儀式のよう
になったり、たかがお茶を一杯飲むだけなのに茶道になってしまったり、ベー
スボールのはずが野球道になってしまったりなどしている。
 日本人は、いつのまにか、物、行為、ルールなどあらゆることにおいて、−
それを使い続けたり、または、極めようとしたときに、−本来の目的とは異な
った精神主義の世界を作り上げてしまう。全てのことに魂が宿っていると信じ、
そのこと1つ1つを成就するために、修行僧のごとく振舞うのである。
 このようなこのような状況になると、そのことが併合理的であっても無意味
であっても、成就しようと必死に努力を重ねている姿を見て、日本人は、この
上ない賛嘆の念に駆られ、自己陶酔に陥ることになる。つまり、物を大切にす
るのは、メインテナンスをよくして、それを長く使ったほうが経済的であると
いう理由からではない。それよりも、その物を使っていくうちに愛着が沸き、
あたかも自分の分身がそこに宿るかのような考えに支配されるため、それを大
切にすることで、その物の塊に触れるような心地よさを感じてしまうことによ
る。
 このような文化を持つ日本人にとって、昔から、あらゆるものいに魂を入れ
るという発想は自然である。これは、いわば日本人の精神構造そのものである。

結論として今の日本には アントニオ 猪木 の張り手が必要という事だ。
381仕様書無しさん:03/02/12 12:31
>>377
Javaの仕事そんなに減ってるかねぇ?
382仕様書無しさん:03/02/12 12:34
>>381
.NETの様子見でちょっと立ち止まってるだけじゃない?本格的な現象傾向は
始まってないと思う。
383仕様書無しさん:03/02/12 12:41
>>377
JavaよりもC/C++のほうが仕事が減りつつあるなあ。
C#は出たばかりだから少し増えているみたいだけど
欠陥だらけ特許問題を抱えているんではまだまだ普及しないだろうねえ。
C#や.NETの仕事がある企業は中小企業くらいだからねえ。
大手企業はJavaの仕事がおおいね。
といってもJavaの基本(J2SE)程度知ったくらいじゃ確かに仕事は少ないね。
J2EEかServlet, JDBCなども知らないと仕事は増えないわけですな。

ついでにOracle, ネットワークの知識、Unixの知識も知らないといかんですなあ。
これくらい知っていればJavaの仕事もたっぷりあるでしょな。
384仕様書無しさん:03/02/12 20:17
>>362 ストアドプロシージャ
385仕様書無しさん:03/02/12 21:45
言語の王者はVB、殆どの企業基幹システムはVBで
組まれているようです。
付属のシステムがC++、JAVA
どう、違う?
386仕様書無しさん:03/02/12 21:58
>>385 はいつまらない釣りね。
VB厨を慰めるだけだね。
387仕様書無しさん:03/02/12 22:03
>>385
禿同!!VBは神!!
きっと、みずほの悲劇はVBによって引き起こされたんだね。
スペースシャトルのウワサの温度センサーも、VBのランタイムエラーかもよ!
次期WindowsのAPIはVBで記述されるらしいね。すごいね、VB!!

スレの名前変えようか?【最高に頭の悪い………】
388仕様書無しさん:03/02/12 22:05
>>387
最高に頭の悪いVB
389仕様書無しさん:03/02/12 22:07
金融機関の基幹システムはVB。
バージョンUPしてもVB。
殆どのPGがVBだがね!
390仕様書無しさん:03/02/12 22:10
>>389
流石素晴らしい逆説ですね。
391仕様書無しさん:03/02/12 22:11
ガンダム搭載のAIもVB
392仕様書無しさん:03/02/12 22:13
>>391 30過ぎですか?
393仕様書無しさん:03/02/12 22:13
コストを考えればVBってこと?
394仕様書無しさん:03/02/12 22:13
>>393 単なる逆説
395仕様書無しさん:03/02/12 22:46
そこまでVBほめたたえなくても・・・
厨くるよ?
396仕様書無しさん:03/02/12 22:49
>そこまでVBほめたたえなくても・・・
よく読んでね。

っつか、おまいそれでもPGか?>>393も同罪。
397395:03/02/12 22:55
>>396
おれの書きこみ自体も皮肉です。
いやーしかし・・・
VBってそこまでひどい言語かね。
おれは使い込んでないからわからん。
398仕様書無しさん:03/02/12 23:30
>>397
C/C++/Java/C#と比較してみいよ。
型がいい加減じゃないか。
もう最低だ。
399368:03/02/12 23:33
いやぁ、書いてみるもんですね。
遅レスですいませんが、丁寧な回答どうもです。

今のチームではJava使わないので、勉学意欲失ってたとこだったので
なおさらありがたいです。
とりあえず「Javaの鉄則」絶対買います。昔買った本を読み返して
勘を取り返します。
あと、同僚に貸したままの「Java謎」本をなんと返してもらいます(w
400仕様書無しさん:03/02/12 23:40
むぅ、あげ損ねた。

あと誤字訂正。
>あと、同僚に貸したままの「Java謎」本をなんと返してもらいます(w
あと、同僚に貸したままの「Java謎」本をなんとか返してもらいます(w
401仕様書無しさん:03/02/12 23:57
>>399
http://www.gimlay.org/~javafaq/
このサイト見たことある?
402仕様書無しさん:03/02/13 00:12
>>401
どうもです。

ただ、言語に関する根本的な疑問は、Faqサイトよりもム板よりも、
マ板のほうが向いてるような、そんな気がしただけっす。
403仕様書無しさん:03/02/13 02:59
VB をけなす香具師がよく 「型がいい加減」 とか書いてるのだが、どういう
事なんだ?
VB で型の扱いに困ったことなんか無いぞ。
404仕様書無しさん:03/02/13 06:05
たしかに、VBよりC++のほうがすぐるているだろう。
でも、企業で使う基幹システムはVBになっちゃんだよね。
本当はC++で組んだほうがいいのだがPGの能力がないため
安全なVBに走ってしまう。
405t:03/02/13 06:47
406仕様書無しさん:03/02/13 07:42
>>403
VBを貶す理由としてはもっともアホで理不尽で筋違いなもの
の一つだと思うがな。
他に貶すところはいくらでもあるだろうに...(w

>>404
突っ込みどころが満載過ぎる。
とりあえず
> すぐるている
> 企業で使う基幹システム
> なっちゃんだよね
> 安全なVB
を指摘しておこう
407仕様書無しさん:03/02/13 10:01
>>403
C/C++/Java/C#との比較すればどれくらいいい加減かはわかる。
巨大なプログラムを作ってみればそのいい加減さにうんざりすることだろう。

VB.NETからは型もしっかりしてきたみたいだが。
最近、VBとVB.NETを一緒にする馬鹿が多くて困る。

>>406
突っ込むところは
> 安全なVB
だけでいいだろう。
他を突っ込むのは不毛な幼稚な揚げ足取り。

馬鹿でも使えるVBに走ってしまう。の方が妥当。
408仕様書無しさん:03/02/13 10:54
>>407
> C/C++/Java/C#との比較すればどれくらいいい加減かはわかる。
ふっ。「わかる」って言うだけで説明できんのか。
409仕様書無しさん:03/02/13 11:01
>>408 他のスレやム板で散々語られていることを
いちいち説明する必要もないと思ってな。

いまどき解らない香具師はブビ厨くらいだな。

文字列型に勝手に数値型を代入できても全くコンパイラが
何も文句を言わないことの恐ろしさがお前にはわかるか?
410仕様書無しさん:03/02/13 11:08
演算子のオーバーロードと同じようなものだろ。
411仕様書無しさん:03/02/13 11:16
う〜ん。静的な型付けを行わない言語なんてのはいくらでもあって、例えば
ほとんどのスクリプト言語はそうである訳だが。で、それは一般のプログラマには
別に必ずしも悪い点とは考えられていない。これらの言語は宣言や型付けを
行わないことによる手軽さを選んでいる訳だ。言語設計には常にトレードオフがあり、
またプログラマが使用する道具を選択する上でもトレードオフが存在する。
こんなのはプログラマにとっては当たり前の話で、その辺を理解しないヤシは
単細胞と取られても仕方が有るまい。
そういう中で、VBのダメな所として(他に幾らでも問題があるのに)真っ先に
型付けの問題を上げるようでは、そいつの程度も知れてるってことよ。
412仕様書無しさん:03/02/13 13:07
>>411
お前甘すぎ。お前のほうがよほど程度が知れているってことだ。
巨大なプログラム作ったことがないからそういうことがいえるんだよ。

お前は単純なプログラム作ることを前提に議論しているだけだろ。
それともお前は型に甘い言語だけでミッションクリティカルに簡単に対応できるとでも思っていたのか?
そんな型に甘い糞言語を宇宙船の動力に搭載できるか。危なすぎて信用できない。

継承もできない、型に甘い手軽な言語で巨大なプログラムを作ってみろ。
バグも見つけにくい。潜在的な顧客の苦情にもバグに素早く対応できない。
拡張も素早くできない。

それともお前は継承もできないVBしか使っていないのか?
413仕様書無しさん:03/02/13 14:04
>>412
トレードオフという言葉が君には難しすぎたかな?
では、もう少し簡単な、適材適所という日本語の意味をよ〜く
噛みしめてから出直してきなさい。


414仕様書無しさん:03/02/13 14:24
>>413
君の説明が曖昧なのだよ。
君は>>412が型付けの問題だけを指摘しているとでも思い込んでいるのかね。

>で、それは一般のプログラマには
>別に必ずしも悪い点とは考えられていない。
君の言う "一般のプログラマ" がそうだと決め付けることも、君の主観ということだね。

>言語設計には常にトレードオフがあり、
君は何がトレードオフかという説明をしていないようだが。
言語設計の何がトレードオフかという説明をしていない君は論点が曖昧だ。

"言語選択の適材適所" から "VBの駄目なところで型の問題をあげる"ことに
話の筋をつなげている君の論法どういうこっちゃ


415仕様書無しさん:03/02/13 14:28
つまり>>403はVBで大規模なプログラミング経験をしたことがないということでよろしいか?
416仕様書無しさん:03/02/13 14:33
C言語と関係ない話やないか。
継承ができないクラスしか定義できないWin以外でろくに動かんVBはC言語より早く死滅するんだからどうでもええっつーの
417仕様書無しさん:03/02/13 15:44
>>414
>君の説明が曖昧なのだよ。
むー。そうかも。

>君は>>412が型付けの問題だけを指摘しているとでも思い込んでいるのかね。
少なくとも412以前で問題になっていたのは型付けの問題だったと
思うのだが。ちがう?
勝手に話を広げないで欲しいね。

>君は何がトレードオフかという説明をしていないようだが。
411の、>これらの言語は宣言や型付けを行わないことによる手軽さを選んでいる
→がここではトレードオフのつもり。要は静的な(強い)型付けを行うかどうかには
簡便さ・安全性・といった言語設計上の選択が有りトレードオフが有るということ。
どうも412には、「大規模で複雑な開発に適した言語(こそ)が、優れている」といった
類の極めて単純な、一次元的指向が有るように見えたのでね。

>"言語選択の適材適所" から "VBの駄目なところで型の問題をあげる"ことに
>話の筋をつなげている君の論法
う〜ん。そういう順序で「話の筋をつなげ」た記憶はないんだが。。。
要は
・VBが強い型付けを行わないのは言語設計上の選択で、そもそも
VBという言語自体が、>>412に書かれているような大規模なプログラミング
に向いたものではなく、むしろお手軽かつ迅速なプロトタイピングのような
用途に最も適しており、そのように設計されている。
・言語特性を適切に把握して適材適所で用いるのはプログラマの責任であって、
そもそもVB向きでない対象にそれを適用して「つかえね〜」なんて云ってるのは
そりゃ選んだ奴が悪い。
・そもそも型付けを行うかどうかの問題は別にVBに限ったことじゃなく、
「強い型付けを行わない」ことはVBという言語環境をもっとも的確に表した
ものでもないから、VBを貶すのにそういう話が出てくるのはちょっと違うんでない、
といったところだね。
418仕様書無しさん:03/02/13 16:09
>>416
例えば、継承は出来るけど型付けはなくて、継承といってもundef出来たり
instance_evalが出来ちゃったりしちゃうような某言語はいかがでしょうか。
419525:03/02/13 16:30
■■出会い系サイト運営システムレンタル■■

儲かる出会い系ビジネス

初心者でも簡単運営

写メール、画像対応

http://kgy999.net/open/






420仕様書無しさん:03/02/13 16:42
必死だな
421仕様書無しさん:03/02/13 18:43
>>1
COBOLERかVB厨?
422仕様書無しさん:03/02/13 21:22
C言語もそれだけではクラス作れないからC++からみても
糞にしか見えないが、
プログラムの仕組みの勉強にはうってつけかもな。
423仕様書無しさん:03/02/13 21:53
C++ってclassという予約語があるだけでぜんぜんOOPLじゃないんだよな。
もうJavaもC#も(かつてはC++の唯一の売りであった)genericなコンテナライブラリがサポートされるから
これから死滅に向かっているのは間違いないよ。
424仕様書無しさん:03/02/13 21:55
>>423 速度面ではJavaもC#もC++には全然負けている。
VMやOS作りに向いているためJavaやC#が現れたくらいでは死滅は
ありえないだろう。
425仕様書無しさん:03/02/13 22:02
templateを侮る事勿れ。
426仕様書無しさん:03/02/13 22:03
Cの得意な低レベルな部分にはそれほど食い込めてないし
アプリ開発ではもはやMFCなんてお呼びじゃないしで
上下から押しつぶされてジリ貧だよ。
Cよりも狭い一部の用途で細々と使われていくんだろうね。
427仕様書無しさん:03/02/13 22:05
何の事言ってるのかさっぱりダ。
428仕様書無しさん:03/02/13 22:10
>>425 JavaにもJ2SE1.5から限定的なC++templateであるGenerics機能が追加される。
C#は代替の方法を使用しているらしい。

>>426 C++の話、それともC#の話?
429仕様書無しさん:03/02/13 22:15
>>426
C++=MFCですか?へーそりゃ凄いや。
430仕様書無しさん:03/02/13 22:17
>>429
>>426の脳内ではC++=VC++でしかないんだろう。
MFCこそ優れたライブラリだと思い込んでいる。
431仕様書無しさん:03/02/13 22:44
MFCに限らずC++のGUIライブラリは全面的に糞だろ。
432仕様書無しさん:03/02/13 23:11
>>431 で、VBがお勧めなのですか?
433仕様書無しさん:03/02/14 00:39
>>432
フレームワークは使いこなすのが難しいということですよ。
434仕様書無しさん:03/02/14 01:09
>>433
しかし、C++のGUIライブラリが糞なら
>>431一体なにが一番いいと思っているのでしょう?
435仕様書無しさん:03/02/14 01:11
Delphiに決まってるだろ。
C#は成熟するのにあと1・2年はかかるだろう。
436仕様書無しさん:03/02/14 01:59
>>435
VBがアップデートされるたびに泣いた者もいるくらいだ。
C#は成熟どころか、M$の独断と偏見で再構築され現在のC#プログラマが
既にコーディングしたC#コードの修正でC#プログラマを泣かせるだろう。
437仕様書無しさん:03/02/14 02:18
変化が怖けりゃEmacsでCのコードをちまちま書いていればいいさ
438仕様書無しさん:03/02/14 02:36
C も変化しまくってる罠
439仕様書無しさん:03/02/14 20:25
ある日突然、参照渡しが値渡しになる恐怖を、キミは体験した事があるか!?
440仕様書無しさん:03/02/15 00:27
>>437
Javaをつかっちまえばいいのさ。
もちろんC/C++は死滅しない。

Sunは「進化が途絶える」というでJavaを標準化機構に提出しなかったんだから。
もっとも、JDK1.3以前からJavaプログラムを作り始めた人は、JDK1.4になってから
少し痛い目にあっている人もいるようだがね。
C#のように極端に便利すぎて返って将来性を損ねるような計画性の殆どない機能追加は
Javaには殆ど付けられていないから今からJavaコード、自作クラ
スライブラリ、API、フレームワークを沢山作っても
バージョンアップで死ぬほど困ることは殆ど無いのさ。

いつかJavaが新言語によって確実に死滅しても
その言語がJavaよりも高水準な言語であればJavaコードの
移植も楽になるものだろう。

C#はJavaより水準が高い(オブジェクト指向度が高い)とは言えないので
Javaを死滅させるにはいたらないだろう。シェアを少し縮めることができるかもしれないが。
441仕様書無しさん:03/02/15 00:35
>今からJavaコード、自作クラスライブラリ、API、フレームワークを沢山作っても
要するに単位行あたりの機能性生産性が低いといいたいのか?
442仕様書無しさん:03/02/15 00:57
>>441
単位行あたり、短いプログラムを書きたい、使い捨てプログラムを書きたい
という生産性用途ではJavaはVB,perl,C++,C#などに劣るでしょう。

巨大なプログラム作り、長く使うプログラム、ネットワーク重視にはJavaの方がVB,C,C++,C#より向いているでしょう。

443仕様書無しさん:03/02/15 01:08
>巨大なプログラム作り、長く使うプログラム、ネットワーク重視にはJavaの方がVB,C,C++,C#より向いているでしょう。
匿名掲示板で根拠を示さず主観や偏見に基づく意見を主張するってきっと気持ちのいいことなんでしょうね。
444仕様書無しさん:03/02/15 01:12
>>443
匿名掲示板で、たとえ主観であれ偏見であれ、自分の意見すら言わずに
単に皮肉で煽るってのはさらに気持ちのいいことなんでしょうね。
445仕様書無しさん:03/02/15 01:15
>>443
改行してくれよ。
446仕様書無しさん:03/02/15 01:20
PERFORM
447仕様書無しさん:03/02/15 01:22
Linux上でJavaを使ってタブ型メモ帳作ってます。
かっくいいです。
448仕様書無しさん:03/02/15 02:39
>>444 おお、その通りですじゃ。
>>443は相当Javaに抵抗があるお方のようですじゃ。
じゃが、使って見れはその実体が解りますのじゃ。
449仕様書無しさん:03/02/15 08:06
やっぱりCが好き。
C/C++/MFC/VBX/Java2/C#極めたくらいで世界見た気になってんじゃネーヨ

上記プラスawk/sed/perl/php/ruby/pythonあたりはザラにつかえて、
CenturaとかForteなどのどう考えても普及していないものすら手中に収め
COBOL/assemblerはそういうPGと話すときの素養の一つ程度に理解
(assemblerのニーモニックは石2つ分覚えてりゃいんでないかい)

OS/390からNetBSDからOS/2からケータイ用プラットフォームまで幅広く見識があり臨機応変にPGに挑む

みたいなヤシじゃないと言語を死滅させるストーリーが描けるワケもない
451仕様書無しさん:03/02/15 08:52
社内ツールのような場合C#は最強だと思ってるんだが・・・・。
ランタイムの必要としないC#アプリケーションが作れれば、もっと普及すると
思うんだが無理なんかな。
452仕様書無しさん:03/02/15 08:58
テンプレートでガチガチに固めたオブジェクト指向構成ってのは
デジドカ大量導入する開発では効果は高いけど、結局デジドカ的な
プログラマーしか育たないからキライ。

オブジェクト指向・工数勘定うんぬんかんぬんで実行速度の意味を考えないシロート
が「設計」「設計」とのたまう開発はウザイ。

そんな訳で・・・・・・・・・・・・・「やっぱC言語最高!」←99岡村 風
エコロジー言語 C

brk()される機会が最も少なく、最適化オプションで高速化 これはOSにやさしい♪

OOPだってどうせシーケンス図書かなきゃいけないんだし、
だったらCでいーじゃん♪
454仕様書無しさん:03/02/15 09:17
>>452
>テンプレートでガチガチに固めたオブジェクト指向構成
→テンプレートとオブジェクト指向は特に関係がない直交する概念ですが
何を云いたいのでしょうか?
>デジドカ大量導入する開発では効果は高い
→兵隊さんを大量導入するような開発現場が効率よく回せるというのが本当なら
それは大変素晴らしいことではないでしょうか。「育たない」と困るプロパー
以外の使い捨てプログラマにたいしては、非常に有効な手法だという訳ですね。
>シロートが「設計」「設計」とのたまう開発はウザイ
→それは言語とは特に関係がないものですね。まあ、「シロート」に設計を
まかせるような会社に問題があるのですから、転職でも考えてみては?

455仕様書無しさん:03/02/15 10:45
この業界には本当に、
主張を完全に論破されるような無能馬鹿が多いのだろうかと
考えずにいられない。

マ板を見ていると。
456440:03/02/15 12:36
>>450
アセンブラーで石二つ? Z80と何かか?
まあ、アセンブラくらいなら大抵の情報系の大学卒業している香具師は経験しているぞ。
情報科学をろく知らない香具師が死滅ストーリーを語るんじゃないといいたのはわかる。

しかしなあWeb系ではperlは死滅の方向に向かっているように見えるぞ。
perlはshとと共にUnix系でスクリプトいじるのに生き残りそうだが。
レンタルサーバで流行っているPHPも単位容量あたりのメモリの価格がHDDと同じくらい安くなればJ2EEやJavaServlet/JSPにとって変わられる日もやってくるかもな。

C/C++/Java/C#がpython風な記述になった言語が登場すれば面白そうだが。
457仕様書無しさん:03/02/15 12:36
>>451 Javaと同じ目に遭います。
458仕様書無しさん:03/02/15 15:18
>>456
> 情報科学をろく知らない香具師が死滅ストーリーを語るんじゃない
死滅ネタが情報科学と関係があるとは思えんが。。。
少なくとも「科学」じゃあないだろ。
>>450が云いたいのは、単純に知識経験が豊富なヤシの方が単なる煽り厨
より面白可笑しくネタを語れるでしょ、ということだと理解している。
それはそれで正しいんだが、

1)そういうことはあまりにも当たり前であって、
2)しかもそんなことを云う奴よりは実際に面白可笑しくネタを語れる奴
の方が圧倒的に正しいのだが
3)実際まともな識見を持っている奴は死滅ネタなんざ相手にしないので

云うだけ野暮ではある。
459仕様書無しさん:03/02/15 18:57
>>457
納得
460仕様書無しさん:03/02/15 19:09
>>455
禿同。
461仕様書無しさん:03/02/15 19:30
そのうち死滅するからほっとけよ。
462仕様書無しさん:03/02/15 20:04
VB房ですが
C++じゃ出来ないことって何?
463仕様書無しさん:03/02/15 20:11
何と比べてるの?VB?
464仕様書無しさん:03/02/15 20:16
VBとC++です。
465仕様書無しさん:03/02/15 20:17
生産性の高い開発
466仕様書無しさん:03/02/15 20:19
C++では簡単ラクチン・プログラミング♪が出来ない。
467仕様書無しさん:03/02/15 20:28
>>462
短期で高機能、かつ、安いソフトを作ること。
468仕様書無しさん:03/02/15 20:30
>>462
短期で低機能、かつ、安いプログラマを作ること。
469仕様書無しさん:03/02/15 20:38
>>462
>>467>>468に共通すること。
すなわち、安いプログラマを作ることが出来ないために安いソフトを
作ることが出来ない。そして仕事を取ることが出来ない。
470仕様書無しさん:03/02/15 20:43
そりゃ、安い仕事しかできない奴に高い仕事がくるわけ無いわな。
471仕様書無しさん:03/02/15 20:48
>>470
どこに安い仕事と書いてあるのかな?
安いと書いてあるのはソフトとプログラマだけですよ。
472仕様書無しさん:03/02/15 20:50
え?
50万/月しか稼げないプログラムを作ったプログラマに
100万/月払ってるの?
473仕様書無しさん:03/02/15 20:57
>>471
会社役員ウマーの法則ですね(意味不明)。
474仕様書無しさん:03/02/15 21:01
同じ仕事を50万で作れるプログラマと100万で作れるプログラマがいたとしたら
50万で作れるプログラマのほうに仕事が行くのが当たり前だろう。
475仕様書無しさん:03/02/15 21:03
どこに同じ仕事と書いてあるのかな?
476仕様書無しさん:03/02/15 21:07
おまいら うるせぇんだ。

C は 神

以上
477仕様書無しさん:03/02/15 21:07
>>475
書いてませんよ。もとから直接的なレスじゃありませんから。
478仕様書無しさん:03/02/15 21:39
>>476
その通りです。
C言語は永遠に不滅です。

C 言 語 は

ノ イマ ン 型 コ ン ピ ュ ー タ が 死 滅 す る ま で

情 報 科 学 、 情 報 工 学 、

コ ン ピ ュ ー タ サ イ エ ン ス 、

コ ン ピ ュ ー タ エ ン ジ ニ ア リ ン グ の 世 界 で

永 遠 に 語 り 継 が れ て い く こ と で し ょ う 。
479仕様書無しさん:03/02/15 22:26
まあ、思い出にはなるだろうね。
480 :03/02/16 20:56
所詮ノイマン型だしCでも十分 という考えかたもあるわな
481仕様書無しさん:03/02/16 21:56
新事実
C は量子コンピュータで大活躍
482仕様書無しさん:03/02/17 10:30
>>481
ソースきぼんぬ
483仕様書無しさん:03/02/17 11:47
なんか、昔のアセンブラ今 C、って感じだな。最近の扱い見てると。
484仕様書無しさん:03/02/17 11:59
>>483
まぁ、「高級アセンブラ言語」なんて別名もあるくらいだし。
485仕様書無しさん:03/02/17 16:23
>>483-484
それがCの正しい位置付けだと思うんだが、CORBAマッピングまで
あることからして、どうもそうは思っていない人もいるらしく…
486仕様書無しさん:03/02/20 10:55
ヴィビ厨にはC言語を死滅させるスキルがありません。
487仕様書無しさん:03/02/20 13:52
>>466
一度苦労しておけば出来ないこともないが、出来るようになるまでが大変だな。
488仕様書無しさん:03/02/20 14:00
>>1 は神に対する挑戦だな。
489仕様書無しさん:03/02/20 15:15
>>487
C、アセンブラを極め。VC++をこなし、さらにオブジェクト指向C++も習得し、
Java、VBプログラミング技術を手に入れたオレ。
そして現在C#で開発していてふと思うこと・・・・・今までの苦労はなんだったんだ(藁
490仕様書無しさん:03/02/20 15:21
>>489
それは、ちゃんと苦労してプログラミングの勉強してないからだろう。
491仕様書無しさん:03/02/20 15:27
>>489
漏れも似たようなもの(嘘)だが、それでもC++は好きだ。
やっぱり、やろうと思えば何でも出来るところがいい。

ちなみに、単なるCは死滅してもいいや。
492U ◆CZtFsGiu0c :03/02/20 15:30
>>485
「CORBAマッピングまで」って、最初のCORBA仕様ではSmalltalkとCの
マッピングしかなかったわけだが。
493452:03/02/20 16:30
■■わりきり学園■■

コギャルから熟女まで

素敵な出会い

ゲイ、レズビアンなどコンテンツ豊富

http://www.geocities.jp/kgy919/deai.html







494仕様書無しさん:03/02/20 16:46
C++にできてCにできないことはないんだけど…。
激しく生産性が悪いがナ。
495仕様書無しさん:03/02/20 16:48
>>494
それはVBにできてアセンブラに出来ないことは無いって
言ってるようなもので、正しいが激しく無意味。
496仕様書無しさん:03/02/20 16:49
>>494
だから、C++なんだよ。
C++は工夫次第でどこまでも生産性を高めることが出来る!


‥‥‥まあ、そこまで持ってくまでが大変なんだがな。
497仕様書無しさん:03/02/20 17:19
>>496
うちはもう
VBやdelよりも、C++のほうが生産性が高いよ。
これまでさんざん苦労したけど。

レスポンスもかなり早くなったけど
OSや開発環境のバージョンアップにも楽になったし。
保守作業がかなり楽になった。

サーバー側も予算がない所だと
C++だけで軽くて安くできるし。

JAVAも良いと思うが、C++も仕事の仕方でかなり良いと思うけど?
498仕様書無しさん:03/02/20 18:03
>>497
すげぇ!自社専用フレームワークとかできあがっちゃってるわけ?!
499仕様書無しさん:03/02/20 18:44
>>497
>>498

俺の会社もそう。
激安のサーバサイドは
Linux+Apache+フリーDBの自社カスタマイズ+自社アドインモジュール
ミドルウェア代をかなりケチった設定。
結構安定してるし、保守も楽、レスポンスも速いよ。
500仕様書無しさん:03/02/20 18:54
>>497>>499
いいね。
それぐらい出来れば、C++を使っている甲斐があるというもの。
501仕様書無しさん:03/02/22 23:23
まっWin32上では実質的に、.NET上では完全に死滅してるんだけどね。
502仕様書無しさん:03/03/03 23:50
おまえらCが死滅寸前に追い込まれたときどうするよ?

ちゃんと対策とってるかよ
死滅対策をよ
死滅後の行動とってるかよ
503仕様書無しさん:03/03/03 23:58
おまえら502が死滅寸前に追い込まれたときどうするよ?

ちゃんと対策とってるかよ
死滅対策をよ
死滅後の行動とってるかよ




別に放っておいてもいいか
504仕様書無しさん:03/03/04 22:55
将来Cが死滅寸前に追い込まれるとして、
そのころUNIXやWindowsは何かで書き直されているんだろうか。
505仕様書無しさん:03/03/04 23:10
Microsoft Pascal++
506 ◆e3475Kmk6c :03/04/13 23:42
   |
   | ∧
   |ω゚) ダレモイナイ ィョゥスルナラ イマノウチ
   |⊂
   |


     ♪
   ♪   ∧ ∧   イョゥ ョゥ
      ヽ(゚ω゚=)ノ   イョゥ ョゥ
         (  へ)    イョゥ イョゥ
          く       ョゥ


   ♪
     ♪ ∧ ∧   イョゥ ョゥ
      ヽ(=゚ω゚)ノ   イョゥ ョゥ
         (へ  )    イョゥ イョゥ
             >     ョゥ
507山崎渉:03/04/17 12:41
(^^)
508山崎渉:03/04/20 05:57
   ∧_∧
  (  ^^ )< ぬるぽ(^^)
509仕様書無しさん:03/04/22 23:48
double dNum = 0.0;

double dNum(0.0);
と書こう


ということでつか?
510仕様書無しさん:03/04/23 04:27
Cが死滅するこたぁないだろ。
超高速化ルーチンの作成にはC++よりCの方がはるかに適しているんだから。
「今日の性能には高速化ルーチンなんか必要ない」とか言ってるヤシは
現実を知らないんだよ。
511仕様書無しさん:03/04/23 05:18
10年以上先の話だと思うけど...

COBOL と C どっちが先に逝くのだろうか?
COBOL はかなりしぶとい気がする。
C なんざ、よりすぐれた後継言語が出ればすぐ死滅すると思うが...
512仕様書無しさん:03/04/24 21:38
コボラーもCジジイも早く逝ってほしい
513仕様書無しさん:03/05/14 00:41
>>511
COBOLはJ2EEによって死滅させられる。
.NEtはCOBOLをぶっ殺す力はないだろう。
C言語はJava2Enterpriseが死滅しない限り死滅しない。

なぜならJVMはCでできているから
514仕様書無しさん:03/05/16 16:42
携帯ゲーム機"プレイステーションポータブル(PSP)

 このPSPは、新規格UMD(ユニバーサルメディアディスク)というディスクを利用しており、そのサイズは直径6cmととても小さい(CDの半分程度)。 容量は1.8GBとなっている。
画面は4.5インチのTFT液晶で、480px x 272px(16:9)。MPEG4の再生やポリゴンも表示可能。外部端子として、USB2.0とメモリースティックコネクタが用意されているという。

この際、スク・エニもGBAからPSPに乗り換えたらどうでしょう。スク・エニの場合、PSPの方が実力を出しやすいような気がするんですが。
任天堂が携帯ゲーム機で圧倒的なシェアをもってるなら、スク・エニがそれを崩してみるのもおもしろいですし。かつて、PS人気の引き金となったFF7のように。
515山崎渉
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―