290 :
仕様書無しさん :
03/02/02 23:10 コンパイル中... 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 何度も確認しましたが間違いはないはずなのこうなってしまいます。どうすればいいですか?
>>286 そのころには「Java を死滅させよう」「C# を死滅させよう」スレが立つんだろう。
きっと。
>>292 いや 0x8140 といえば、お決まりの…
294 :
仕様書無しさん :03/02/02 23:16
*
>>291 すでにム板にたっている
「死滅しちゃうの??」シリーズ
インプレスより好評発売中!
イソプレスだろ
301 :
仕様書無しさん :03/02/04 22:56
SQLを死滅させて欲しい。なんでデータ取り出す命令が文字列なんだよ。
303 :
仕様書無しさん :03/02/04 23:50
バイナリ形式にコンパイル済みの問い合わせをしたいんだろ。 JavaでJDBCのPreparedStatement使え。 コンパイル済みだから、速いぞ。
create view ...
>>303 JDBCをつかうならJ2EEのEJBがチョベリグ〜♪
>>303 ストアドプロシージャもつかうともっとグ〜♪
>>301 それは不可能です。
なんでHTML、XMLが文字列なんだよ、といっているのと同じように
309 :
仕様書無しさん :03/02/06 22:42
これからは日本語でコーディングする時代だろ?
ひまわり栽培係の方ですか?
>>309 日本語はあまりに冗長すぎて大変だ。
漢字使えばそれだけ情報量が増える。
英語のように少ない種類の部品でより多くのことを表現できる方がいい。
有機化学にたとえれば、酸素、炭素、水素だけで非常に多くの性質が異なる物質を作ることができる。これらの物質のバリエーションはたった3個の元素だけで数億にも及ぶ。
日本語はひらがなだけでもアルファベットより余計な情報が多い。
312 :
仕様書無しさん :03/02/07 17:27
>>311 そんなものはコンパイラの性能だろ。
ソースの情報量が増えても、これだけ大容量メディアがあるんだから
詭弁第6条
一見関係ありそうで関係ない話を始める
「ところで、カモノハシが卵を産むのは知っているか?」
に該当する。
313 :
仕様書無しさん :03/02/07 17:28
perlを使いましょう。
315 :
仕様書無しさん :03/02/07 18:01
>>311-313 オマエラ話が噛み合わなさ過ぎ
会話にすらなってねーじゃねーかよ
アフォか?
>>312 ソースを構成する情報が増えることによって困るのはコンパイラではなく人間なのだが
いや、もちろん、自然言語としての日本語を解釈してプログラムを生成して くれるというなら、そりゃあ便利だけども。 そういう話じゃないよな?
>>312 え? おれのレス詭弁に見えた?
コンパイラの性能云々の問題じゃないぞ。
メディアとかじゃないよ。
というか、英語より日本語の方が省略できるから逆に容量節約になるぞ。
そのかわり解読しにくくなる。
例えば、C++とJavaとC#で可能な限りソースコードをスパゲティ化したとしよう。
さて、どれが最もスパゲティコードを作りやすいか、
どれが最も巨大なスパゲティコードになるか。
これの答えは恐らく
C++ > C# > Java
だろう。
理由としてはC++はポインタ演算、参照型記号、構造体、メモリ操作、
実装の多重継承、プリプロセッサ、グローバル変数、グローバル関数、
関数ポインタ、テンプレート、演算子のオーバーローディング、C言語の旧ライブラリ使用可、
などの使用を許している分、スパゲティ化しやすい。
C#はunsafeでポインタ演算などができる。構造体も使え、演算子のオーバーローディングも使用できる。
Javaではこれらの使用を禁止している。テンプレートはJDK1.5から限定的に使用可能。
Javaはすっきりしている反面C/C++/C#とくらべソースが大容量化しやすい。
>>319 その比較対象にBASICとFORTRANとCOBOLとCも入れてくれ。
321 :
仕様書無しさん :03/02/08 01:07
>>319 お前はJavaで
try中のtry中のtryに対するfinally中のthrowを捕まえるcatchの中からのthrow
を見たことがないからそんな事が言えるんだ。
スパゲティ職人の手にかかればどんな言語もスパゲティ。
>>322 おまえのは日本語さえもスパゲッティだな。
>>323 当然わざとやってるわけだが。
・・・冗談で突っ込んでたんならゴメン。
>>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言語ができないやつがいるの?
たぶん業界の範囲がすごく狭いのでしょう。井の中の蛙。
「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を入れるのがどう痛いのか解説してくれ! 例外をマクロで実装していた時代の記憶で語っているものと思われ。
>>330 めっちゃくちゃ痛いじゃないか。
catch文が無視されるんだぞ。
こりゃイタイイタイ病
しかもfinallyがあると先にfinallyを実行してからreturnを実行するんだぜ。
アイタタタ....
ネイティブな言語は残るだろう… C、Del(Pascal)とか…
cppも残るぜい!まだまだ現役だあ!やっほーい!
ぬるぽは残ります
>>334 それの何が問題なのか説明してもらいたいんだが…。
>>338 「Javaの鉄則」という本を読めばわかるよ。
そんなに分厚い本でもないので、立ち読みだけで
理解できると思う。
オブジェクト指向を極めるにはこれくらいは気をつけておかないと
痛い目を見ると言うことさ。
340 :
仕様書無しさん :03/02/09 10:14
Cははやいのさ。
>>339 オブジェクト指向とは関係ないところだと思うが。
342 :
仕様書無しさん :03/02/09 12:34
制御系、組み込み系 以外でC言語使用している ソフト開発って現在あるの?
>>341 例外処理はな。
例外がクラスになっているのだよ。
Exceptionクラスを継承して独自の例外クラスを作るのだよ。
直接はオブジェクト指向とは関係なくとも
オブジェクト指向を極めるには例外の使いかたを間違えると
いつまで経っても洗練された堅牢なプログラミングができないのだよ。
で、例外がどのようにして物体指向と関係しているのかと
>>343 オブジェクト指向でない言語では例外処理を適当に書いても問題無いと。
347 :
仕様書無しさん :03/02/09 13:32
>>343 try
{
スレに書き込み();
}
catch
{
あぼーん();
}
class 通報スマスタ : Exception
{
}
これでいいのか?
>>347 訳わからん。
もっとわかりやすい記述できるように頑張りな。
>>344 オブジェクト指向やUMLで言われている
オブジェクトとは物体ではなく
森 羅 万 象 を意味するものだぞ。
だからJavaやC#ではすべてのクラスの
スーパークラスはObjectクラスなのだ。
UMLPressにプラトンの哲学にたとえてクラスがイデアという表現があったな。
スレタイが気に食わん。
C言語を引退させよう
FORTRANモナー
>>355 まだ無理。
MATLABやMathmaticaですらFortranに完全完勝はしていない。
>>351 ム板には死滅シリーズや"馬鹿になる"シリーズのスレタイがいくつかある。
C#, Java, C, Delphi, VBなどなど。
研修でC言語やらされる会社は多いんだな。
K&Rスタイルが気に食わん
おいしいものを食べて元気を出そうと思った
361 :
仕様書無しさん :03/02/12 00:06
362 :
仕様書無しさん :03/02/12 00:39
>>301 XML を処理するAPIが言語を超えて統一されているのと同じで
SQLも プログラムでSQL文字列生成->文字列を解析してクエリを生成
なんてことやらず、データ取り出しオブジェクトを生成->オブジェクト情報からクエリを生成
なんてのがあってもいいんじゃねーか。ってことでございます。
364 :
仕様書無しさん :03/02/12 00:49
むう。PCめ、勝手に書きこむな。改めて、
>>361 JAVAを勉強してて、思ったことだけど、
例外をthrowするのは結局、同クラス内なのよね。
作るアプリにもよると思うけど、
たとえばファイル処理例外で致命的なものは
統一したクラスに例外をthrowしたいと思うんだけど、
そういうことを書いた参考書が無い・・・
JAVAにはできないってこと?
>>364 RuntimeException は catch せずともコンパイルは通してくれるけども。
366 :
仕様書無しさん :03/02/12 00:56
>>365 返答ありがとうです。
ファイル処理例外は、例としてあげただけで、
要するに、アプリ側で、例外処理専用クラスを作って、
それに共通する例外処理の大部分を処理させたいってことです。
>>366 ならそのアプリ専用のその処理を行うクラス(例えばファイル処理)とかを定義してやりゃどうか。
>>367 try {
処理;
}
catch (例外) {
if (例外==共通処理できる例外)
throw 例外;
}
と書いても呼び出し元にしかthrowできないじゃないすか?
throw 例外;
と書くのではなく、委譲した例外処理クラスを呼び出すってことすか?
だったらそれを、言語としてサポートして欲しかったってことっす。
throw (例外, 例外処理クラス)
見たいな文法を見とめて欲しかった、ていうか。
欲張りですね。すんません。
欲張りっていうか全てのエラー処理を一箇所にまとめて書くというニーズがないんじゃないの。 なんとなくN88BASICのon error goto/resume nextの悪夢を思い出したよ。
370 :
仕様書無しさん :03/02/12 04:08
>>368 Vectorを使え,
catch節で例外オブジェクトをVectorに溜め込め
372 :
仕様書無しさん :03/02/12 04:27
373 :
仕様書無しさん :03/02/12 04:31
メソッドシグネチャにthrows節を書くことをサボるのは、 他人の迷惑なのでやめましょう。
>>373 ということはC#は非常に迷惑な言語ってことやな。
throwsを消して最悪。もう迷惑、あの言語死滅。M$は失敗した。
ここって Java のスレなんですか?
376 :
仕様書無しさん :03/02/12 07:33
>>370 わざわざ古い実装を勧める必要はないだろ。
今ならVectorじゃなくてArrayListを勧めれ。
過去の資産との互換性が気になるひとは、メソッドの引数をVectorからListに替えるとかすればいい。
そうすりゃどっちも通るようになる。
>>375 違う。奇跡的にJavaの質問にマジレスがついてるだけ。
このスレの趣旨はあくまで、Cを使わない方向でいくこと、らしい。
>>375 1.仕事が減ってるJava厨の白昼夢スレです。
2.Cができないリアル厨もいます。
3.知ったかぶりブビ厨もいます。
4.プッってこのスレを見てるまともな人は思ってます。
5.C・C++もJAVAも自称厨の中で本当に使えるヤシは1割くらいです。
こうやって生真面目に答えてくれる人が居るんだから 2ch も悪くないと思う。
379 :
仕様書無しさん :03/02/12 08:01
●ロボットを受け入れる日本人の精神構造 日本人は、昔から愛用品や非常に大切にしているものに対して、その中に塊が 宿り始めると信じる傾向がある。それは、以前であれば縫い子さんが大切に使 った針から現代においては工場で愛用される大小の機械まで例外ではない。一 年に一度この折れた針を集めては供養と称し、豆腐などに刺してその労をねぎ らったり、工場の機械にニックネームを漬けては特殊な感情の表現をするので ある。 また、スポーツにおいては、例えば野球では”一球入魂”などといって自分 の投げる球に魂を入れ、自分と魂を一体であるかのように考えているフシもあ る。そればかりか、各種の道具や機械を作ることからスポーツに至るまで、本 来るまで、本来は単なる作成手法であったり、ルールに則って行うゲームに過 ぎなかったりするもののはずが、刀鍛冶が刀を作る際の神事に近い儀式のよう になったり、たかがお茶を一杯飲むだけなのに茶道になってしまったり、ベー スボールのはずが野球道になってしまったりなどしている。 日本人は、いつのまにか、物、行為、ルールなどあらゆることにおいて、− それを使い続けたり、または、極めようとしたときに、−本来の目的とは異な った精神主義の世界を作り上げてしまう。全てのことに魂が宿っていると信じ、 そのこと1つ1つを成就するために、修行僧のごとく振舞うのである
380 :
仕様書無しさん :03/02/12 08:03
●ロボットを受け入れる日本人の精神構造 日本人は、昔から愛用品や非常に大切にしているものに対して、その中に塊が 宿り始めると信じる傾向がある。それは、以前であれば縫い子さんが大切に使 った針から現代においては工場で愛用される大小の機械まで例外ではない。一 年に一度この折れた針を集めては供養と称し、豆腐などに刺してその労をねぎ らったり、工場の機械にニックネームを漬けては特殊な感情の表現をするので ある。 また、スポーツにおいては、例えば野球では”一球入魂”などといって自分 の投げる球に魂を入れ、自分と魂を一体であるかのように考えているフシもあ る。そればかりか、各種の道具や機械を作ることからスポーツに至るまで、本 来るまで、本来は単なる作成手法であったり、ルールに則って行うゲームに過 ぎなかったりするもののはずが、刀鍛冶が刀を作る際の神事に近い儀式のよう になったり、たかがお茶を一杯飲むだけなのに茶道になってしまったり、ベー スボールのはずが野球道になってしまったりなどしている。 日本人は、いつのまにか、物、行為、ルールなどあらゆることにおいて、− それを使い続けたり、または、極めようとしたときに、−本来の目的とは異な った精神主義の世界を作り上げてしまう。全てのことに魂が宿っていると信じ、 そのこと1つ1つを成就するために、修行僧のごとく振舞うのである。 このようなこのような状況になると、そのことが併合理的であっても無意味 であっても、成就しようと必死に努力を重ねている姿を見て、日本人は、この 上ない賛嘆の念に駆られ、自己陶酔に陥ることになる。つまり、物を大切にす るのは、メインテナンスをよくして、それを長く使ったほうが経済的であると いう理由からではない。それよりも、その物を使っていくうちに愛着が沸き、 あたかも自分の分身がそこに宿るかのような考えに支配されるため、それを大 切にすることで、その物の塊に触れるような心地よさを感じてしまうことによ る。 このような文化を持つ日本人にとって、昔から、あらゆるものいに魂を入れ るという発想は自然である。これは、いわば日本人の精神構造そのものである。 結論として今の日本には アントニオ 猪木 の張り手が必要という事だ。
>>377 Javaの仕事そんなに減ってるかねぇ?
>>381 .NETの様子見でちょっと立ち止まってるだけじゃない?本格的な現象傾向は
始まってないと思う。
>>377 JavaよりもC/C++のほうが仕事が減りつつあるなあ。
C#は出たばかりだから少し増えているみたいだけど
欠陥だらけ特許問題を抱えているんではまだまだ普及しないだろうねえ。
C#や.NETの仕事がある企業は中小企業くらいだからねえ。
大手企業はJavaの仕事がおおいね。
といってもJavaの基本(J2SE)程度知ったくらいじゃ確かに仕事は少ないね。
J2EEかServlet, JDBCなども知らないと仕事は増えないわけですな。
ついでにOracle, ネットワークの知識、Unixの知識も知らないといかんですなあ。
これくらい知っていればJavaの仕事もたっぷりあるでしょな。
384 :
仕様書無しさん :03/02/12 20:17
385 :
仕様書無しさん :03/02/12 21:45
言語の王者はVB、殆どの企業基幹システムはVBで 組まれているようです。 付属のシステムがC++、JAVA どう、違う?
>>385 はいつまらない釣りね。
VB厨を慰めるだけだね。
>>385 禿同!!VBは神!!
きっと、みずほの悲劇はVBによって引き起こされたんだね。
スペースシャトルのウワサの温度センサーも、VBのランタイムエラーかもよ!
次期WindowsのAPIはVBで記述されるらしいね。すごいね、VB!!
スレの名前変えようか?【最高に頭の悪い………】
389 :
仕様書無しさん :03/02/12 22:07
金融機関の基幹システムはVB。 バージョンUPしてもVB。 殆どのPGがVBだがね!
ガンダム搭載のAIもVB
393 :
仕様書無しさん :03/02/12 22:13
コストを考えればVBってこと?
そこまでVBほめたたえなくても・・・ 厨くるよ?
>そこまでVBほめたたえなくても・・・
よく読んでね。
っつか、おまいそれでもPGか?
>>393 も同罪。
>>396 おれの書きこみ自体も皮肉です。
いやーしかし・・・
VBってそこまでひどい言語かね。
おれは使い込んでないからわからん。
>>397 C/C++/Java/C#と比較してみいよ。
型がいい加減じゃないか。
もう最低だ。
いやぁ、書いてみるもんですね。 遅レスですいませんが、丁寧な回答どうもです。 今のチームではJava使わないので、勉学意欲失ってたとこだったので なおさらありがたいです。 とりあえず「Javaの鉄則」絶対買います。昔買った本を読み返して 勘を取り返します。 あと、同僚に貸したままの「Java謎」本をなんと返してもらいます(w
400 :
仕様書無しさん :03/02/12 23:40
むぅ、あげ損ねた。 あと誤字訂正。 >あと、同僚に貸したままの「Java謎」本をなんと返してもらいます(w あと、同僚に貸したままの「Java謎」本をなんとか返してもらいます(w
>>401 どうもです。
ただ、言語に関する根本的な疑問は、Faqサイトよりもム板よりも、
マ板のほうが向いてるような、そんな気がしただけっす。
VB をけなす香具師がよく 「型がいい加減」 とか書いてるのだが、どういう 事なんだ? VB で型の扱いに困ったことなんか無いぞ。
404 :
仕様書無しさん :03/02/13 06:05
たしかに、VBよりC++のほうがすぐるているだろう。 でも、企業で使う基幹システムはVBになっちゃんだよね。 本当はC++で組んだほうがいいのだがPGの能力がないため 安全なVBに走ってしまう。
>>403 VBを貶す理由としてはもっともアホで理不尽で筋違いなもの
の一つだと思うがな。
他に貶すところはいくらでもあるだろうに...(w
>>404 突っ込みどころが満載過ぎる。
とりあえず
> すぐるている
> 企業で使う基幹システム
> なっちゃんだよね
> 安全なVB
を指摘しておこう
>>403 C/C++/Java/C#との比較すればどれくらいいい加減かはわかる。
巨大なプログラムを作ってみればそのいい加減さにうんざりすることだろう。
VB.NETからは型もしっかりしてきたみたいだが。
最近、VBとVB.NETを一緒にする馬鹿が多くて困る。
>>406 突っ込むところは
> 安全なVB
だけでいいだろう。
他を突っ込むのは不毛な幼稚な揚げ足取り。
馬鹿でも使えるVBに走ってしまう。の方が妥当。
>>407 > C/C++/Java/C#との比較すればどれくらいいい加減かはわかる。
ふっ。「わかる」って言うだけで説明できんのか。
>>408 他のスレやム板で散々語られていることを
いちいち説明する必要もないと思ってな。
いまどき解らない香具師はブビ厨くらいだな。
文字列型に勝手に数値型を代入できても全くコンパイラが
何も文句を言わないことの恐ろしさがお前にはわかるか?
演算子のオーバーロードと同じようなものだろ。
う〜ん。静的な型付けを行わない言語なんてのはいくらでもあって、例えば ほとんどのスクリプト言語はそうである訳だが。で、それは一般のプログラマには 別に必ずしも悪い点とは考えられていない。これらの言語は宣言や型付けを 行わないことによる手軽さを選んでいる訳だ。言語設計には常にトレードオフがあり、 またプログラマが使用する道具を選択する上でもトレードオフが存在する。 こんなのはプログラマにとっては当たり前の話で、その辺を理解しないヤシは 単細胞と取られても仕方が有るまい。 そういう中で、VBのダメな所として(他に幾らでも問題があるのに)真っ先に 型付けの問題を上げるようでは、そいつの程度も知れてるってことよ。
>>411 お前甘すぎ。お前のほうがよほど程度が知れているってことだ。
巨大なプログラム作ったことがないからそういうことがいえるんだよ。
お前は単純なプログラム作ることを前提に議論しているだけだろ。
それともお前は型に甘い言語だけでミッションクリティカルに簡単に対応できるとでも思っていたのか?
そんな型に甘い糞言語を宇宙船の動力に搭載できるか。危なすぎて信用できない。
継承もできない、型に甘い手軽な言語で巨大なプログラムを作ってみろ。
バグも見つけにくい。潜在的な顧客の苦情にもバグに素早く対応できない。
拡張も素早くできない。
それともお前は継承もできないVBしか使っていないのか?
>>412 トレードオフという言葉が君には難しすぎたかな?
では、もう少し簡単な、適材適所という日本語の意味をよ〜く
噛みしめてから出直してきなさい。
>>413 君の説明が曖昧なのだよ。
君は
>>412 が型付けの問題だけを指摘しているとでも思い込んでいるのかね。
>で、それは一般のプログラマには
>別に必ずしも悪い点とは考えられていない。
君の言う "一般のプログラマ" がそうだと決め付けることも、君の主観ということだね。
>言語設計には常にトレードオフがあり、
君は何がトレードオフかという説明をしていないようだが。
言語設計の何がトレードオフかという説明をしていない君は論点が曖昧だ。
"言語選択の適材適所" から "VBの駄目なところで型の問題をあげる"ことに
話の筋をつなげている君の論法どういうこっちゃ
つまり
>>403 はVBで大規模なプログラミング経験をしたことがないということでよろしいか?
C言語と関係ない話やないか。 継承ができないクラスしか定義できないWin以外でろくに動かんVBはC言語より早く死滅するんだからどうでもええっつーの
417 :
仕様書無しさん :03/02/13 15:44
>>414 >君の説明が曖昧なのだよ。
むー。そうかも。
>君は
>>412 が型付けの問題だけを指摘しているとでも思い込んでいるのかね。
少なくとも412以前で問題になっていたのは型付けの問題だったと
思うのだが。ちがう?
勝手に話を広げないで欲しいね。
>君は何がトレードオフかという説明をしていないようだが。
411の、>これらの言語は宣言や型付けを行わないことによる手軽さを選んでいる
→がここではトレードオフのつもり。要は静的な(強い)型付けを行うかどうかには
簡便さ・安全性・といった言語設計上の選択が有りトレードオフが有るということ。
どうも412には、「大規模で複雑な開発に適した言語(こそ)が、優れている」といった
類の極めて単純な、一次元的指向が有るように見えたのでね。
>"言語選択の適材適所" から "VBの駄目なところで型の問題をあげる"ことに
>話の筋をつなげている君の論法
う〜ん。そういう順序で「話の筋をつなげ」た記憶はないんだが。。。
要は
・VBが強い型付けを行わないのは言語設計上の選択で、そもそも
VBという言語自体が、
>>412 に書かれているような大規模なプログラミング
に向いたものではなく、むしろお手軽かつ迅速なプロトタイピングのような
用途に最も適しており、そのように設計されている。
・言語特性を適切に把握して適材適所で用いるのはプログラマの責任であって、
そもそもVB向きでない対象にそれを適用して「つかえね〜」なんて云ってるのは
そりゃ選んだ奴が悪い。
・そもそも型付けを行うかどうかの問題は別にVBに限ったことじゃなく、
「強い型付けを行わない」ことはVBという言語環境をもっとも的確に表した
ものでもないから、VBを貶すのにそういう話が出てくるのはちょっと違うんでない、
といったところだね。
>>416 例えば、継承は出来るけど型付けはなくて、継承といってもundef出来たり
instance_evalが出来ちゃったりしちゃうような某言語はいかがでしょうか。
必死だな
421 :
仕様書無しさん :03/02/13 18:43
C言語もそれだけではクラス作れないからC++からみても 糞にしか見えないが、 プログラムの仕組みの勉強にはうってつけかもな。
C++ってclassという予約語があるだけでぜんぜんOOPLじゃないんだよな。 もうJavaもC#も(かつてはC++の唯一の売りであった)genericなコンテナライブラリがサポートされるから これから死滅に向かっているのは間違いないよ。
>>423 速度面ではJavaもC#もC++には全然負けている。
VMやOS作りに向いているためJavaやC#が現れたくらいでは死滅は
ありえないだろう。
templateを侮る事勿れ。
Cの得意な低レベルな部分にはそれほど食い込めてないし アプリ開発ではもはやMFCなんてお呼びじゃないしで 上下から押しつぶされてジリ貧だよ。 Cよりも狭い一部の用途で細々と使われていくんだろうね。
何の事言ってるのかさっぱりダ。
>>425 JavaにもJ2SE1.5から限定的なC++templateであるGenerics機能が追加される。
C#は代替の方法を使用しているらしい。
>>426 C++の話、それともC#の話?
>>426 C++=MFCですか?へーそりゃ凄いや。
>>429 >>426 の脳内ではC++=VC++でしかないんだろう。
MFCこそ優れたライブラリだと思い込んでいる。
431 :
仕様書無しさん :03/02/13 22:44
MFCに限らずC++のGUIライブラリは全面的に糞だろ。
>>432 フレームワークは使いこなすのが難しいということですよ。
>>433 しかし、C++のGUIライブラリが糞なら
>>431 一体なにが一番いいと思っているのでしょう?
Delphiに決まってるだろ。 C#は成熟するのにあと1・2年はかかるだろう。
>>435 VBがアップデートされるたびに泣いた者もいるくらいだ。
C#は成熟どころか、M$の独断と偏見で再構築され現在のC#プログラマが
既にコーディングしたC#コードの修正でC#プログラマを泣かせるだろう。
変化が怖けりゃEmacsでCのコードをちまちま書いていればいいさ
C も変化しまくってる罠
ある日突然、参照渡しが値渡しになる恐怖を、キミは体験した事があるか!?
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を死滅させるにはいたらないだろう。シェアを少し縮めることができるかもしれないが。
>今からJavaコード、自作クラスライブラリ、API、フレームワークを沢山作っても 要するに単位行あたりの機能性生産性が低いといいたいのか?
>>441 単位行あたり、短いプログラムを書きたい、使い捨てプログラムを書きたい
という生産性用途ではJavaはVB,perl,C++,C#などに劣るでしょう。
巨大なプログラム作り、長く使うプログラム、ネットワーク重視にはJavaの方がVB,C,C++,C#より向いているでしょう。
443 :
仕様書無しさん :03/02/15 01:08
>巨大なプログラム作り、長く使うプログラム、ネットワーク重視にはJavaの方がVB,C,C++,C#より向いているでしょう。 匿名掲示板で根拠を示さず主観や偏見に基づく意見を主張するってきっと気持ちのいいことなんでしょうね。
>>443 匿名掲示板で、たとえ主観であれ偏見であれ、自分の意見すら言わずに
単に皮肉で煽るってのはさらに気持ちのいいことなんでしょうね。
PERFORM
447 :
仕様書無しさん :03/02/15 01:22
Linux上でJavaを使ってタブ型メモ帳作ってます。 かっくいいです。
>>444 おお、その通りですじゃ。
>>443 は相当Javaに抵抗があるお方のようですじゃ。
じゃが、使って見れはその実体が解りますのじゃ。
やっぱり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でいーじゃん♪
>>452 >テンプレートでガチガチに固めたオブジェクト指向構成
→テンプレートとオブジェクト指向は特に関係がない直交する概念ですが
何を云いたいのでしょうか?
>デジドカ大量導入する開発では効果は高い
→兵隊さんを大量導入するような開発現場が効率よく回せるというのが本当なら
それは大変素晴らしいことではないでしょうか。「育たない」と困るプロパー
以外の使い捨てプログラマにたいしては、非常に有効な手法だという訳ですね。
>シロートが「設計」「設計」とのたまう開発はウザイ
→それは言語とは特に関係がないものですね。まあ、「シロート」に設計を
まかせるような会社に問題があるのですから、転職でも考えてみては?
455 :
仕様書無しさん :03/02/15 10:45
この業界には本当に、 主張を完全に論破されるような無能馬鹿が多いのだろうかと 考えずにいられない。 マ板を見ていると。
>>450 アセンブラーで石二つ? Z80と何かか?
まあ、アセンブラくらいなら大抵の情報系の大学卒業している香具師は経験しているぞ。
情報科学をろく知らない香具師が死滅ストーリーを語るんじゃないといいたのはわかる。
しかしなあWeb系ではperlは死滅の方向に向かっているように見えるぞ。
perlはshとと共にUnix系でスクリプトいじるのに生き残りそうだが。
レンタルサーバで流行っているPHPも単位容量あたりのメモリの価格がHDDと同じくらい安くなればJ2EEやJavaServlet/JSPにとって変わられる日もやってくるかもな。
C/C++/Java/C#がpython風な記述になった言語が登場すれば面白そうだが。
>>456 > 情報科学をろく知らない香具師が死滅ストーリーを語るんじゃない
死滅ネタが情報科学と関係があるとは思えんが。。。
少なくとも「科学」じゃあないだろ。
>>450 が云いたいのは、単純に知識経験が豊富なヤシの方が単なる煽り厨
より面白可笑しくネタを語れるでしょ、ということだと理解している。
それはそれで正しいんだが、
1)そういうことはあまりにも当たり前であって、
2)しかもそんなことを云う奴よりは実際に面白可笑しくネタを語れる奴
の方が圧倒的に正しいのだが
3)実際まともな識見を持っている奴は死滅ネタなんざ相手にしないので
云うだけ野暮ではある。
459 :
仕様書無しさん :03/02/15 18:57
そのうち死滅するからほっとけよ。
462 :
仕様書無しさん :03/02/15 20:04
VB房ですが C++じゃ出来ないことって何?
何と比べてるの?VB?
464 :
仕様書無しさん :03/02/15 20:16
VBとC++です。
生産性の高い開発
C++では簡単ラクチン・プログラミング♪が出来ない。
>>462 短期で高機能、かつ、安いソフトを作ること。
>>462 短期で低機能、かつ、安いプログラマを作ること。
>>462 >>467 と
>>468 に共通すること。
すなわち、安いプログラマを作ることが出来ないために安いソフトを
作ることが出来ない。そして仕事を取ることが出来ない。
そりゃ、安い仕事しかできない奴に高い仕事がくるわけ無いわな。
>>470 どこに安い仕事と書いてあるのかな?
安いと書いてあるのはソフトとプログラマだけですよ。
え? 50万/月しか稼げないプログラムを作ったプログラマに 100万/月払ってるの?
>>471 会社役員ウマーの法則ですね(意味不明)。
同じ仕事を50万で作れるプログラマと100万で作れるプログラマがいたとしたら 50万で作れるプログラマのほうに仕事が行くのが当たり前だろう。
どこに同じ仕事と書いてあるのかな?
476 :
仕様書無しさん :03/02/15 21:07
おまいら うるせぇんだ。 C は 神 以上
>>475 書いてませんよ。もとから直接的なレスじゃありませんから。
478 :
仕様書無しさん :03/02/15 21:39
>>476 その通りです。
C言語は永遠に不滅です。
C 言 語 は
ノ イマ ン 型 コ ン ピ ュ ー タ が 死 滅 す る ま で
情 報 科 学 、 情 報 工 学 、
コ ン ピ ュ ー タ サ イ エ ン ス 、
コ ン ピ ュ ー タ エ ン ジ ニ ア リ ン グ の 世 界 で
永 遠 に 語 り 継 が れ て い く こ と で し ょ う 。
まあ、思い出にはなるだろうね。
所詮ノイマン型だしCでも十分 という考えかたもあるわな
新事実 C は量子コンピュータで大活躍
482 :
仕様書無しさん :03/02/17 10:30
なんか、昔のアセンブラ今 C、って感じだな。最近の扱い見てると。
>>483 まぁ、「高級アセンブラ言語」なんて別名もあるくらいだし。
>>483-484 それがCの正しい位置付けだと思うんだが、CORBAマッピングまで
あることからして、どうもそうは思っていない人もいるらしく…
486 :
仕様書無しさん :03/02/20 10:55
ヴィビ厨にはC言語を死滅させるスキルがありません。
487 :
仕様書無しさん :03/02/20 13:52
>>466 一度苦労しておけば出来ないこともないが、出来るようになるまでが大変だな。
488 :
仕様書無しさん :03/02/20 14:00
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は死滅してもいいや。
>>485 「CORBAマッピングまで」って、最初のCORBA仕様ではSmalltalkとCの
マッピングしかなかったわけだが。
494 :
仕様書無しさん :03/02/20 16:46
C++にできてCにできないことはないんだけど…。 激しく生産性が悪いがナ。
>>494 それはVBにできてアセンブラに出来ないことは無いって
言ってるようなもので、正しいが激しく無意味。
496 :
仕様書無しさん :03/02/20 16:49
>>494 だから、C++なんだよ。
C++は工夫次第でどこまでも生産性を高めることが出来る!
‥‥‥まあ、そこまで持ってくまでが大変なんだがな。
>>496 うちはもう
VBやdelよりも、C++のほうが生産性が高いよ。
これまでさんざん苦労したけど。
レスポンスもかなり早くなったけど
OSや開発環境のバージョンアップにも楽になったし。
保守作業がかなり楽になった。
サーバー側も予算がない所だと
C++だけで軽くて安くできるし。
JAVAも良いと思うが、C++も仕事の仕方でかなり良いと思うけど?
>>497 すげぇ!自社専用フレームワークとかできあがっちゃってるわけ?!
>>497 >>498 俺の会社もそう。
激安のサーバサイドは
Linux+Apache+フリーDBの自社カスタマイズ+自社アドインモジュール
ミドルウェア代をかなりケチった設定。
結構安定してるし、保守も楽、レスポンスも速いよ。
500 :
仕様書無しさん :03/02/20 18:54
まっWin32上では実質的に、.NET上では完全に死滅してるんだけどね。
502 :
仕様書無しさん :03/03/03 23:50
おまえらCが死滅寸前に追い込まれたときどうするよ? ちゃんと対策とってるかよ 死滅対策をよ 死滅後の行動とってるかよ
おまえら502が死滅寸前に追い込まれたときどうするよ? ちゃんと対策とってるかよ 死滅対策をよ 死滅後の行動とってるかよ 別に放っておいてもいいか
将来Cが死滅寸前に追い込まれるとして、 そのころUNIXやWindowsは何かで書き直されているんだろうか。
Microsoft Pascal++
| | ∧ |ω゚) ダレモイナイ ィョゥスルナラ イマノウチ |⊂ | ♪ ♪ ∧ ∧ イョゥ ョゥ ヽ(゚ω゚=)ノ イョゥ ョゥ ( へ) イョゥ イョゥ く ョゥ ♪ ♪ ∧ ∧ イョゥ ョゥ ヽ(=゚ω゚)ノ イョゥ ョゥ (へ ) イョゥ イョゥ > ョゥ
(^^)
∧_∧ ( ^^ )< ぬるぽ(^^)
509 :
仕様書無しさん :03/04/22 23:48
double dNum = 0.0; を double dNum(0.0); と書こう ということでつか?
510 :
仕様書無しさん :03/04/23 04:27
Cが死滅するこたぁないだろ。 超高速化ルーチンの作成にはC++よりCの方がはるかに適しているんだから。 「今日の性能には高速化ルーチンなんか必要ない」とか言ってるヤシは 現実を知らないんだよ。
10年以上先の話だと思うけど... COBOL と C どっちが先に逝くのだろうか? COBOL はかなりしぶとい気がする。 C なんざ、よりすぐれた後継言語が出ればすぐ死滅すると思うが...
コボラーもCジジイも早く逝ってほしい
>>511 COBOLはJ2EEによって死滅させられる。
.NEtはCOBOLをぶっ殺す力はないだろう。
C言語はJava2Enterpriseが死滅しない限り死滅しない。
なぜならJVMはCでできているから
携帯ゲーム機"プレイステーションポータブル(PSP) このPSPは、新規格UMD(ユニバーサルメディアディスク)というディスクを利用しており、そのサイズは直径6cmととても小さい(CDの半分程度)。 容量は1.8GBとなっている。 画面は4.5インチのTFT液晶で、480px x 272px(16:9)。MPEG4の再生やポリゴンも表示可能。外部端子として、USB2.0とメモリースティックコネクタが用意されているという。 この際、スク・エニもGBAからPSPに乗り換えたらどうでしょう。スク・エニの場合、PSPの方が実力を出しやすいような気がするんですが。 任天堂が携帯ゲーム機で圧倒的なシェアをもってるなら、スク・エニがそれを崩してみるのもおもしろいですし。かつて、PS人気の引き金となったFF7のように。
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―