Ｃ言語を死滅させよう

このエントリーをはてなブックマークに追加
1 ：仕様書無しさん：
今すぐは無理だけど、そういう方向で。。
2 ：COBOLCOBOLCOBOL：03/01/29 22:12
COBOLCOBOLCOBOLCOBOLCOBOLCOBOLCOBOLCOBOLCOBOL
OBOLCOBOLCOBOLCOBOLCOBOLCOBOLCOBOLCOBOLCOBOLC
BOLCOBOLCOBOLCOBOLCOBOLCOBOLCOBOLCOBOLCOBOLCO
OLCOBOLCOBOLCOBOLCOBOLCOBOLCOBOLCOBOLCOBOLCOB
3 ：仕様書無しさん：03/01/29 22:12
Linuxのカーネルのアセンブラを除くところは何言語で書くのでつか
4 ：仕様書無しさん：03/01/29 22:14
>>3
VBなんかいいと思うよ。
5 ：仕様書無しさん：03/01/29 22:15
>>3
VBなんて糞糞
COBOLで書きなさい。
6 ：仕様書無しさん：03/01/29 22:17
>>4-5 LinuxのカーネルとVBやCOBOLで書くのか?
そんな言語で書かれたOSはもはやLinuxではないな。

OSがWindows並みに退化するぜ。
もう穴だらけ。
7 ：仕様書無しさん：03/01/29 22:17
歴史が長いので色々なところに蔓延っているが問題。
駆逐するには時間が掛かるがやるべきことだと思う。
8 ：仕様書無しさん：03/01/29 22:18
>>1 Unix系OS、オープンソースコミュニティを死滅させない限り不可能。
9 ：仕様書無しさん：03/01/29 22:19
>>7 C言語死滅がなんでやるべきことなんだ?
むしろ、さきにVBやCOBOLを死滅させた方が効率が良い。
10 ：仕様書無しさん：03/01/29 22:20
Unixなどの過去の財産に拘っていては進歩が無い。
より長期的に見た展望が必要。
11 ：仕様書無しさん：03/01/29 22:21
Ｃ言語の生産性が低いから
無くしていくべきであるという観点です。
12 ：仕様書無しさん：03/01/29 22:22
>>10 Linux, *BSD, Solaris, BEOSがUnixベースのOSだということを忘れてないか?
13 ：仕様書無しさん：03/01/29 22:22
>>11 C言語を死滅させたらC++も死滅するぞ
14 ：仕様書無しさん：03/01/29 22:22
Cは死なないわ。私が守るもの。
15 ：仕様書無しさん：03/01/29 22:22
>>3
emacsLispで書いたら神！
16 ：仕様書無しさん：03/01/29 22:22
ｵﾏｴﾗ小物が何を言おうとMicrosoftは偉大。
17 ：仕様書無しさん：03/01/29 22:23
>>13 それどころかC#も死滅
18 ：仕様書無しさん：03/01/29 22:23
C++があればCはなくなってもいいや。
19 ：仕様書無しさん：03/01/29 22:24
>>16 C言語の死滅関係のレスになぜ突如M$が入ってくるのか不明
詳しく説明せよ
20 ：仕様書無しさん：03/01/29 22:24
このままいけば、Ｃ言語無しでは何も成り立たなくなってしまう。
というより成り立たなくなってしまったのが今かもしれない。
21 ：仕様書無しさん：03/01/29 22:24
>>18 C++は使い方によってはC言語と一身胴体。
C++が死滅しない限りC言語は死滅しない
22 ：仕様書無しさん：03/01/29 22:25
>>10 Unixから継承されたLinuxはC/C++で開発されているのだ。
23 ：Mac板よりコピペ：03/01/29 22:28
VVindovvsは90%がCOBOLで記述されているらしい
だから、C/C++/asmで記述されたMαcОSХと違って桁違いに性能が低い
24 ：仕様書無しさん：03/01/29 22:29
>>23 それがもし本当ならWindowsは糞OSだな。
25 ：仕様書無しさん：03/01/29 22:30
$makeにしてもC。
求人欄もC。
挙句の果てにC#
後戻りすべき時である。
26 ：仕様書無しさん：03/01/29 22:32
Ｃ言語を捨てることにより失った財産より
捨てたことによって得た財産が大きくなる
損益分岐点は必ずやってくると思う。
27 ：仕様書無しさん：03/01/29 22:36
結局あれですか、ここの皆さんはCが書けない人ですか。
何冊もC言語入門の本を持ってるのに無駄にしてる人達ですか。
28 ：仕様書無しさん：03/01/29 22:38
C言語が本当に生産性が高いと思っているのですか？
ただの標準で、仕方無しに使っているのではないのですか？
29 ：仕様書無しさん：03/01/29 22:38
>>27
話をすり替えるだけの奴は消えな。
30 ：詭弁の特徴のガイドライン：03/01/29 22:40
１：事実に対して仮定を持ち出す
　　　 「犬は子供を産むが、もし卵を生む犬がいたらどうだろうか？」
２：ごくまれな反例をとりあげる
　　　 「だが、時として尻尾が２本ある犬が生まれることもある」
３：自分に有利な将来像を予想する
　　　 「何年か後、犬に羽が生えないという保証は誰にもできない」
４：主観で決め付ける
　　　 「犬自身が哺乳類であることを望むわけがない」
５：資料を示さず自論が支持されていると思わせる
　　　 「世界では、犬は哺乳類ではないという見方が一般的だ」
６：一見関係ありそうで関係ない話を始める
　　　 「ところで、カモノハシが卵を産むのは知っているか？」
７：陰謀であると力説する
　　　 「それは、犬を哺乳類と認めると都合の良いアメリカが画策した陰謀だ」
８：知能障害を起こす
　　　 「何、犬ごときにマジになってやんの、バーカバーカ」
９：自分の見解を述べずに人格批判をする
　　　 「犬が哺乳類なんて言う奴は、社会に出てない証拠。現実をみてみろよ」
10：ありえない解決策を図る
　　　 「結局、犬が卵を産めるようになれば良いって事だよね」
11：レッテル貼りをする
　　　 「犬が哺乳類だなんて過去の概念にしがみつく右翼はイタイね」
12：決着した話を経緯を無視して蒸し返す
　　　 「ところで、犬がどうやったら哺乳類の条件をみたすんだ？」
13：勝利宣言をする
　　　 「犬が哺乳類だという論はすでに何年も前に論破されてる事なのだが」
14：細かい部分のミスを指摘し相手を無知と認識させる
　　　 「犬って言っても大型犬から小型犬までいる。もっと勉強しろよ」
15：新しい概念が全て正しいのだとミスリードする
　　　 「犬が哺乳類ではないと認めない限り生物学に進歩はない」
16：反論の代わりに詭弁ということにしてすます。
　　　 「それは詭弁です。いいから詭弁なんです。」
31 ：27：03/01/29 22:41
純粋なCで仕事をしたのはもう8年くらい前。
以降はずっとC++ですが、何か？
32 ：仕様書無しさん：03/01/29 22:43
Cは教育用にでも残しておいてよ。
あれが一番単純で教えやすいんだから。
33 ：仕様書無しさん：03/01/29 22:44
>>31
だから消えなって。
34 ：仕様書無しさん：03/01/29 22:50
>>25
そこでなぜC#が出るのか疑問

JavaクローンなC#がでるのは疑問。
C++ならわかるが。

ひょっとして >>25は C#はC言語の後継だと勘違いしていないか?
35 ：仕様書無しさん：03/01/29 22:51
いくら文明が進歩したところで路上の空き缶拾いをする人間が
いなくならないようにCだって細々と使われ続けるのは間違いない｡
要は使いどころをわきまえろってことだ｡
36 ：27：03/01/29 22:52
>>34
Cから始まってるからね。
37 ：仕様書無しさん：03/01/29 22:52
>>36 ﾊｧ?
38 ：仕様書無しさん：03/01/29 22:58
>>35
例えはアレですが、プログラム言語なんてものは使いどころの問題でしょうね。
39 ：仕様書無しさん：03/01/29 23:04
見てくればっかで速度がさほど要求されず、遅けりゃガンガン
HWリソースを追加してくれたり、定期的に止まっても再起動で
許してくれるよなWinの使い捨て業務系アプリなんかは、ま何で
書いてもいいだろう。開発側の趣味とか都合（開発効率etc）を
最優先して言語を選択するのはぜんぜんオーケーだ。

40 ：仕様書無しさん：03/01/29 23:09
>>39
例えはアレですが、まことにその通りです。言語よりも重要なことはたくさんあります。
41 ：27：03/01/29 23:11
>>38
書き方がわるかった。
C#の名前がCという文字から始まってるという意味。
42 ：仕様書無しさん：03/01/29 23:12
誰が何と言おうとMicrosoftは偉大。
Microsoftの戦略に踊らされ続け、逆らうことすらできない。
なぜならMicrosoftは偉大だから。
Microsoftに逆らう香具師はＩＴ業界から疎外される。
Microsoftはもう止まらない。
Microsoftは他の追随を許さない。
MicrosoftはIT業界を支配している。
Microsoftに逆らう香具師は愚か者だ。
43 ：仕様書無しさん：03/01/29 23:19
>>41
ということはCOBOLも(以下略
44 ：すぷーん ◆spoonLv.3M ：03/01/29 23:24
>>30
よく出来てるなぁ、と思って検索してみると、そういうスレがあるのね。
しかしよくできてる。
元ネタはなんだろ。
45 ：仕様書無しさん：03/01/29 23:34
C言語から派出した言語も糞。
COBOL マンセー！
46 ：仕様書無しさん：03/01/29 23:38
COBOLって、どんな言語ですか？
47 ：仕様書無しさん：03/01/29 23:39
なんていうかC言語のエラーのほとんどが、
配列の領域に関するものと
メモリを動的に確保するもの。

やっぱり、ぬるぽを自分で処理しなきゃいけない、
というのは、一般的なプログラマに対して荷が重すぎんじゃないだろうか？
48 ：仕様書無しさん：03/01/29 23:39
>>46
エレガントでエクセレントな言語
49 ：仕様書無しさん：03/01/29 23:40
プログラミング言語はRubyで統一すればよいのだ
50 ：仕様書無しさん：03/01/29 23:44
>>47
>なんていうかC言語のエラーのほとんどが、
>配列の領域に関するものと
>メモリを動的に確保するもの。
これってどんなエラー？
51 ：仕様書無しさん：03/01/29 23:44
>>8
UNIX系OSはCで書かれてるからその通りだが
オープンソースがなぜ出てくるの？
C以外の言語だとクローズになってしまうのか？
ソースを公開すりゃHSPだってオープンソースだろ
52 ：仕様書無しさん：03/01/29 23:46
>>50
10個しか確保しなかった配列の11個目を参照しようとしたとか、
リストのポインタが、果てしない荒野を指していたとか。
笑い話のような本当の話。
53 ：仕様書無しさん：03/01/29 23:47
>>50
エラーじゃなくてバグだとしたらメモリーリーク？
54 ：仕様書無しさん：03/01/29 23:48
>>52
それは動的かどうかは関係ないとおもうけど・・・
55 ：仕様書無しさん：03/01/29 23:48
>>51
知りもしないのに口出すな｡
56 ：53：03/01/29 23:50
あ、ちなみに「>メモリを動的に確保するもの。」へのレスね。
57 ：仕様書無しさん：03/01/29 23:50
こりゃまた過激なスレタイだなぁ
58 ：仕様書無しさん：03/01/29 23:50
>>54
配列の領域と関係するんだろ。
59 ：仕様書無しさん：03/01/29 23:52
>>58
配列の領域なんだから、動的とか静的は関係ないって事なんじゃない？
60 ：27：03/01/29 23:54
>なんていうかC言語のエラーのほとんどが、
>配列の領域に関するものと
>メモリを動的に確保するもの。

それはあなたがヘタレなのでは？
61 ：仕様書無しさん：03/01/29 23:54
>>53
リストのソースを書いたことがありますか？

struct Node {
int nData;
Node* pNextNode
};

みたいな。
62 ：仕様書無しさん：03/01/29 23:54
>>59
そりゃそうだ。動的は別の話だろ。
63 ：仕様書無しさん：03/01/29 23:56
>>60
ミスは誰にでもあるがその発見が難しいのが問題なんだろ。
64 ：仕様書無しさん：03/01/29 23:56
Cの初心なのに死滅させようと騒いでいる奴がいるのはこのスレですか？
65 ：仕様書無しさん：03/01/29 23:57
>>61
だから動的確保(mallocのことでしょ？)とは関係ないでしょ。
ノードの作成にmallocを使うのが一般的というだけで。
66 ：仕様書無しさん：03/01/29 23:57
>>64
>>29
67 ：仕様書無しさん：03/01/29 23:58
struct Node{
Data data;
Node* pre_p;
Node* next_p;
}

Node Index.next_p->Node.next_p->ぬるぽ
68 ：52,61：03/01/29 23:59
>>60
私だけの話だけでなく、一般論として。
自分自身の過去のバグを思い返してその割合を想定して
もらえば納得できるのでは。

生産性を下げる大きな要因は、その、作りこんでしまった
ポインタや領域計算のミスが、たまたま
うまく動いていて、突然、ぜんぜん関係なさそうなルーチンで
問題が表面化したとき。
69 ：仕様書無しさん：03/01/29 23:59
>>61
Cだとエラー
70 ：仕様書無しさん：03/01/30 00:00
　 （　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　 　 |　|
　　 Ｙ　/ノ　　　 人
　　　 /　）　 　 < 　>__Λ∩
　 ＿/し'　／／. Ｖ｀Д´）/
　（＿フ彡　　　　　 　　/ 　←>>67
71 ：仕様書無しさん：03/01/30 00:01
>>68
そうそう。表面化しにくいんだよね。それが一番の問題だ。
72 ：仕様書無しさん：03/01/30 00:01
>>61
すいません。へたれですな。最近C++しか触らないんで。

73 ：仕様書無しさん：03/01/30 00:02
とりあえずポインタは悪ということでよいかな？
74 ：仕様書無しさん：03/01/30 00:03
>>73
バッカモーーーーーーーーン
75 ：仕様書無しさん：03/01/30 00:04
>>73
と言うとまた信者が騒ぐから
費用対効果が低いことが多い｡くらいにしとけ｡
76 ：仕様書無しさん：03/01/30 00:04
ポインタが悪というより、論理的に無効な場所にアクセスできる所が悪。
77 ：68：03/01/30 00:05
>>73
悪と言いきれない。

領域計算すら、プログラマに任せて突き放すことで得られる
圧倒的なパフォーマンスを無視することはできない。
78 ：仕様書無しさん：03/01/30 00:07
> 圧倒的なパフォーマンス
プ
79 ：仕様書無しさん：03/01/30 00:09
>>77
今となってはわずかなパフォーマンスというべきですな。
80 ：仕様書無しさん：03/01/30 00:10
>>71
問題になるほど表面化しにくいのは、
1) 作りに問題がある
2) その程度の問題を解決できない人間に C を使わせることこそが問題
の、どちらかでは？
81 ：仕様書無しさん：03/01/30 00:13
発生する問題が文法エラーだけならどんなにか楽なものか。
82 ：仕様書無しさん：03/01/30 00:13
ま、何だかんだいっても、ソレが必要でソレ以外に選択肢が
ない場面はたくさんあり、そしてソレを使いこなせる一部の人間が
ちゃんと居てくれることで、この業界の底辺がしっかりと支えられて
いるという現実があるってこった。
APIのお化けみたいな環境で積み木細工のような仕事ばっかしてる
ﾜｼﾗみたいのは、感謝の気持ちを忘れちゃいかんて。
83 ：仕様書無しさん：03/01/30 00:15
>>80
そうそう、配列の不等号を間違えて一つ外の要素を参照したり
freeを呼ぶのを忘れたり、バッファオーバーフローをするコードを入れたり、
そんなことをする奴はC言語を使っちゃいけないね。
今すぐ全員解雇すべきだ。もちろん、あんたの会社からもね。
84 ：80：03/01/30 00:15
>>83
じゃあ真っ先に俺が首切られちゃうじゃん(T_T)
85 ：仕様書無しさん：03/01/30 00:19
>>83
>そうそう、配列の不等号を間違えて一つ外の要素を参照したり
>freeを呼ぶのを忘れたり、バッファオーバーフローをするコードを入れたり、
>そんなことをする奴はC言語を使っちゃいけないね。
って事はメモリ管理のバグは絶対に作りこまない方ですか？
86 ：71：03/01/30 00:19
>>80,83
まったくおっしゃる通り。
そういう意味で.NETとかいいかもね。

重要なライブラリだけをできるひとたちだけでC++でやるという。
87 ：27：03/01/30 00:19
>うまく動いていて、突然、ぜんぜん関係なさそうなルーチンで
>問題が表面化したとき。

Cを覚えたてのころには、確かにこういう経験をして、
半泣きになりそうな気持ちでリセットボタンを押していた
けど（当時PC-98シリーズ全盛期)
その時期を過ぎれば、そういうミスを事前に防ぐ工夫を
いろいろと覚えるんだよ。
だからオレの場合、ここ数年はそういうバグは経験してない。
去年、うちの職場のヘタレが特定の状況でヒープを壊す
プログラムを書いて3日苦しんで、オレのところに
相談に来たけど、そういう間違いを早く見つけるコツという
のもある。3時間かかったけど該当箇所をそいつに突きつけて
やったよ。
そういうメモリに関するトラブルをコントロールできる
ようになって初めてCを使えるっていうの。

逆に言うとそういうメモリを壊すようなバグこそ、
C/C++プログラマにとっての一番の敵なんだから、
そういうのを持て余すようなヤツが言う
「CやC++は生産性が高くない。」
って言葉こそアテにはならない。
限定句をつけて、
「私にとっては、CやC++は生産性が高くない。」
と堂々と言うのであれば、
「それじゃ、あなたはJavaでもVBでも使えば？」
と言ってあげるけどね。
88 ：仕様書無しさん：03/01/30 00:20
つーかclassとvirtualがない時点で使う気がしない｡
89 ：仕様書無しさん：03/01/30 00:21
>>88
あーた、話を振り出しに戻したところで・・・
90 ：仕様書無しさん：03/01/30 00:23
生産性が高くないのは事実だと思うけど・・・
91 ：仕様書無しさん：03/01/30 00:23
> 逆に言うとそういうメモリを壊すようなバグこそ、
> C/C++プログラマにとっての一番の敵なんだから、
メモリを壊すバグが一番の敵となっている時点で間違っている。
そういう、本質でないことに無駄な努力をしているから技術力が
あるという考えは改めなければならない。
92 ：80：03/01/30 00:25
>>88
私はコンストラクタ/デストラクタも欲しいです。

>>84
騙らない様に。
93 ：仕様書無しさん：03/01/30 00:25
つーかstringがない時点で(略
94 ：仕様書無しさん：03/01/30 00:25
オーバーロードだけほしい
95 ：仕様書無しさん：03/01/30 00:28
そーゆー意味でもMicrosoftは偉大だと思う。
96 ：仕様書無しさん：03/01/30 00:29
SUNもね。
97 ：27：03/01/30 00:31
>>91
それもそうだ。
初心者にとっての一番の敵と言い直しておく。

98 ：仕様書無しさん：03/01/30 00:33
初心者なんぞどうでもいい。

重要なのは熟練者が以下に早く目的の物を作れるかだ。

初心者に都合が悪ければ初心者用のルールを作ればよかろう。
99 ：98：03/01/30 00:33
× 以下に
○ いかに
100 ：仕様書無しさん：03/01/30 00:34
>>51 オープンソースにはC言語で書かれているものがあるから

>>54
C言語の配列は恐怖だ。配列サイズオーバーしてのアクセスや
indexがマイナスの配列は
JavaならArrayIndexOutOfBoundsExceptionや
NegativeArrayExceptionなどが発動する。

動的配列はVectorなどのCollection系を使うだろう。

>>73 ポインタが悪い? そんなこといってポインタ使用禁止にしたら
JavaもC#つかいものにならんわい。
ポインタ(参照)とポインタ演算の区別くらいつけておけ。

>>87 なぜJavaとVBを一緒にするのか不思議。
101 ：仕様書無しさん：03/01/30 00:34
>>98
そういう意味でこそCは生産性が低いだろ｡
102 ：仕様書無しさん：03/01/30 00:36
>>ポインタ(参照)とポインタ演算の区別くらいつけておけ。

皆様、どう思われますか？
103 ：仕様書無しさん：03/01/30 00:38
>ポインタ(参照)
ただ場を混乱させたいだけだろ｡
104 ：仕様書無しさん：03/01/30 00:40
ポインタと参照が違うものだと言い張るのなら、
参照があればポインタはいらないというのも理解できる。
105 ：仕様書無しさん：03/01/30 00:42
>>102 ポインタ演算はソースコードを汚し見づらくするだけでなく
デバッグもしにくくする。かといってポインタをなくせということでもない。

ポインタがないと不便だからな。
そもそもJavaではおもいっきりポインタを使っている。
オブジェクトへの参照がポインタそのものだからな。
106 ：仕様書無しさん：03/01/30 00:43
>>104 ポインタ == 参照
ポインタ演算 != ポインタ
107 ：仕様書無しさん：03/01/30 00:45
>>105
>オブジェクトへの参照がポインタそのものだからな。
int　func(int &a){
}

int　main(void){
　int　a;
　func(a);
}
108 ：仕様書無しさん：03/01/30 00:47
たとえ概念や実装に類似点があるとしても
参照をポインタと言い張るのは明らかな間違い｡
109 ：仕様書無しさん：03/01/30 00:48
Cのマルチスレッドが一番難しい
110 ：仕様書無しさん：03/01/30 00:48
>>108
では違いをおっしゃってください。
111 ：108：03/01/30 00:50
型が違う｡以上｡
同じだと言い張っているリファレンスが
あるならそれを示してください｡
112 ：仕様書無しさん：03/01/30 00:51
アドレスの参照　→　参照
アドレスの引渡し　→　ポインタ
113 ：仕様書無しさん：03/01/30 00:53
にしろ、なまのアドレスの香りがするだけで
C系の言語ってある種異様ではあるよね。
アセンブラと高級言語の庶子って感じ。
114 ：仕様書無しさん：03/01/30 00:57
>>107 Javaで書くと...
public class PointerDemo {
　private int func(Integer a){
　}

　public static void main(String[] args){
　　int a;
　　func(new Integer(a));
　}
}

>>108 Javaでは間違いではない。C#は微妙だな。
Javaではオブジェクトはすべて参照型になる、。
int, longなどは値型のみである。
115 ：仕様書無しさん：03/01/30 01:03
そもそも、”ポインタ”って呼ばれる物は機能名だろ？
ポインタ演算ってのはポインタ機能の一つ。
116 ：仕様書無しさん：03/01/30 01:04
>>91
mallocを書いたその手でfreeを書く自分を悲しく思ったりはする。
117 ：仕様書無しさん：03/01/30 01:05
>>111
なんだよ。型が違うって。違う理由になってなじゃんか。
118 ：仕様書無しさん：03/01/30 01:06
>>114
> int, longなどは値型のみである。
おいおい。でなおせ。
119 ：仕様書無しさん：03/01/30 01:07
C はよく判らない Java 使いの >>100 登場以降、話がずれていますが
>>103
>ただ場を混乱させたいだけだろ｡
まさにこの通りになってますね。
120 ：仕様書無しさん：03/01/30 01:07
プリミティブ・・・
121 ：108：03/01/30 01:12
>>C#は微妙だな。
C#では参照とポインタは文法上厳密に区別された別物で
同一視することは不可能です｡

>>108 Javaでは間違いではない。
で､それはリファレンス上のどこに書いてありますか?

別に雑談で"ポインタ"という語を不正確に使いたいだけならそれでもかまいませんが｡
122 ：仕様書無しさん：03/01/30 01:13
>>118 お前Javaをよく触っていないだろ?
Javaではint, longなどのプリミティブ型はC/C++/C#のように&をつけて
参照型にすることを禁止しているんだよ。

それでラップクラスのInteger型を使用して参照型にしているんだよ。
わかったか?
123 ：仕様書無しさん：03/01/30 01:14
>>121 用語が違うだけで概念は同じ。
124 ：仕様書無しさん：03/01/30 01:14
ポインタと参照の型が違うのは百も承知。
機能的な点での違いは何かという答えを求めている。
その違いこそがポインタ演算だろう。
125 ：仕様書無しさん：03/01/30 01:15
なんでJava厨が暴れているの？
126 ：仕様書無しさん：03/01/30 01:15
JavaとC#、先に死滅するのはどっちか。
127 ：仕様書無しさん：03/01/30 01:17
>>125 アンチJavaですか?
128 ：仕様書無しさん：03/01/30 01:19
>>124 何言語の話ししてんの?
129 ：仕様書無しさん：03/01/30 01:21
Pascalの話をしようぜ。
130 ：仕様書無しさん：03/01/30 01:21
>>125 誰も暴れていないけど。
あんたム板の死者ﾌﾟﾁｭ?
131 ：仕様書無しさん：03/01/30 01:22
>>126 M$が気分が変われば新しい言語作ってC#はすぐに死滅
132 ：仕様書無しさん：03/01/30 01:22
>>128
CとJAVAでしょう？
参照の加減算はできないけれども
ポインタの加減算はできると？違う？
133 ：仕様書無しさん：03/01/30 01:23
>>124
どの言語について知りたいのか判りませんが、“百も承知”という割には
型が違うとしか理解していないんですね。
しかも、ちょっと検索してみるくらいの事も出来ない割には不遜な態度ですねぇ。
134 ：仕様書無しさん：03/01/30 01:23
>>128
C++しかないんじゃない？ 同時に二つあるのって。
135 ：仕様書無しさん：03/01/30 01:24
>>132
C には、所謂“参照”と呼ばれるものはありません。
136 ：仕様書無しさん：03/01/30 01:24
>>134
Rubyにも両方ある
137 ：仕様書無しさん：03/01/30 01:24
>>133
ポインタ演算って書いてあるじゃん。よく読め。そしてお前の意見を言え。
138 ：仕様書無しさん：03/01/30 01:24
>>134
勉強不足｡しかもC++の参照は明らかに設計ミス｡
139 ：仕様書無しさん：03/01/30 01:24
>>124
>ポインタと参照の型が違うのは百も承知。
ナにこれ? Cのこと、Javaのこと?
140 ：仕様書無しさん：03/01/30 01:25
>>100の思惑通り乱れに乱れたな
141 ：仕様書無しさん：03/01/30 01:26
>>137
お前は不正確な用語を撒き散らして場を混乱させてるだけ｡
お前の言いたいことは最初からみんなわかってるからもう失せていいよ｡
142 ：仕様書無しさん：03/01/30 01:27
プログラム言語用語のポインタ・参照と
概念的な用語とをごっちゃにしてたら
話はまとまらないだろう。
143 ：仕様書無しさん：03/01/30 01:27
>>140 何言いたいん?
144 ：仕様書無しさん：03/01/30 01:28
>>141
ったく厨房はこれだから。すぐに話を誤魔化す。
145 ：仕様書無しさん：03/01/30 01:28
良スレだと思ってたのに。
もっと、Cの良いところ、悪いと思うところの話をしようよ。
27さんとか寝ちゃった？
146 ：仕様書無しさん：03/01/30 01:29
>>122 で論破されてなんとか話を誤魔化そうとしているのかな?
147 ：仕様書無しさん：03/01/30 01:30
>>145
Cなんかどうでもいいの。
今はJavaの話をしているの。
148 ：仕様書無しさん：03/01/30 01:30
27が一番の混乱の元だろう
149 ：仕様書無しさん：03/01/30 01:31
ま、とにかくCのポインタ配列はバッファーオーバーフロー、メモリリークの素として脅威だということだな。
150 ：仕様書無しさん：03/01/30 01:31
>>146
Cの話題で太刀打ちできないとおもい、Javaの話を持ち出して優位に立とうとしているだけ。
誰がとは言わないけど
151 ：仕様書無しさん：03/01/30 01:31
>>147
じゃあJAVAのスレ立てなよ。マジな話。
152 ：ここでCMです 詭弁の特徴のガイドライン：03/01/30 01:32
１：事実に対して仮定を持ち出す
　　　 「犬は子供を産むが、もし卵を生む犬がいたらどうだろうか？」
２：ごくまれな反例をとりあげる
　　　 「だが、時として尻尾が２本ある犬が生まれることもある」
３：自分に有利な将来像を予想する
　　　 「何年か後、犬に羽が生えないという保証は誰にもできない」
４：主観で決め付ける
　　　 「犬自身が哺乳類であることを望むわけがない」
５：資料を示さず自論が支持されていると思わせる
　　　 「世界では、犬は哺乳類ではないという見方が一般的だ」
６：一見関係ありそうで関係ない話を始める
　　　 「ところで、カモノハシが卵を産むのは知っているか？」
７：陰謀であると力説する
　　　 「それは、犬を哺乳類と認めると都合の良いアメリカが画策した陰謀だ」
８：知能障害を起こす
　　　 「何、犬ごときにマジになってやんの、バーカバーカ」
９：自分の見解を述べずに人格批判をする
　　　 「犬が哺乳類なんて言う奴は、社会に出てない証拠。現実をみてみろよ」
10：ありえない解決策を図る
　　　 「結局、犬が卵を産めるようになれば良いって事だよね」
11：レッテル貼りをする
　　　 「犬が哺乳類だなんて過去の概念にしがみつく右翼はイタイね」
12：決着した話を経緯を無視して蒸し返す
　　　 「ところで、犬がどうやったら哺乳類の条件をみたすんだ？」
13：勝利宣言をする
　　　 「犬が哺乳類だという論はすでに何年も前に論破されてる事なのだが」
14：細かい部分のミスを指摘し相手を無知と認識させる
　　　 「犬って言っても大型犬から小型犬までいる。もっと勉強しろよ」
15：新しい概念が全て正しいのだとミスリードする
　　　 「犬が哺乳類ではないと認めない限り生物学に進歩はない」
16：反論の代わりに詭弁ということにしてすます。
　　　 「それは詭弁です。いいから詭弁なんです。」
153 ：仕様書無しさん：03/01/30 01:32
>>149 となるとC#のunsafeも脅威
154 ：仕様書無しさん：03/01/30 01:32
>>153
だからunsafeなんじゃ・・・
155 ：仕様書無しさん：03/01/30 01:34
>>153
もともと気をつけて使うものだから脅威なのは当然。
Cのポインタ配列はC#のunsafeと同等レベルなのだよ。
156 ：仕様書無しさん：03/01/30 01:34
>>150 それだったらCではなくC++/C#で太刀打ちできない、
というならわかるが。

ここはC死滅スレだろ。
ム板名物「死者ﾌﾟﾁｭって死滅しちゃうの?」 シリーズということで
157 ：仕様書無しさん：03/01/30 01:34
>>154
確かに（ｗ
158 ：仕様書無しさん：03/01/30 01:41
unsafeは用途が限定されるためCほど
致命的で発見が困難な不具合が生じる可能性は少ないよ｡
これはgotoがBASICが制御構文として乱用されていて危険であるのに対して
Cが限定的に使用する為に比較的安全であるのと同じこと｡
159 ：仕様書無しさん：03/01/30 01:41
C言語を死滅させたければC#のunsafeを使用禁止にしないとな
160 ：仕様書無しさん：03/01/30 01:44
>>159
逆だろ。速度が遅くても安全さがほしいときならunsafeを使わず、
危険でもいいから速さがほしいとき等にunsafeを使うことで
Cの出番をなくさせる。
161 ：仕様書無しさん：03/01/30 01:51
>>160 それはC言語の普及に歯止めをかけるという意味だね。
この世からC言語の使用を完全に禁止し、
この世に存在するC言語のソースコード、書籍も
すべて焼却して初めてC言語が死滅した、とすれば
>>159 的な意見が出る。
162 ：仕様書無しさん：03/01/30 01:55
>>160 しかしなあ。C#の値型の構造体は速いようで遅い。
特にループ内で構造体を大量にすると。
C#では構造体の使い方を間違えるととんでもなくパフォーマンスが低下するからなあ。

あと、C#とC/C++とのベンチマークは殆どがCが最高だよ。
C#はC/C++と比べるとJavaよりちょっとだけ早い、という結果が殆どだよ。
163 ：仕様書無しさん：03/01/30 01:55
>>161
わけわかめ。それならC#をどうしようが関係ないじゃん。
164 ：仕様書無しさん：03/01/30 01:56
C++やJava,C#があるにもかかわらず、
いまだCがはびこるのは？なぜ？
それこそ１のように死滅させたほうがいいのでは？
165 ：仕様書無しさん：03/01/30 01:57
>>161-162
なにかごちゃごちゃ言ってるが、
> C言語を死滅させたければC#のunsafeを使用禁止にしないとな
という意見は間違ってたということでよいな。
166 ：仕様書無しさん：03/01/30 01:57
>>164
エレガントでスウィートだから。
167 ：仕様書無しさん：03/01/30 01:59
>>164
今の世の中のコンピュータはすべてハイスペックという訳ではないのだよ。
低スペックとハイスペックにわかれる。
低スペックのコンピュータではC言語しか使えないのさ。
168 ：仕様書無しさん：03/01/30 02:01
>>164
> C++やJava,C#があるにもかかわらず、
> いまだCがはびこるのは？なぜ？
Cは学校でもよくつかわれているからね。
他に、既存のソースコードの殆どがCとして眠っている、または稼動している。
それを再利用するためにはC言語を学習しないといけない。
たとえＣ言語から新しい言語に乗り換えようとも、
C言語のソースを読まなければ新しい言語に移植することができないケースも多いだろう。
そして*&->操作だらけのソースコードを必死になって解読。
このような煩雑なコードを解読するためにCを必死になって学んで解析している人が多いのではないだろうか?
> それこそ１のように死滅させたほうがいいのでは？
どうやって?
169 ：仕様書無しさん：03/01/30 02:01
>>167
ケイタイとか？
マジレスきぼん。
170 ：仕様書無しさん：03/01/30 02:03
>>165 死滅の定義にもヨルヨルヨ
171 ：仕様書無しさん：03/01/30 02:04
>>164 JVMはC(C++)で書かれているらしい。
172 ：仕様書無しさん：03/01/30 02:04
>>170 そのくらいでやめとけ。
173 ：仕様書無しさん：03/01/30 02:05
だからC/C++はOS/VM作成専用言語って言ってるでしょ。
174 ：仕様書無しさん：03/01/30 02:07
>>173
そうなってくのかなぁ。そうなるといぃなぁ。
175 ：仕様書無しさん：03/01/30 02:08
そんなことよりBS2にYMOがでとるぞ
176 ：仕様書無しさん：03/01/30 02:09
>>175
（ｗ
177 ：仕様書無しさん：03/01/30 02:16
>>174 必然的にそうなっていくだろ
>>175 衛星かい。テクノ好きか?
178 ：仕様書無しさん：03/01/30 02:27
C言語と掛けてYMOと解く
その心は今じゃ見る影も無い
179 ：仕様書無しさん：03/01/30 02:37
>>178　初耳。由来は?
180 ：仕様書無しさん：03/01/30 18:15
ポインタ本を買い漁ったり、
ソースとC言語仕様書をミラメッコするのが良いのですか？
181 ：仕様書無しさん：03/01/30 18:21
Cを死滅させるより、Cも使えない無能PGを抹殺する方が簡単じゃない？
182 ：仕様書無しさん：03/01/30 18:34
1よ！いくらポインターが理解出来ないからといってcを無くせだなんて無茶だよもう少し冷静にね
183 ：仕様書無しさん：03/01/30 19:00
>>182 Cを死滅させるよりC#を死滅させる方が簡単かも。

>>1はC言語を死滅させたがっているようだが、
代替の言語として何を使っている(あるいはこれから何を使いたがっているのだろうか?)


会社でC言語使いたくなければ、
表向きはC言語を使っているように見せかけて
中身は他の言語でCコードからほかの言語を呼び出すと言う
手段を使おう。

表向きはJavaを使っているが中身はJNI使ってC/C++バリバリ。
表向きはC#を使っているが中身はunsafe使ってC/C++バリバリ。
>>1よ、これの逆を実行せよ。
184 ：仕様書無しさん：03/01/30 19:31
> 表向きはJavaを使っているが中身はJNI使ってC/C++バリバリ。
> 表向きはC#を使っているが中身はunsafe使ってC/C++バリバリ。
はた迷惑だな。そういう連中は氏んでほしい。
185 ：仕様書無しさん：03/01/30 19:34
高級言語としての用途はC#/Javaでもいいけど、
依存一切無しの.objを吐けるアセンブラモドキとしての用途が残ってるからなあ…。

PascalやAda(やC++)なんかも.objは吐けるけど、
初期化ルーチンの呼び出しが必要だったりしてあんまり向かない。
結局、ある程度移植性を持ち、尚且つ低レベル用途に使えるのは(流行ってる中では)Cしか無い事になる。
ポインタ演算を含む危険な機能も、アセンブラモドキ用途には必須だから、別に構わない。
Cの欠点は、機能とは直接関係ない設計次第で無くせる文法上の落とし穴が多いことではないだろうか。

constのかかり方やセミコロンの不統一、switchの落下、boolの不在、ミスを誘う構文糖…。
(幾つかはC99で直されたけど、それでもまだまだ落とし穴は大量に有る)

ここはひとつ、アセンブラモドキとして使える新しい言語の登場を…って今更無理か。
186 ：183：03/01/30 20:26
>>184　逆だったらいいと思う。
表向きは高級言語で裏、中身の大半が
低級言語で書いている香具師は、
新で欲しい、と漏れも思う。
187 ：仕様書無しさん：03/01/31 01:48
D 言語ってどうよ？
188 ：仕様書無しさん：03/01/31 02:24
>>187 あれC#, javaっぽくて期待大だ。

C#に対抗するだけの力があるかもしれない。
189 ：仕様書無しさん：03/01/31 03:18
Java厨って他にやること無いの？
190 ：仕様書無しさん：03/01/31 12:11
Cの落とし穴にはまるようなヤツでも、C++だと優等生になれるのか？
能力不足を言語のせいにしているんじゃないのか？

C<C++は成り立つのは同意だが、
Cプログラマ<C++プログラマが成り立つと思っている香具師はドアフォ
というか、人間ﾔﾒﾛ
191 ：仕様書無しさん：03/01/31 14:14
>>189 君VB厨でしょ。
3ヶ月前にプログラム板で暴れていたでしょ?
C#とVBを批判するJavaプログラマのレスに
腹をたてていた香具師じゃないの?

少なくとも、Javaできる香具師はC#もできるんでないかい?
192 ：仕様書無しさん：03/01/31 16:43
我々C言語軍は永遠に不滅です
193 ：仕様書無しさん：03/01/31 17:18
そう長嶋はんも言うてはったが、結局引退すんねん。
松井おらんようになって、ナベツネ次第ではどうなるか分からん。

タイガース以外、不滅なんてものはおまへん。よう覚えときや。
194 ：仕様書無しさん：03/01/31 18:27
タイガースって？
ググってみたけど、沢田研二の昔やってたバンドしか出なかった。
195 ：仕様書無しさん：03/01/31 19:49
tiger
scott
196 ：仕様書無しさん：03/01/31 20:09
>>1
多分20年かけても無理
197 ：仕様書無しさん：03/01/31 20:37
>>196が失職するまで無理
198 ：仕様書無しさん：03/01/31 22:36
>>193-194 ﾜﾛﾀ
C言語はいつの間にか巨人軍になっておるのか?
タイガースは何言語や?
199 ：鬱：03/02/01 01:27

未だに COBOLER がはびこっている世の中ですよ？
病原菌は、一度広まると消すのに数十年はかかります。
200 ：仕様書無しさん：03/02/01 02:03
>>198
delphi
201 ：仕様書無しさん：03/02/01 04:15
１は素人
202 ：仕様書無しさん：03/02/01 09:14
まぁ本音を言うと、Cは局所的に使われるだけでいいよ。

今時、Cでごりごり書いてる奴は低レイヤーでコミュニケーションがとれない奴ｊのみ。

そこのお前、当てはまるだろ？
203 ：仕様書無しさん：03/02/01 09:16
【ネットボランティア】余ったＣＰＵを・・・
　cell computingとは、ブロードバンドに接続された家庭内
や企業内のPCの余剰CPUパワーを統合し、
仮想的なスーパーコンピュータとしての利用を実現する
技術を用いたSI、ネットワークサービスです。
　バイオ、物理計算、設計、金融工学、CGレンダリング
などの分野のお客様へ、安価に仮想スーパー
コンピュータパワーを提供することを目的としております。
　なお、将来的には収益にあわせてCPUパワーを提供し
てくださる参加者へポイントシステムやデジタルコンテンツ
による利益還元を考えております。
http://www2.cellcomputing.jp/

２ちゃんねるのチームあります。【挑戦しる】
http://members.cellcomputing.jp/services/teams/team.htm?id=ABBE425B-CE11-4DA4-8591-C68DF67DA41A
204 ：仕様書無しさん：03/02/01 10:14
>>202
じゃあ、毎日本をシコシコ読んでがんばっていた漏れはいったいなんだったのだろう…
205 ：仕様書無しさん：03/02/01 10:14
ところで、カモノハシが卵を産むのは知っているか？
ちょっと気に入った
206 ：仕様書無しさん：03/02/01 13:05
>>204
言語は流行り廃りがあるけど勉強したことが全て無駄になるわけじゃない。ガンガレ

しかし、本は黙々と読むものであってシコシコ読むのはいかがなものか。
207 ：仕様書無しさん：03/02/01 15:26
>>199 　M$がCOBOL.Netなんて余計なもん作ったからな。
M$のせいで病原菌はなかなか死滅しねえや。

>>202
>今時、Cでごりごり書いてる奴は低レイヤーでコミュニケーションがとれない奴ｊのみ。
言いすぎ。

>>204 C++があるだろ。全然役に立っている。
OS作りもCでなければならん
208 ：仕様書無しさん：03/02/01 16:03
C++のほうがいらね
グチャグチャで醜い
Cはシンプルで美しい
209 ：仕様書無しさん：03/02/01 17:58
>>208 それならJavaとPythonとSmallTalkが一番シンプル
210 ：仕様書無しさん：03/02/01 21:33
>>1
いいたいことは分かるが、誰も好き好んでC使ってるわけじゃねえからなぁ。

JavaとC好きな方で開発していいよ？ってなったら普通Javaで
やるだろ。
Cでやらざるを得ないから、、、。


>>1はどうやれば死滅できると思ってるんだ？
211 ：仕様書無しさん：03/02/01 21:35
死滅させるための具体策を述べてくれれば、実行のしようもあるが。

因みにオレには思い浮かびません。時間が立つのを待つしかないのでは。
212 ：仕様書無しさん：03/02/01 21:36
>>210
Java と C のどちらで開発するかは、開発対象によるけど・・・
何も考えないでいきなり Java を選んじゃうんですか？
213 ：仕様書無しさん：03/02/01 21:37
>>211
具体策：画期的な言語を開発し普及させる

具体策を述べたので、実行してください。
214 ：仕様書無しさん：03/02/01 21:39
せめてC言語くらい使えるようになれよ？
JavaやC#なんかと同列に扱ってる時点で既にDQN
215 ：仕様書無しさん：03/02/01 21:40
不況
　↓
技術の進歩が停滞
　↓
ハードのスペックそのまま
　↓
Cなどの厨・高級言語のオーバーヘッドが無視できなくなる
　↓
すべてアセンブラで記述
　↓
C死滅
216 ：仕様書無しさん：03/02/01 21:40
>214 C爺ﾊｯｹｿ
217 ：仕様書無しさん：03/02/01 21:43
なんで勝手にC言語使えないことにするわけ？
自分が使える唯一の言語だから死滅するのが怖いの？
早く他の言語も使えるようになれよ。
218 ：仕様書無しさん：03/02/01 21:45
>>217
214がデンパなのは明らかなのでマジレスしないで下さい。
219 ：仕様書無しさん：03/02/01 21:46
デバイスメーカーはアセンブラなくしては、製品の開発ができないのです。
220 ：仕様書無しさん：03/02/01 21:48
>>219
嘘つくな。
221 ：仕様書無しさん：03/02/01 21:48
>>218
マジレスじゃなくて修正済みコピペだよ。
222 ：仕様書無しさん：03/02/01 21:51
>>221
コピペならコピペってメール欄にでも書いておけ！この糞ボケナスカス野郎！！
223 ：仕様書無しさん：03/02/01 21:52
つか、アセンブラができれば他の言語は何もいらない。
時間だけが必要。
224 ：仕様書無しさん：03/02/01 21:53
>>223
無理｡
規模の問題をどうするんだよ｡いずれどこかで破綻する｡
225 ：仕様書無しさん：03/02/01 21:54
アセンブラができるってのも抽象的だな。
統一された文法があるわけじゃないのに。
226 ：仕様書無しさん：03/02/01 21:54
>>220
Ｃとアセンの違いを言ってみろ。
227 ：仕様書無しさん：03/02/01 21:56
>>224
マクロライブラリを整備すれば無理ではない。規模は関係が無い。
228 ：仕様書無しさん：03/02/01 21:58
フルアセンブリでread.cgiを書き直そうぜ。
229 ：仕様書無しさん：03/02/01 21:58
>>226
それに何の意味がある？
230 ：仕様書無しさん：03/02/01 21:59
>>224
設計次第。
231 ：仕様書無しさん：03/02/01 22:02
>>227, >>230無理｡
原理的には不可能ではないが､
一定の規模を超えると政治的技術的生理的に不可能｡
232 ：仕様書無しさん：03/02/01 22:03
問題は既存のマクロライブラリが無いことだ。
233 ：仕様書無しさん：03/02/01 22:07
>>231
君がソフトウェアにおける「言語」の本質を理解していないという事は良くわかった。
「言語」に依存し過ぎた開発スタイルは身を滅ぼすよ。
234 ：仕様書無しさん：03/02/01 22:07
＞＞２２９
C言語でそのMMX命令を使うためには、
アセンブラでC言語用の命令を作らなければならない。
235 ：仕様書無しさん：03/02/01 22:10
>>233
>規模は関係が無い。
君がソフトウェア開発の本質を理解していないということは良くわかった｡
早く学生気分を捨てないと首切られるよ｡
236 ：仕様書無しさん：03/02/01 22:11
>>234
「デバイスメーカー」って CPU屋の事だったのか。
一口に「デバイス」と言っても範囲が広過ぎるんで、
アセンブラなんか必要無い「デバイス」も有るという意味を込めて、
嘘つくな、と言ったわけだが。
237 ：仕様書無しさん：03/02/01 22:15
>>236
おれは、ＣＰＵのことを言っていたんだよ。
書き方がわるかったな。スマン。
238 ：仕様書無しさん：03/02/01 22:18
>>235
ちょっと待て。そこだけ抽出して揚げ足取られてはかなわん。
規模の問題を持ち出されたら、どんな言語であっても無理な規模というものは
存在するわけで、この議論には「規模は関係無い」と言っている。
239 ：仕様書無しさん：03/02/01 22:22
>>233
　ちみは「プロジェクト管理」の本質を理解していないという事は良くわかった。
　231と「同じ立場」になったら身を滅ぼすよ。
240 ：仕様書無しさん：03/02/01 22:24
>>239
えーと、スレタイと関係無い方向へ向かっているみたいなんすけど。
241 ：仕様書無しさん：03/02/01 22:32
211 ：仕様書無しさん ：03/02/01 21:35
死滅させるための具体策を述べてくれれば、実行のしようもあるが。

因みにオレには思い浮かびません。時間が立つのを待つしかないのでは。


242 ：仕様書無しさん：03/02/01 22:35
>>1
こ・と・わ・る
243 ：仕様書無しさん：03/02/01 22:36
>>242 C爺ﾊｯｹｿ
244 ：仕様書無しさん：03/02/01 22:39
>>1 C言語を死滅させる前に先にマイクソが作ったC#を死滅させようぜ。
245 ：仕様書無しさん：03/02/01 22:43
>>244 既に死滅しますた。
246 ：仕様書無しさん：03/02/01 22:44
>>245
ﾜﾛﾀ
247 ：仕様書無しさん：03/02/01 22:46
>>245 じゃ、次は .NetとVB, VB.Netを死滅させてくれ
248 ：仕様書無しさん：03/02/01 22:52
うんで、最後に残る言語は？
249 ：仕様書無しさん：03/02/01 22:52
英語
250 ：仕様書無しさん：03/02/01 23:01
>>249 いや、エスペラント語
251 ：仕様書無しさん：03/02/01 23:16
Cが無くなったら、制御用の言語何で書くの。
ポインタもあまり使われない世界だからね。

注：組み込みと制御は似て異なる
252 ：仕様書無しさん：03/02/01 23:18
>>251
自社製マクロ。昔は共通言語なんて無かった・・・
253 ：仕様書無しさん：03/02/01 23:26
これからはJavaでしょ
254 ：仕様書無しさん：03/02/01 23:28
>>253
これからってお前・・・
255 ：仕様書無しさん：03/02/01 23:39
>>253-254
ﾜﾛﾀ
256 ：仕様書無しさん：03/02/01 23:41
まぁあれだ、「こわがりすぎー」って奴だな >>1
257 ：仕様書無しさん：03/02/01 23:43
C使うような低レベルな会社はやめて別の会社に移ればいい｡
258 ：仕様書無しさん：03/02/02 00:20
そんなことよりお前ら、C 言語使えるようになっとけ。
危ないぞ。
259 ：仕様書無しさん：03/02/02 00:21
>>257 どの言語使う会社が高レベル?
260 ：仕様書無しさん：03/02/02 00:37
>>259
みかか
261 ：仕様書無しさん：03/02/02 00:46
>>260 そんな言語シラネ
262 ：仕様書無しさん：03/02/02 01:00
>>1
無理。
どんな世代でも、
アセンブラ→Ｃ→他の高級言語
の流れで開発されるからね。
263 ：仕様書無しさん：03/02/02 01:15
>>262 そんなもんだな。
C言語死滅させたがっているVB厨、死者ﾌﾟﾁｭは顔を洗って出直してもらわないとな。
264 ：仕様書無しさん：03/02/02 02:55
>>261
白根って誰ですか？
265 ：仕様書無しさん：03/02/02 04:11
>>264
しらね
266 ：仕様書無しさん：03/02/02 11:48
コボラーは仲間に入れてもらえないのですか？
267 ：仕様書無しさん：03/02/02 12:07
>>266
あれはわざわざ手を下さなくても、ほっとけば死ぬでしょ。
268 ：260：03/02/02 12:17
>>264-265 ﾜﾛﾀ
269 ：仕様書無しさん：03/02/02 12:18
>>268 いや>>260ではなく>>261だった
CよりVB使ってる会社のほうがレベル低いんです
270 ：ｺﾞﾙｧ：03/02/02 13:53
PGになるためにはCのマスターが必須にならねばならない。
C知らずしてプログラミング語ることなかれ！
なんだ？このスレは。
271 ：仕様書無しさん：03/02/02 13:59
>>270 愚かなM$に毒された愚かなブビ厨死者ﾌﾟﾁｭ(C#厨)がたてたスレじゃないかね?
272 ：仕様書無しさん：03/02/02 14:00
毎日本をシコシコ読んでがんばっていた204の未来を考えるスレ
273 ：仕様書無しさん：03/02/02 20:43
M$に泣きつくVBやC#しかできないヴァカどもにはC言語を死滅させることすらできん
274 ：仕様書無しさん：03/02/02 20:56
近い将来C言語は
ながーく何故効くの？くしゃみと鼻水に〜♪
赤と白のつぶつぶ入ってるからやないの！♪
ﾌｯﾌｯﾌｯ…
に滅ぼされるだろう。
275 ：仕様書無しさん：03/02/02 20:59
C言語を滅ぼすにはC#も滅ぼさなければならない。
なぜなら、C#にunsafeがあるからだ。
276 ：仕様書無しさん：03/02/02 21:05
C++あるからCいらなーい。ばいばいきーん。
277 ：仕様書無しさん：03/02/02 21:12
>>276 内部でC使っているから
あなたはＣを必然的に必要としているのです。

ＵｎｉｘにもCが使われています。
オープンソースとなって公開されているものもあります。
Cを死滅させるにはこれらをすべて焼却し、
闇の彼方に放り出さなければなりません。

それは法的にも物理的にも不可能です。
可能だとしたら、C言語の知識を持つ人類を滅ぼすしかないでしょう。

しかしそれは犯罪です。

C言語を死滅させると言う行為は、あなたの体の成分である
炭素原子Cを死滅させろといっているようなものです。
炭素原子Cは人間、いや、生命の活動には無くてはならない必要不可欠なモノです。
よってCを死滅させることは不可能です。
278 ：仕様書無しさん：03/02/02 21:17
>>275
unsafe は使い勝手が悪すぎで使い物にならん。
279 ：仕様書無しさん：03/02/02 21:20
>>275
意味わからん。おばかですか？
C#にunsafeあったほうがC言語滅びやすいじゃん。
280 ：仕様書無しさん：03/02/02 21:27
>>279 あなたがおばかですか?
C#でunsafeが使われるということは
C言語が使われていると言うことだ。
unsafeによってC言語が使われていると言うことはC言語が死滅しないと言うことだ。
死者ﾌﾟﾁｭがunsafeを使えば使うほどC言語は死滅しなくなる。
281 ：仕様書無しさん：03/02/02 21:30
そうか！すべての言語はCによって実装されていたのか！
知らなかった。
282 ：仕様書無しさん：03/02/02 21:36
>>281 あなたの妄想です。
あなたの論理によれば、日本語もCによって実装されているのですか?
283 ：仕様書無しさん：03/02/02 22:23
よーするに低レベルレイヤー記述可能な言語で、
Cよりまともな文法を持ったやつが普及すればいいわけだが…今更無理っぽい
284 ：仕様書無しさん：03/02/02 22:46
どちらにせよ、C言語はOS・VM作成用言語に成り下がるわけだが。
285 ：仕様書無しさん：03/02/02 22:49
>>1
同意
286 ：仕様書無しさん：03/02/02 22:54
>>284
昔はアセンブラも一般アプリ作成に使っていたことを知っているか？
それが今や・・・。Cも同じ道をたどるのであろう。
287 ：仕様書無しさん：03/02/02 22:57
ぶっちゃけ名前が「C'」みたいにならなけりゃどうでもいいかも。
288 ：仕様書無しさん：03/02/02 23:04
プログラマーの生き場所はどこへ？
289 ：仕様書無しさん：03/02/02 23:05
まっ、ただの一言語に固執している奴はプログラマじゃないな。
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

何度も確認しましたが間違いはないはずなのこうなってしまいます。どうすればいいですか？
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 ははは、マジレス禁止でお願いします
295 ：290：03/02/02 23:21
続きはこちらでお願いします（ｗ
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
おまえのは日本語さえもスパゲッティだな。
324 ：322：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
>>361
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に溜め込め
371 ：370：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

１．仕事が減ってるJava厨の白昼夢スレです。
２．Cができないリアル厨もいます。
３．知ったかぶりﾌﾞﾋﾞ厨もいます。
４．ﾌﾟｯってこのスレを見てるまともな人は思ってます。
５．C・C++もJAVAも自称厨の中で本当に使えるヤシは１割くらいです。


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

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

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

結論として今の日本には　アントニオ　猪木　の張り手が必要という事だ。
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
言語の王者はＶＢ、殆どの企業基幹システムはＶＢで
組まれているようです。
付属のシステムがＣ＋＋、ＪＡＶＡ
どう、違う？
386 ：仕様書無しさん：03/02/12 21:58
>>385 はいつまらない釣りね。
VB厨を慰めるだけだね。
387 ：仕様書無しさん：03/02/12 22:03
>>385
禿同！！ＶＢは神！！
きっと、みずほの悲劇はＶＢによって引き起こされたんだね。
スペースシャトルのウワサの温度センサーも、ＶＢのランタイムエラーかもよ！
次期WindowsのAPIはVBで記述されるらしいね。すごいね、VB！！

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

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

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

あと誤字訂正。
>あと、同僚に貸したままの「Java謎」本をなんと返してもらいます（ｗ
あと、同僚に貸したままの「Java謎」本をなんとか返してもらいます（ｗ
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
たしかに、ＶＢよりＣ＋＋のほうがすぐるているだろう。
でも、企業で使う基幹システムはＶＢになっちゃんだよね。
本当はＣ＋＋で組んだほうがいいのだがＰＧの能力がないため
安全なＶＢに走ってしまう。
405 ：t：03/02/13 06:47
http://bbs.1oku.com/bbs/bbs.phtml?id=kkgogo
406 ：仕様書無しさん：03/02/13 07:42
>>403
VBを貶す理由としてはもっともアホで理不尽で筋違いなもの
の一つだと思うがな。
他に貶すところはいくらでもあるだろうに...(w

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

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

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

馬鹿でも使える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が出来ちゃったりしちゃうような某言語はいかがでしょうか。
419 ：525：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#は成熟するのにあと１・２年はかかるだろう｡
436 ：仕様書無しさん：03/02/14 01:59
>>435
ＶＢがアップデートされるたびに泣いた者もいるくらいだ。
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が好き。
450 ：名無しさん＠お腹いっぱい。：03/02/15 08:51
C/C++/MFC/VBX/Java2/C#極めたくらいで世界見た気になってんじゃﾈｰﾖ

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

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

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

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

そんな訳で・・・・・・・・・・・・・「やっぱＣ言語最高！」←99岡村 風
453 ：名無しさん＠お腹いっぱい。：03/02/15 09:09
エコロジー言語 C

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

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

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

マ板を見ていると。
456 ：440：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
ＶＢ房ですが
Ｃ＋＋じゃ出来ないことって何？
463 ：仕様書無しさん：03/02/15 20:11
何と比べてるの？VB？
464 ：仕様書無しさん：03/02/15 20:16
ＶＢとＣ＋＋です。
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
おまいら　うるせぇんだ。

Ｃ　は　神

以上
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プログラミング技術を手に入れたオレ。
そして現在Ｃ＃で開発していてふと思うこと・・・・・今までの苦労はなんだったんだ(藁
490 ：仕様書無しさん：03/02/20 15:21
>>489
それは、ちゃんと苦労してプログラミングの勉強してないからだろう。
491 ：仕様書無しさん：03/02/20 15:27
>>489
漏れも似たようなもの（嘘）だが、それでもC++は好きだ。
やっぱり、やろうと思えば何でも出来るところがいい。

ちなみに、単なるCは死滅してもいいや。
492 ：U ◆CZtFsGiu0c ：03/02/20 15:30
>>485
「CORBAマッピングまで」って、最初のCORBA仕様ではSmalltalkとCの
マッピングしかなかったわけだが。
493 ：452：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
Ｃが死滅するこたぁないだろ。
超高速化ルーチンの作成にはＣ＋＋よりＣの方がはるかに適しているんだから。
「今日の性能には高速化ルーチンなんか必要ない」とか言ってるﾔｼは
現実を知らないんだよ。
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人気の引き金となったFF７のように。
515 ：山崎渉：
━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―