C言語を完全に駆逐するためには

C言語を完全に駆逐するためには at TECH

1:デフォルトの名無しさん
08/05/07 20:11:42
どうすればいい？

2:デフォルトの名無しさん
08/05/07 20:13:02
クソすれ立てる人間を完全に駆逐するためには

どうすればいい？

3:デフォルトの名無しさん
08/05/07 20:17:12
駆逐する意図が分からん

4:デフォルトの名無しさん
08/05/07 20:30:05
C言語は生産性低い。
コーディングしててイライラする。
もうC言語はうんざりだ。
しかしパフォーマンスやらなんやらの点からC言語を選ばざるを得ないこともある。

C言語より全ての面で優れた言語があればもうCをやらなくていいよね？
「～だからC言語で開発しよう。」という理由をこの世からひとつ残らず消したい。

5:デフォルトの名無しさん
08/05/07 20:42:07
そんなキミにD

6:デフォルトの名無しさん
08/05/07 20:43:26
>>4
で、なぜはほんとう？

7:デフォルトの名無しさん
08/05/07 21:11:28
言語厨召喚スレ

8:デフォルトの名無しさん
08/05/07 21:37:00
Cのパフォーマンス、スクリプト言語並のゆるい型付け、
Smalltalkから受け継いだオブジェクト指向、
そう、つまりObjective-Cの出番だな。

自分で言っときながら、これはねーよｗ

9:デフォルトの名無しさん
08/05/07 21:41:29
MISRAやら、あの系統のコーディング規約とかを目にすることがあるけど、
あそこまでガチガチにするなら、素直にPascalつかっとけよって感じだけど。

10:デフォルトの名無しさん
08/05/07 21:50:45
C++はCを（完全には）駆逐することは出来なかった。
なぜ？

11:デフォルトの名無しさん
08/05/07 22:09:35
慣れてるから。実績があるから。
切替えによる不具合がないといいきれないから。
教育コストがかかるから。機能的に必要ないから。

12:デフォルトの名無しさん
08/05/07 22:14:30
そりゃ、ハードウェアをある程度仮想化できて、汎用性と生産性が高い
アセンブラが登場してくれば……たぶんCとほとんど同じようなものに
なるだけだな、きっと。

13:デフォルトの名無しさん
08/05/07 22:20:38
>>10
MFCとシステムハンガリアンのせいだったりして

14:デフォルトの名無しさん
08/05/07 22:31:59
みんなに聞きたいんだが、みんなの意見はどれに近い？

１．C言語はクソ。早く完全に駆逐したい。
２．C言語はクソだけど、必要。今後も使われるのはしょうがない。
３．C言語はC言語でいいところもある。
４．C言語こそ最強。むしろ他の言語イラネ。

場合によって言語を使い分けすりゃいいだろ。というのは却下。

15:デフォルトの名無しさん
08/05/07 22:52:37
>>14
２
古臭さを感じるけど、メジャーな代替言語が無いからなぁ
あんまり言うと言語厨が沸くから、この辺で

16:デフォルトの名無しさん
08/05/07 23:02:04
>>14
2
環境制限なしでC++ or CならC++を取りたいな。
たぶん組み込みやってるから若干3よりではある。

17:デフォルトの名無しさん
08/05/08 00:22:35
>>10
STLでprintfのような書き方できないから

18:デフォルトの名無しさん
08/05/08 00:29:53
>>10
C++はC++で問題が多いからな
むしろC++は駆逐される側にまわってしまった感がある

19:デフォルトの名無しさん
08/05/08 06:29:39
>>14
1
「ランタイムサポート(GCとか)を必要としない」「メモリに直接アクセスできる」
「アセンブリコードを埋め込める」「動的メモリ確保に依存しない」という特徴のある、
もうすこしマシな言語が欲しい

20:デフォルトの名無しさん
08/05/08 11:19:14
まあ同意なんだけど、それってどれも欠点の裏返しとして槍玉に上がる利点なんだよな
なんか止揚っつーか、パラダイムシフトが欲しい所なのかもね

21:デフォルトの名無しさん
08/05/08 11:51:05
他にCの代替になる優良な言語があるならともかく、
無い現状で駆逐しようとか気勢上げてもしょうがないだろう。
順番が逆。

22:デフォルトの名無しさん
08/05/08 13:49:11
>>21
Javaとか言い出す奴が出そうだなｗ

23:デフォルトの名無しさん
08/05/08 14:00:28
Cと全く同じことがCが動く全プラットフォームでできて
なおかつ機能が少なくとも同等でパフォーマンスが少なくとも同等な言語があれば
Cは一気に駆逐されると思うぜ

Cは使われるべくして使われている言語だ
Cの代替がない限り、Cは死なないし死ねない

24:デフォルトの名無しさん
08/05/08 14:59:03
それってただのまがいもの

皮肉的につっぱしるなら「少なくともCと同等以上の歴史と運用実績を持ち」も追加してほしす

25:デフォルトの名無しさん
08/05/08 18:33:49
C+CoreFoundation
C+GObject

みたいなので我慢出来ない?

26:デフォルトの名無しさん
08/05/08 18:48:41
>>21
だからCの代替になる言語を作ろう(あるいは見つけてこよう)という話じゃないの？

27:デフォルトの名無しさん
08/05/08 20:03:31
>>8
Apple信者の俺でもそれはねーよｗ

28:デフォルトの名無しさん
08/05/08 20:41:35
ハードウェアが根本から変わったらCは駆逐される。
ハードウェアがノイマン型のうちはCは無くならんよ。

29:デフォルトの名無しさん
08/05/08 21:51:45
Cには標準で動的にサイズが変わるコレクションが無いっていうのがいや。

30:デフォルトの名無しさん
08/05/08 22:05:50
でも、それで充分な内容もたくさんあるってことだね。

31:デフォルトの名無しさん
08/05/08 22:45:42
>>26
結局Cみたいなもんしかできあがらんだろうなってのが
大方の意見だと思われ。

32:デフォルトの名無しさん
08/05/09 01:53:40
OSでUNIX(POSIX)的なものを完全に駆逐できれば可能かもね

33:デフォルトの名無しさん
08/05/09 02:30:25
Inferno を思い出した

34:デフォルトの名無しさん
08/05/09 03:21:42
>>29
裏で勝手にメモリ取らないというのがCのポリシーだろ。
その意味でstrdupは異端。

35:デフォルトの名無しさん
08/05/09 03:52:58
>>34
>Cのポリシー

初めて知った。どこかに明文化されてる物なの？

36:デフォルトの名無しさん
08/05/09 09:17:04
俺解釈だろ

37:デフォルトの名無しさん
08/05/09 12:37:27
>>32
Unixと共に産まれUnixと共に滅ぶのならCも本望だろう。
どっちも死にそうに無いけど。

38:デフォルトの名無しさん
08/05/09 17:20:01
ハード寄りな言語がCしか無いのってのが現状。
カーネルやデバイスドライバとかいじろうとするとCしか選択肢がないんだよ。

39:デフォルトの名無しさん
08/05/09 17:31:17
tomoyo Linux最高

40:デフォルトの名無しさん
08/05/09 19:19:10
Cの文法上の不満点は？

41:デフォルトの名無しさん
08/05/09 19:47:02
そういうレベルじゃないだろ

42:デフォルトの名無しさん
08/05/09 19:56:30
>>40
宣言の文法は、異常。
もっとスッキリできなかったのか？

43:デフォルトの名無しさん
08/05/09 20:22:02
Cはタイプ量が多くなる。
他の先進的な言語と比べて１０倍くらいタイプが必要だろ。

44:デフォルトの名無しさん
08/05/09 20:26:39
それはGUIみたいな無駄かつ無意味な処理を書くから。

45:デフォルトの名無しさん
08/05/09 20:29:29
C++はC+程度に留めておけばCに止めを刺せたかもしれないのにな。
ちょっと欲張りすぎたね。

46:デフォルトの名無しさん
08/05/09 20:39:26
Cの宣言の文法は一貫性があって良いと思うんだけど、なかなか賛同が得られない

47:デフォルトの名無しさん
08/05/09 20:55:38
文法にすら不満が無いのならなんで駆逐させたいんだ

48:デフォルトの名無しさん
08/05/09 21:52:40
クラスが無いのが不満。
CでOOぽくコーディングするとキモくなる。

49:デフォルトの名無しさん
08/05/09 21:59:45
>>48
いやそれCの不満点として挙げる必要ないだろｗ
ま、C++使っちゃいけない場合が多すぎるのもあるけど

50:デフォルトの名無しさん
08/05/09 22:01:40
関数プログラミングができないのが不満

51:デフォルトの名無しさん
08/05/09 22:17:26
今時、クロージャもジェネレータもリストの内包表記もパターンマッチも型推論も
総称関数もイテレータもクラスもインターフェイスも継承も遅延評価も参照透明性も
名前空間もモジュールシステムも高階関数もガベージコレクションも例外機構も、
その他色んな物が入っていないのが不満。

という事は無いな（まあ正直な所、少しはあるけど）。

Cが良いのは慎み深い所。21世紀になってもオブジェクト指向の追加すらされてない
だなんて何と禁欲的で信頼に値する事か。あと92年くらいは使われ続けるんじゃない
だろうか。

52:デフォルトの名無しさん
08/05/09 22:23:45
GCは要らない。GCなんか入れたらC言語の利点が失なわれてしまう
代数的データ型とか、制限付きの無名関数とか、強力なマクロとか、パターンマッチとか、
そういうこまごましたものが欲しい

53:デフォルトの名無しさん
08/05/09 22:28:22
オブジェクトシステムを入れるなら単一継承にして欲しいし、そうなるだろうな

54:デフォルトの名無しさん
08/05/09 22:30:48
Cのリプレースを目指すわけじゃなく単純に哲学を受け継いだ正常進化系の言語ってありそうなもんだけど
結局メジャーになるようなものは出てきてないな。

55:デフォルトの名無しさん
08/05/09 22:31:03
そんな難しい機能入れたって、C厨に使えるわけないだろ。

56:デフォルトの名無しさん
08/05/09 22:38:40
1980～1990年頃まではfortranとcobolは駆逐されない。とみんなが考えていた。
まあ「駆逐」という言葉の定義に依存する話だ。
この頃から現在に至るまでのコンピューティングの変化を書ききることは出来ないけれど。
まあ「同程度の変化が起これば主流言語の交代が起こるのではないか」と愚考する。
あるいは現在と同様の状態が長い間、続くのかもね。

57:デフォルトの名無しさん
08/05/09 22:39:29
今の時代にCだけしか使っていない人間が生き残っているとも考えづらいし、
高級言語はそれなりに触っている事だろう。

58:デフォルトの名無しさん
08/05/09 22:42:31
>>57
入社してCの部署に配属されて、Cしか触ったことないってやつとかいっぱいいそうだけど。

59:デフォルトの名無しさん
08/05/09 22:47:50
ハード寄りの組み込みの人たちとかUNIX系OSのカーネル開発者系の人達とかはたとえ
先進的言語について精通していたとしても自分の仕事ではCを使う、みたいな感じで
生き残り続けるんじゃない？

60:デフォルトの名無しさん
08/05/09 22:52:19
>>58
うちの会社では見た事無いな。Javaの研修がほぼ必須になってるし。
組み込み機器メーカーのソフト開発部門とかだとC専業部隊があるのかな。

61:デフォルトの名無しさん
08/05/09 23:06:24
>>56
コボルはまだまだ残る
なぜか残る

62:デフォルトの名無しさん
08/05/09 23:46:18
>>48
そこでObjective-Cですよ！
…ごめん俺もなんか無理>>8

しかし何でObjective-Cは微妙に思えるのかねぇ。

63:デフォルトの名無しさん
08/05/09 23:58:47
C言語と一緒にCシェルも駆逐してくれ。

64:デフォルトの名無しさん
08/05/10 00:02:17
むしろBシェルがイヤっす
あーいう曖昧なのを許容するなんて出来ない
あれがデフォなせいでLinuxやら使いたくない

65:デフォルトの名無しさん
08/05/10 00:19:13
何か曖昧だったっけ？

66:デフォルトの名無しさん
08/05/10 00:24:05
>>54
結局のところノイマン型コンピュータ言語の根本的な変革って二つしか無い。
一つは構造化で一つはオブジェクト指向。
Cが進化するとしたらオブジェクト指向を取り入れるくらいなもので、実際
そのように進化してると思うが。

67:デフォルトの名無しさん
08/05/10 01:46:46
わざわざノイマン型コンピュータと明言する必要でもあるのか？

68:デフォルトの名無しさん
08/05/10 06:08:06
まぁ、出世してエラくなれば、言語使ってPGなんてしなくなるから、
どうでもよくなるよ。

69:デフォルトの名無しさん
08/05/10 06:55:54
仮面ライダーBLACKが一度死んでRXとして復活したように
Javaも一度死ぬべきだ
そして真の神仕様の言語として復活すべし

70:デフォルトの名無しさん
08/05/10 07:10:58
逆だな、Javaはもっとカオスになってくれないと
リファクタリングしたときの効果が薄くていかん。
D言語みたいに中途半端になってしまう。

71:デフォルトの名無しさん
08/05/10 08:08:13
>>1
先ずは、KernelとコンパイラをC以外で書いてみれば？

72:デフォルトの名無しさん
08/05/10 08:31:08
javaとC#とあとはオブジェクト指向スクリプト言語しか使ったこと無い俺に
C++がCより劣ってる点を教えてくれ。

73:デフォルトの名無しさん
08/05/10 08:56:37
カーネルはともかく、コンパイラをCでかく必要って本当にあるのか？
入力はただの文字列だし、出力だってただの文字列だろ。
直接ハードを叩くわけでも無し。
ていうかコンパイラこそ、リッチな機能をもった高級言語で書くべきなんじゃ。
でも世の中のコンパイラは大抵Cで書かれてるんだっけ？

74:デフォルトの名無しさん
08/05/10 09:03:16
>>73
しょうもない質問で申し訳ない。

コンパイラの出力って文字列なの？バイナリも文字列の一種？

75:デフォルトの名無しさん
08/05/10 09:04:31
>>72
斜め上の機能を使いにくい
GCはまあ使えるがcall/ccとか無理ぽ

76:デフォルトの名無しさん
08/05/10 09:06:03
>>72
すぐにコンパイル・リンクにめちゃくちゃ時間がかかるようになること。

77:デフォルトの名無しさん
08/05/10 09:06:31
>>74
しっ！そこ突っ込んじゃ可哀想！

78:デフォルトの名無しさん
08/05/10 09:12:02
俺の理解ではコンパイラはアセンブラを吐いて
アセンブラがバイナリを吐くということになっている。
アセンブラまで含めてのコンパイラというなら
コンパイラの出力はバイナリ。

79:デフォルトの名無しさん
08/05/10 09:15:44
>>66
オブジェクト指向っていうのは、構造化の延長線上じゃないの?

80:デフォルトの名無しさん
08/05/10 09:19:17
>>73
そこらへんの高級言語よりは速いコードを生み出すと信じられているから。

81:デフォルトの名無しさん
08/05/10 09:29:21
URLﾘﾝｸ(shootout.alioth.debian.org)

Cは全てにおいて最速ではないが、かなりの範囲で最速になるな。
機械語に近くて、コンパイラ屋にも人気のある言語なだけに。

82:デフォルトの名無しさん
08/05/10 10:33:28
>>79
C++とかJavaとかCの延長線上の言語でオブジェクト指向を見ると
そう見えるかもしれんね

83:デフォルトの名無しさん
08/05/10 11:24:39
>>72
バイナリがやたらでかくなる
ネームマングリングの所為でシンボルダンプやスタックトレースが読み辛い

84:デフォルトの名無しさん
08/05/10 12:26:13
>>72
技量の低い私にはコンパイラの出力がどーなっているか C は分かっても C++ はわからない。
私のような技量の低いプログラマーを駆逐する方が本来の目的に近づけるのかも。

85:デフォルトの名無しさん
08/05/10 12:31:12
>>78
では、「んなもん実装次第」だということを理解しましょう。

86:デフォルトの名無しさん
08/05/10 17:08:29
(1)多くのOSがC言語の関数群として表現されている
(2)他言語のコンパイラも多くはC言語で書かれている。
(3)(1,2)を他言語に換装する作業が面倒＆標準言語が未定。

個人的にはObjective-Cに興味があります。
(コイツは言語の名称で損していないだろうか？)

87:デフォルトの名無しさん
08/05/10 17:22:33
Objective-CってMac専用だろ
その時点でCにとって代わるのは無理

88:デフォルトの名無しさん
08/05/10 18:46:40
>>73
そりゃ自分の言語がいろんなプラットフォームで動くようにしたいからでしょ。
だから言語は C でかくか、JavaVM で動かすかのどっちか。
変態系は lisp で書いたりするけど。

89:デフォルトの名無しさん
08/05/10 19:10:35
>>87
専用って訳じゃないと思う、、(^^;
URLﾘﾝｸ(wwwa.dcns.ne.jp)

無理なのには同意。objcいいとは思うんだけどね、、

90:デフォルトの名無しさん
08/05/10 22:28:04
そんなん過渡期にこういうのありましたよ、って紹介でしか知りません

91:デフォルトの名無しさん
08/05/10 23:40:28
>>86
>　(1)多くのOSがC言語の関数群として表現されている　

これは別にどうでもいい要素じゃん。
PascalとかVBからでもAPI呼び出したりできてるし。

92:デフォルトの名無しさん
08/05/10 23:50:51
Objective-CってMac専用ってイメージなのか。
俺はずっとNext専用ってイメージしかなかったから、ちょっとびっくり。

93:デフォルトの名無しさん
08/05/11 05:42:43
Objective-Cは取り敢えず[]で括るのがキモイ

94:デフォルトの名無しさん
08/05/11 11:19:20
C++でガベージコレクション使わんのがある程度Cの代用に
なるんじゃないのか

95:デフォルトの名無しさん
08/05/11 11:49:29
最近はC++の記法の方がキモく感じられるようになった。
Objective-Cはかなり良いのだけど、これ以上広がることはないだろうな、まったく残念ながら。

96:デフォルトの名無しさん
08/05/11 12:05:21
ちょっと興味はあるんだが検索してもサンプルコードらしきコードが全然出てこないな

97:デフォルトの名無しさん
08/05/11 12:16:54
オブジェクト指向言語の比較
URLﾘﾝｸ(hmdt.jp)

ちょっと興味深かった。

98:デフォルトの名無しさん
08/05/11 12:53:49
>>86
2 は重要かな?
Lisp のコンパイラは大抵 Lisp 自身で書かれているし、
確認していないけど javac は C++ で書かれてるよね?
その他、JavaScript のコンパイラは Java, OCaml, SML,
JavaScript, C++, etc. で書かれた実装があったと思う。

99:デフォルトの名無しさん
08/05/11 14:26:14
最初のC++コンパイラはCで書くしかないからな
そのコードを捨ててC++で書き直す意味が分からん

100:デフォルトの名無しさん
08/05/11 14:35:38
>>99
>最初のC++コンパイラはCで書くしかないからな

cfront は C++ で書かれていたらしいが?

101:デフォルトの名無しさん
08/05/11 14:53:21
それどうやってコンパイルしたんだろ
手か
俺は絶対に嫌だが

102:デフォルトの名無しさん
08/05/11 14:55:07
つ　bootstrap

103:デフォルトの名無しさん
08/05/11 15:00:24
我々はもう既にオブジェクト指向から拡張した新たなるパラダイムに接している。

ただ気付いていないだけだ。

Extension Method や Generic を見ているとわかる。

継承と多態では表現できない世界に入り込んでしまっている。

皆さん、新たなるパラダイムにようこそ。

104:デフォルトの名無しさん
08/05/11 15:09:09
ここだけ 1990 年代のスレですか?

105:デフォルトの名無しさん
08/05/11 15:36:58
JavaChip上でJavaOSが動けばCも捨てられるんだろうけどね

でも結局、最後はマシン語の世界に降りていかないといけないだろうし
そうなったら最後は高級アセンブラであるところのCに頼らざるをえない。

106:デフォルトの名無しさん
08/05/11 15:38:52
だからもっとまともな高級アセンブラが欲しいって話じゃないのか

107:デフォルトの名無しさん
08/05/11 15:51:51
D言語があるじゃまいか！

108:デフォルトの名無しさん
08/05/11 16:08:58
皆に黙殺されるD言語

109:デフォルトの名無しさん
08/05/11 18:50:50
真のオブジェクト指向言語はLOGO

110:デフォルトの名無しさん
08/05/11 21:40:39
Objective-D++が有れば最強……かも。

111:デフォルトの名無しさん
08/05/11 23:01:18
>99
最初のC++の実装は、確かCへのトランスレータじゃなかったっけかな。
国内でもPC向けのC++実装はトランスレータの時代があった。MIWA C++とかさ。

112:デフォルトの名無しさん
08/05/11 23:15:47
C++は生れた時から今までずっと、C with class だろ？
CとC++で、OOなコードを書こうとする時、コード量が増える以外の
違いってあるのかな？

113:デフォルトの名無しさん
08/05/12 00:11:27
>>99-101
「最初のC++コンパイラはC with Classesで書かれた」が答えというオチ？

114:デフォルトの名無しさん
08/05/12 12:10:39
Zortech C++ のバージョン1使ってたぞ。Cへのトランスレータだった
ちなみに作者はWalter Bright
Dの作者でもある

115:デフォルトの名無しさん
08/05/12 13:35:53
Zortech C++は最初からトランスレータじゃなくてnative compilerだったと
思うけど。PC向けに国内で初めて手に入ったnative compilerってことで俺も
買って、そして余りのバギーさに枕を濡らした記憶がある。

116:デフォルトの名無しさん
08/05/12 22:34:49
仮想関数があるとパフォーマンス落ちるから継承がある言語はCの代わりにはなれないな。

117:デフォルトの名無しさん
08/05/12 22:45:17
パフォーマンス(笑)

118:デフォルトの名無しさん
08/05/12 22:47:50
あんたの笑いのツボはよく分からんな

119:デフォルトの名無しさん
08/05/12 22:50:04
エンドユーズに限りなく近いデベロッパならC++/C#/Javaで十分ですよ。
Java7はビデオデコード機能がFlashやSilverlightに追いつくらしくて期待してる。
後はゲーム系インタフェースさえ標準化されればJavaだけでいいのに。

120:デフォルトの名無しさん
08/05/12 22:54:48
Java(笑)

121:デフォルトの名無しさん
08/05/12 23:16:42
継承無しのクラスに価値はあるのか？

122:デフォルトの名無しさん
08/05/12 23:18:04
継承はクズ。これからは委譲。

123:デフォルトの名無しさん
08/05/12 23:19:55
オブジェクト指向を根本から否定かよ。

124:デフォルトの名無しさん
08/05/12 23:35:13
>>120
C言語（笑）

お前のやってる手法は根拠レスでチープな行為だ。

125:デフォルトの名無しさん
08/05/12 23:35:35
なぜ継承がクズかkwsk

126:デフォルトの名無しさん
08/05/12 23:40:23
>>123
delegationも立派なオブジェクト指向の手法。継承だけがOOPLじゃないのよ。
>>125
オブジェクトの関係を固定してしまうから変化に弱い。

127:デフォルトの名無しさん
08/05/12 23:42:18
>>126
初心者の俺でも分かるようにもっとｋｗｓｋ

128:デフォルトの名無しさん
08/05/12 23:52:28
仮想関数は実行時に差し替えることができない。だから継承しまくる
デリゲートはそれができる。だから継承いらない

129:デフォルトの名無しさん
08/05/13 00:19:14
処理の委譲とインタフェースの実装はまるで別な機能だろ。
ストリーム関係が継承を必要とする最もたる例だと思うが。

130:デフォルトの名無しさん
08/05/13 00:22:48
CとC++/C#/Javaなんて唯の兄弟喧嘩だろ
しかも偉大な兄(C)を越えられない
Cを駆逐するなら、全く別のアプローチしか無い

131:デフォルトの名無しさん
08/05/13 00:26:02
超えようと機能を追加していったのがC++で、別のアプローチのつもりが
気がついたらナナメ上だったのがJAVAだと。

132:デフォルトの名無しさん
08/05/13 00:28:09
C言語なんてハードウェアよりじゃないかぎり使う方が馬鹿だと思うが。

133:デフォルトの名無しさん
08/05/13 00:30:32
つまり Apache はハードウェアよりと…

134:デフォルトの名無しさん
08/05/13 00:33:34
ハードウェア寄りじゃ無い場面で、Cの幻影を引き摺ってる言語を使ってる
時点でダメだよな。

135:デフォルトの名無しさん
08/05/13 00:35:09
世間はそう思ってないみたいだが、どうなのよ？

136:デフォルトの名無しさん
08/05/13 00:37:24
ちなみに Perl も Python も Ruby も SpiderMonkey も Tcl/Tk も C だよね

137:デフォルトの名無しさん
08/05/13 00:40:26
フリーの言語処理系だけ並べられても

138:デフォルトの名無しさん
08/05/13 00:40:42
>>134
Java が出なければ SML が主役になる筈だったと言ってる人が居たけど…

139:デフォルトの名無しさん
08/05/13 00:43:22
>>137
ハードウェアよりじゃない所で、実装言語を確認出来る良い例だから。

140:デフォルトの名無しさん
08/05/13 00:46:04
STLが無いってだけでC言語は糞だろ。
生産性の無い言語は現場から去るべき。

141:デフォルトの名無しさん
08/05/13 00:47:31
マルチプラットフォームでパフォーマンスが求められるとどうしてもCになるねえ

しかし、それこそC言語のほうこそ、「FORTRANとCOBOLを完全に駆逐するためには」
とか日頃思ってるんじゃないかな。コンピュータの世界ではCはそんなに独占してる
わけじゃないから

142:デフォルトの名無しさん
08/05/13 00:47:33
C++が糞じゃなかったらとっくに現場から去ってるって

143:デフォルトの名無しさん
08/05/13 00:48:26
PerlとTclはちょっと違うな。
Cも含めた闇鍋風バカ言語。もちろん良い意味で。

144:デフォルトの名無しさん
08/05/13 00:58:21
STLが無いと生産性の上らない>>140は現場から・・・

145:デフォルトの名無しさん
08/05/13 01:00:52
>>144の苦しい言い訳とか、Cが如何に使えないかよくわかる。

146:デフォルトの名無しさん
08/05/13 01:01:11
STLなめんな。

147:デフォルトの名無しさん
08/05/13 01:03:09
未だにテンプレート禁止のところもあるというのに

148:デフォルトの名無しさん
08/05/13 01:03:22
ちょ、子供の喧嘩は勘弁な

149:デフォルトの名無しさん
08/05/13 01:13:09
>>141
今やCの守備範囲とFortran,COBOLが生き残ってるところは、ほとんど被ってないからなぁ
Fortanを駆逐するのは(可能がどうか別にして)Camlでいいと思うが、COBOLは何だろう？

150:デフォルトの名無しさん
08/05/13 01:13:27
つーかこの急激なスレの伸びはなんなのよｗ

151:デフォルトの名無しさん
08/05/13 01:18:03
コレクションもなく文字列操作も冗長で正規表現も標準で無いとかふざけすぎ。
エラートラップをするにしてもエラーコードびっしりで冗長極まりない。
例外を使わせろよ。C++みたいにfinallyの無いなんちゃって仕様じゃない奴。

152:デフォルトの名無しさん
08/05/13 01:29:53
そこで組み込みスクリプト言語ですよ

153:デフォルトの名無しさん
08/05/13 02:02:19
>>151
finallyも使いやすいとは思えないけどな。
C#のusingとかDのscopeとかみたいな仕組みくらいのほうがいい。
C++デストラクタもまああり。

154:デフォルトの名無しさん
08/05/13 05:06:38
C++はネイチブ生成の宿命があるのに
その場合エラー専用処理がものすごく非効率って問題が

155:デフォルトの名無しさん
08/05/14 09:01:09
>>153
んなもんケースによるだろ。
ケースによるのにfinallyがないのが糞なんだよ。

156:デフォルトの名無しさん
08/05/14 09:42:43
finally相当の機能なら、C++/CLIでついたんじゃなかったっけ?

157:デフォルトの名無しさん
08/05/14 10:34:32
まるでC++/CLIがC++の後継みたいな言い方だな

158:デフォルトの名無しさん
08/05/14 13:30:06
C++/CLIはC++じゃない

159:デフォルトの名無しさん
08/05/14 15:37:48
>>150
それだけみんなCに不満もってるってことだ。
総力を挙げて潰さないとこの業界に未来はないよ。

160:デフォルトの名無しさん
08/05/14 16:04:13
形式仕様から、最終的にバイナリコード(FPGAベースのチップ向けの)を
生成する研究が実用化されれば、Cだけでなく、現状のほとんどの言語を使わなくなる。

プログラミングは、「問題領域向けのDSLを記述+DSLで動作記述」になるよ。

161:デフォルトの名無しさん
08/05/14 20:24:35
問題領域向けのDSLを記述+DSLで動作記述
↑
これのコンパイラは結局Cでかかれると。

162:デフォルトの名無しさん
08/05/14 20:27:14
最近は言語処理系は関数型言語か C++ で書くのが流行の様だよ
C++ がもう少しまともだったらな

163:デフォルトの名無しさん
08/05/14 20:29:28
コンパイラはリッチな環境の上で動かせるから選択肢の数が全然違う

164:デフォルトの名無しさん
08/05/14 20:57:24
C言語で開発しとけばなんかあったとき安心、見たいのがあるのかね？
性能をどうしてもあと１０％上げなきゃいけない、なんてときもCなら何とかなるとか。

165:デフォルトの名無しさん
08/05/14 21:02:28
Cで書いた所でそれ程ハードルが高くなる訳じゃない
特に拘りがないだけじゃないの

166:デフォルトの名無しさん
08/05/14 21:33:09
俺はCだとハードルかなり高くなる。
それで飛び越えられなくなるわけじゃないとしても、いちいち高めにジャンプしなきゃいけないのがむかつく。

167:デフォルトの名無しさん
08/05/14 21:47:37
コンパイラをCで書くとか、嗜虐癖があるとしか思えん

168:デフォルトの名無しさん
08/05/14 21:49:54
>>164
C で書いておけば色んな言語と混ぜられる。
C のルーチンを LL から呼び出すのは至極楽ちん。

169:デフォルトの名無しさん
08/05/14 22:07:14
前にRubyからCのルーチン呼ぼうとしたらSWIGとかいうの使う羽目になった。
配列とか使ってたから、変換用のコーディングも若干必要になったし。
大変というほどでも無いが至極楽ちんというほど楽ちんでもないような。

170:デフォルトの名無しさん
08/05/14 22:15:07
CはLLのインラインアセンブラや～

171:デフォルトの名無しさん
08/05/14 22:35:22
>>168
C#とPowerShellその他.NETなLLの親和性は異常
CというかシステムコールをOOなLLでラッピングとかもう面倒でやってらんない

172:デフォルトの名無しさん
08/05/14 23:56:55
何でシステムコールが出てくる？
シスコール生で叩かせるLLなんてあるのか？

173:デフォルトの名無しさん
08/05/14 23:57:26
>>171
そういえば、.NETってなんとなくスルーしてたなぁ。
趣味として使うとしたら学ぶ価値ある？
普段はRuby使ってます。

174:デフォルトの名無しさん
08/05/14 23:58:22
>8
＞Cのパフォーマンス
これほんと？

175:デフォルトの名無しさん
08/05/15 00:07:41
>>174
C だけ使えば C と同じ性能。
C++ でもよく使われる言い回し。

176:デフォルトの名無しさん
08/05/15 01:35:36
>>174
例えばある変数の値を、1から10000までカウントupみたいなのは、Cは高速。

理由はおおざっぱに言えば、処理時間=計算量*1計算あたりのクロック数　だから。
2次元テーブル(n行n列)の全スキャン計算量は、nの2乗に比例するからo(n^2)とか。
単純なカウントupの計算量は小さい。

一方、ライブラリに必ずしも無いもの(例:クロージャなど)が必要になると、
プログラマーがゼロから実装するのは負担が大きくて、他の方法で回避する。
回避策の計算量、1計算あたりのクロック数によっては、他の言語で記述した方が
早い場合もある。

↓参考:プログラミング言語ベンチマーク
URLﾘﾝｸ(shootout.alioth.debian.org)

177:デフォルトの名無しさん
08/05/15 02:38:24
>>71
古い話で恐縮だけれども、ICOTの例のプロジェクトでは prolog の進化形で　**カーネルの大部分を** 記述していたとか。
そういう用途のシステムでは、そういう選択もあるようです。
＃同じ研究を現在のハードウェア技術で行ったらどうなるのかつくづく知りたいものですが、あと 100 年はとりあげられないでしょうか‥‥‥。

178:デフォルトの名無しさん
08/05/15 02:43:57
>>88
人を変態よばわりしないでください。
R6RS準拠のコンパイラがでたんですって？

179:デフォルトの名無しさん
08/05/15 08:35:10
Cに文句言うより86アセンブラをまず駆逐しろよ・・・
Intelでさえできなかったんだぞ

180:デフォルトの名無しさん
08/05/15 08:37:36
今時のCPUはアセンブラ（≒機械語）を直接実行せずに
自前の命令に変換するんでしょ。
そんな内部コードを毎度毎度表にさらしてたら大混乱が起こるんじゃね。

AMDの人も命令コードなんて全然大した問題じゃないとか言ってたし。

181:デフォルトの名無しさん
08/05/15 13:54:39
>173
> そういえば、.NETってなんとなくスルーしてたなぁ。
> 趣味として使うとしたら学ぶ価値ある？

プログラミングが趣味か、なんらかの成果物を完成させるのが趣味かで変わってくるんじゃ?
ﾄﾞﾄﾈﾄ系はWindowsのアプリを作るということなら、死ぬほど楽なのは確か。
特にC#とC++/CLIの楽さは異常。

182:173
08/05/15 18:43:57
>>181
レスさんくす。
C#でもかじってみるか。
（そういえばIronRubyはどうなったんだ？とんと話を聞かないが。）

183:デフォルトの名無しさん
08/05/16 18:44:40
開発言語をアセンブラからCに変えて解放されることって

１．レジスタの管理
２．メモリの管理
３．スタックの管理

くらいかな？
こうやってみるとCって意外と面倒な問題を解決してくれてることに気づくｗ

184:デフォルトの名無しさん
08/05/16 18:54:16
とりあえずage

185:デフォルトの名無しさん
08/05/16 19:23:40
CはどんなCPUでも同じ文法で動く、“共通アセンブラ”みたいな位置づけ。
他の言語と比べること自体がナンセンス。もう機能追加とかしない方がいい。
CにはOOだのGCだの必要なし。それはLLとかに任せればいい。

186:デフォルトの名無しさん
08/05/16 19:30:17
namespaceとstructに関数ぶら下げるのとoverloadがあると気分的にだいぶ楽になるな。
IDEとの親和性も爆上がるし。

187:デフォルトの名無しさん
08/05/16 19:42:34
>>185
ただ、cppにはもうちょっと賢くなってほしいけどなあ。

あ、でもあんまり賢すぎるとlispみたいになんでもマクロで書いちゃう
人が出てくるからダメかな。

188:デフォルトの名無しさん
08/05/17 00:00:28
>>183
Cはメモリーもスタックも管理しないだろ

189:デフォルトの名無しさん
08/05/17 00:07:03
自動変数の事じゃないの

190:183
08/05/17 00:20:31
スタックの管理は自動変数、
メモリーの管理はmalloc&free,大域変数のつもりで書いた。

191:デフォルトの名無しさん
08/05/17 11:00:14
OO言語としてC++は置いといて高級アセンブラとしてCを凌駕する
ポストC的な言語がほとんど話題にならない時点で結論が出ているわけだが。

192:デフォルトの名無しさん
08/05/17 12:10:51
c++を駆逐してほしいんだが

193:デフォルトの名無しさん
08/05/17 12:38:39
学習コスト＜＜駆逐コスト

194:デフォルトの名無しさん
08/05/17 13:08:01
>>191
高級アセンブラが使われる環境を駆逐したいんじゃない？

195:デフォルトの名無しさん
08/05/17 13:17:15
入れ子が{}じゃなくて
ポインタが*じゃないC言語ください

196:デフォルトの名無しさん
08/05/17 13:35:32
なぜ組み込みの世界であんなに C++ が嫌われるのか理解できない。
些細なデメリット避けるために大きなメリットを失っている。

197:デフォルトの名無しさん
08/05/17 13:53:06
The C Programming Language 274ページ

URLﾘﾝｸ(www.amazon.co.jp)

The C++ Programming Language 1030ページ

URLﾘﾝｸ(www.amazon.co.jp)

この厚さの差が問題だと思うけどな。スピードを求めるならCで書けばいいし、そうで
ないならJavaとか使えばいいかと思う。C++は何でも屋であるが故に駆逐されつつある。

198:デフォルトの名無しさん
08/05/17 13:53:49
>>192
今田舎に別荘を建てて隠遁する準備が進んでいるよ
200x 年には完成する見込みらしい

199:デフォルトの名無しさん
08/05/17 14:01:51
>>196
C++ は遅い・複雑・でかいの3重苦だから組み込みには向いていない
特にリンクやロードが遅いのは致命的

MISRA-C++ とか JSF++ って日本語の解説無いのかな

200:デフォルトの名無しさん
08/05/17 14:37:41
C+αとして使えば全く速度は変わらないし生産性はかなり上がると思っている。
むしろプログラムを自然に作れば C++ の方が速いと思っているぐらいです。
リンクやロードが遅い理由はよく分からないが、それは言語の問題じゃないん
じゃない?

201:デフォルトの名無しさん
08/05/17 14:51:55
>>200
>リンクやロードが遅い理由はよく分からないが、それは言語の問題じゃないん
>じゃない?

世間の C++ 使いって所詮この程度の認識なんだよね…
自分が使っている道具に対する関心が無さ過ぎ

>全く速度は変わらないし

だからこんなことを平気で言えてしまうわけだな

202:デフォルトの名無しさん
08/05/17 15:39:45
そういうのはいいから説明してくれよ

203:デフォルトの名無しさん
08/05/17 19:10:03
VC8 で Dhrystone Benchmark, Version 2.1 を C と C++ でコンパイルして比較

C
Dhrystones per Second: 10300995.0

C++
Dhrystones per Second: 10299298.0

確かに C の方が速いですね。

204:デフォルトの名無しさん
08/05/17 19:13:25
dhrystone で測れるのはループの中の計算時間だけだからね

205:デフォルトの名無しさん
08/05/17 19:27:25
ループの中で結構関数呼び出しもしてるよ。

206:デフォルトの名無しさん
08/05/17 19:28:51
リンクやロードも?

207:デフォルトの名無しさん
08/05/17 20:04:19
>>200
C+αなんかではなく、ポテンシャル全開でC++を使うときの
コンパイル・リンクの遅さの原因の半分は言語仕様だと思う。
残りの半分は実装の問題。

208:デフォルトの名無しさん
08/05/17 21:51:56
＋αでない残りのポテンシャルの部分って具体的に何よ？
例外とか？

209:デフォルトの名無しさん
08/05/17 21:54:58
テンプレートじゃね？

210:デフォルトの名無しさん
08/05/17 23:04:00
>>206
リンクは C が 0.10257s で C++ が 0.10281s です。
ロードは Windows の場合だと実行と切り離せないのでうまい計測方法が分かりません。

>>208
コンパイルで一番負担がかかるのは圧倒的にテンプレートだと思います。
boost::spirit のように凝ったテンプレートをインクルードしたファイルは
極端に時間がかかります。
遅いだけあってテンプレートの可能性は絶大なのですが。

VCの場合はテンプレートでオブジェクトファイルも大きくなるようです。
ただしリンク後は実行ファイルはそれほど大きくなりません。

211:デフォルトの名無しさん
08/05/18 01:34:45
>>195
入れ子が begin end,
ポインタが ^ でもいい？

212:デフォルトの名無しさん
08/05/18 01:56:07
>>203
同じソースコードで C++ にしただけで 10% 遅くなった。

g++ でコンパイルが通る様にしたのと、scanf() も消して
ベンチマーク回数は 10000000 回固定にしている。

C++:
% otool -L dry2
dry2:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
% time ./dry2
-- snip --
./dry2 1.35s user 0.00s system 99% cpu 1.352 total

C:
% otool -L dry2
dry2:
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
% time ./dry2
-- snip --
./dry2 1.22s user 0.00s system 99% cpu 1.227 total

あまり例題としては適当じゃないけど、こんなもんかね。

213:デフォルトの名無しさん
08/05/18 07:19:22
ちなみに ObjC でもやってみた。

ObjC:
% otool -L dry2
dry2:
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
% time ./dry2
-- snip --
./dry2 1.42s user 0.00s system 99% cpu 1.424 total

更に、ベンチマーク回数を 10 倍にすると…

C: ./dry2 12.26s user 0.01s system 99% cpu 12.291 total
C++: ./dry2 13.47s user 0.01s system 99% cpu 13.490 total
ObjC: ./dry2 14.17s user 0.01s system 99% cpu 14.200 total

Better C は Slower C でしたw
こんなお遊びのマイクロベンチの結果を真に受けちゃ嫌よ。

214:デフォルトの名無しさん
08/05/18 11:03:42
VC は優秀だな。

215:デフォルトの名無しさん
08/05/18 12:21:33
いろんな分野でC++はPythonに置き換わりつつあるな
Rubyなんてのを与えられた日本人は世界から置いてけぼり

216:デフォルトの名無しさん
08/05/18 12:30:09
何のスレだここは

217:デフォルトの名無しさん
08/05/18 13:43:40
cソースはcppソースに変換後にコンパイルされるんだが。

218:デフォルトの名無しさん
08/05/18 14:59:17
cpp ってCプリプロセッサのこと?
確かに gcc はそういう手順になっていると思います。

219:デフォルトの名無しさん
08/05/18 16:06:49
>>214
C コンパイラが C++ 並みに遅いのは優秀とは言えないと思うけど…
アセンブラ出力かシンボルダンプが見てみたいね

>>218
.cpp の事でしょう
何となく何でこうなってるのかは予想がつくけど…

220:デフォルトの名無しさん
08/05/18 18:52:20
Dhrystone Benchmark, Version 2.1 を同じ環境で VC 8.0 と GCC 3.4.4 (cygwin) で比較

VC 8.0 (最適化オプションは /O2)
C: 1m37.328s
C++: 1m37.437s

GCC 3.4.4 (最適化オプションは -O4 -fno-omit-frame-pointer -march="pentium-m")
C: 2m2.188s
C++: 2m4.297s
ちなみに -march を外すとさらに 24s ぐらい時間がのびました。

C コンパイラが C++ 並みに遅くてもこれだけ速ければ十分優秀じゃないかな?
というよりこちらでは GCC も C が C++ 並みに遅くなりました。

221:デフォルトの名無しさん
08/05/18 19:32:20
>>220
ちゃんと C++ としてコンパイルしてる?
共有ライブラリのリンク情報かシンボルダンプかアセンブラ出力か、
何でも良いけど晒してみて。最適化オプション無しだとどうなる?

222:デフォルトの名無しさん
08/05/18 22:24:40
>>221
C++ 版は VC では /TP オプションで、GCC では g++ 経由でコンパイルしたので
C++ としてコンパイルしているはずです。
C++ でコンパイルするとき class X; をソースに書いてもエラーが出ません。

リストは長くなるのでここでは勘弁してください。

参考までに最適化を禁止して時間を計測しました。
最適化なしだと C++ が遅くなると思っていたのですが意外な結果になりました。

VC 8.0
C: 18m58.547s
C++: 18m58.890s

GCC 3.4.4
C: 4m46.594s
C++: 4m47.765s

223:デフォルトの名無しさん
08/05/19 00:33:34
tccを使えば解決、と言ってみる。
URLﾘﾝｸ(alohakun.blog7.fc2.com)

224:デフォルトの名無しさん
08/05/19 00:46:36
>>222
ウィンドウズは知らないけど、うちの環境だとアセンブラ出力も
シンボル名もライブラリのリンクもベンチマークのスコアも変わる。
純粋に C だけのコードでこれだから、Better C として C++ の
機能を混ぜた使い方（例えば例外処理や名前空間）をすれば
更に悪化する物と期待出来る。ウィンドウズで組み込みなら
C++ でも変わらないかもね。あとは Symbian とか。

まあ Better C って考え方は他にも落とし穴があるから、俺は
好きじゃないな。

225:デフォルトの名無しさん
08/05/19 14:40:12
>>224
OS というよりもほとんどの場合コンパイラとリンカで決まると思います。
(Windows の場合は実行時の最適化もやりかねないけど)

組込み向けコンパイラの場合は信じられないくらい最適化がダメなものも
あるようです。5,6年前にある有名 CPU 向けの純正コンパイラーを使った
とき、register 付きローカル変数を使っただけで命令がかなり削減された
ことがありました。VC ではとても考えられないし、いまどき register を
使おうと思う人も少ないと思います。
昔の話なので今の組込み環境がどうなっているのかよく分かりませんが。

> Better C って考え方は他にも落とし穴があるから
技術的にはそれほど大きな問題もないと思っているのですが、興味深いので
よかったら教えていただけませんか?

226:デフォルトの名無しさん
08/05/19 20:31:42
その駄目コンパイラ…
気になる…

227:デフォルトの名無しさん
08/05/20 13:43:51
>>201

C++がCと比較してほとんど性能を落とさない理由は以下の本を読むとよく分かります。
またなぜC++をこのような設計にする必要があったのかも詳しく書いてあります。

C++の設計と進化
URLﾘﾝｸ(www.amazon.co.jp)

星の数が胡散臭く感じるかもしれませんが読む価値はあると思います。

228:デフォルトの名無しさん
08/05/20 18:25:10
あーその本、もってるけど全然読んでないな。
ちゃんと読んでみるかな。

229:デフォルトの名無しさん
08/05/20 18:59:36
>>227
C++は遅いし、コンパイラの事を知らない人間が作った言語だよ。

230:デフォルトの名無しさん
08/05/20 19:08:21
AT&T に居たんだから Aho なりに相談すれば良かったのにな

231:デフォルトの名無しさん
08/05/20 19:08:45
暴言ｷﾀ━＞▽＜━━

232:デフォルトの名無しさん
08/05/20 19:15:22
いやだってやたらと信じやすい人が居たから…
C++ をマンセーするのも良いけど程々にね

233:デフォルトの名無しさん
08/05/20 19:37:24
あ、いちいち最後に改行を付け加えてる人の事な。
ストラウストラップが GLS の 1/10 でも言語設計の知識があったら
あんなコンパイルが糞遅くなる事も無かっただろうさ。

234:デフォルトの名無しさん
08/05/20 20:21:11
あ、いちいち最後に改行を付け加えてる人の事な。
ストラウストラップが GLS の 1/10 でも言語設計の知識があったら
あんなコンパイルが糞遅くなる事も無かっただろうさ。

235:デフォルトの名無しさん
08/05/20 20:23:45
>>234
下2行は禿上がる程同意。その言い訳も>>227の本に書いてあるかな？

236:デフォルトの名無しさん
08/05/20 21:42:19
GLS がストラウストラップ 1/10 でも現実を見ていれば
あんなアプリケーションの起動が糞遅くなる事も無かっただろうさ。

237:デフォルトの名無しさん
08/05/20 22:08:58
C のどこが起動が遅いって?

238:デフォルトの名無しさん
08/05/20 22:15:11
なんでCが出てくるんだ

239:デフォルトの名無しさん
08/05/20 22:20:34
>>238
GLS 知らんのか?

240:デフォルトの名無しさん
08/05/20 22:27:31
ぐぐったら、
予備校とサーバとガラステレビ台が出て来た語学センターとガールズラブサーチってのが出て来た

とりあえずガールズラブサーチ見てる

241:デフォルトの名無しさん
08/05/20 22:32:21
起動は?

242:デフォルトの名無しさん
08/05/20 22:50:13
>>225
>OS というよりもほとんどの場合コンパイラとリンカで決まると思います。

だから環境って書いただろ…
ナチュラルに斜め下の指摘をするのは止めてくれ

243:デフォルトの名無しさん
08/05/20 23:29:12
>>239
Guy L Steel Jr.の事だと思って読んだけど違うの？

244:デフォルトの名無しさん
08/05/20 23:36:44
なら、そんな疑問は浮かばないだろ

245:デフォルトの名無しさん
08/05/20 23:39:59
Guy L Steel Jr.とC言語の関係が分からん

246:デフォルトの名無しさん
08/05/20 23:40:27
ガイ・スティールと聞いてJavaを最初に思い出したとか？＞起動が糞遅く
まあ言語仕様の著者ではあるが無理感じるな

247:デフォルトの名無しさん
08/05/20 23:41:17
>>245
ANSI標準化

248:デフォルトの名無しさん
08/05/20 23:41:51
なぜSchemeが出ない

249:デフォルトの名無しさん
08/05/20 23:42:17
つか、何で知らないなら調べようとしないかね…

250:デフォルトの名無しさん
08/05/20 23:44:46
>>247
すまん、もうちょい詳しく

251:デフォルトの名無しさん
08/05/20 23:47:14
ググっても出てこないのはSteelじゃなくてSteeleだからだ

252:デフォルトの名無しさん
08/05/20 23:56:40
>>235
書いていないな。

そもそもあの本が書かれたのは95年頃で、
テンプレートによるコンパイル速度の低下は
まだ問題になっていなかったのではないかと思う。
俺はテンプレートさえなければ、Cと比べて気になるほどなるとは思えない。

次ページ