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と比べて気になるほどなるとは思えない。
253:デフォルトの名無しさん
08/05/21 00:02:40
テンプレートこそC++の特徴であり価値の一つだと思うんだけど
254:252
08/05/21 00:09:26
>>253
そりゃそうだ。テンプレートなしでC++使うなんて気にはなれないし、
実際、そんな機会は全然ないから
「Cと比べて気になるほどなるとは思えない」というのは自分の想像でしかない。
すれ違いすまん。
255:デフォルトの名無しさん
08/05/21 00:20:09
C++ に無理矢理似非クロージャを入れて喜んでるくせに GLS も知らないんだよな…
256:デフォルトの名無しさん
08/05/21 01:45:37
そもそもGLSって略称一般的かなあ
257:デフォルトの名無しさん
08/05/21 01:56:54
スティールが設計に深く関わった高性能な言語は Fortress ぐらいしかないんじゃない?
258:デフォルトの名無しさん
08/05/21 02:13:36
>>235
D&E 15.10 あたりで問題は認識しいるようですよ。
最近のコンパイラはプリコンパイルヘッダーや簡易ビルドの技術が発達しているので
ずいぶん良くなったと思います。
モジュール分けしてそれぞれの依存度を少なく設計すればそれほどストレスを感じません。
259:デフォルトの名無しさん
08/05/21 07:38:05
>>258
他の言語だってモジュール分けすればもっと速いよ
C++ と違って小細工しなくても常識的な速さだけど
260:デフォルトの名無しさん
08/05/21 08:31:09
まあビルドの速い言語ほどその後の処理負担が大きいけどな。ユーザーが多いほどコストが増大。
261:デフォルトの名無しさん
08/05/21 08:57:38
C++が遅いのは文法の問題だから一般的なまともな言語と比較しても意味無い。
262:デフォルトの名無しさん
08/05/21 09:10:21
>>261 詳しく。
>>259 モジュール分割や依存度下げは小細工かよ。まあ前方宣言はそうかもしれないが。
263:デフォルトの名無しさん
08/05/21 09:20:06
C/C++は糞。
Cは必要悪だがC++は必要ですらない。
264:デフォルトの名無しさん
08/05/21 14:58:16
ベターCとしてのC++は悪くない
ただたまに勘違いしたやつがいらんところで、継承とかテンプレートを
使いまくる。
265:デフォルトの名無しさん
08/05/21 16:41:10
プロファイルを定義して違反したらコンパイル時にエラーか警告出すような
機能を付けてくれないかな。
266:デフォルトの名無しさん
08/05/21 17:59:57
ほほう、それでC++が晴れてベターCになれると。
267:デフォルトの名無しさん
08/05/21 19:36:41
>>266 問題点を指摘して、もっといい方法を教えてください。
268:デフォルトの名無しさん
08/05/21 20:26:33
>>262
>>>261 詳しく。
URLﾘﾝｸ(www.nobugs.org)
C++ 使いって基本的に自分で調べたり勉強したりしないよな…
まあだからこそ未だに C++ をマンセー出来るんだろうけど
269:デフォルトの名無しさん
08/05/22 03:03:43
全体のビルド時間に占める構文解析の時間はそんなに大きいものかね？
第一 C++ の構文解析を複雑にしているのはほとんど C の文法を引き
ずっている部分だよ。D&E を読めば構文解析に配慮していることが分
かるよ。
270:デフォルトの名無しさん
08/05/22 03:10:14
配慮はしてるけど何もしてないってことだろ。俺も自分がニートなのに配慮してる
けど特に就職活動とかしてない
271:デフォルトの名無しさん
08/05/22 03:10:59
>C++ の構文解析を複雑にしているのはほとんど C の文法を
>引きずっている部分だよ
Cからすれば勝手に引き摺って勝手に泥沼に走り去った後ろ姿しか見えない訳で。
ようも色々余計な物引き摺って、そんな泥沼に邁進してるなと。
272:デフォルトの名無しさん
08/05/22 14:36:52
言語屋からの賛成を得てC文法の良くないところを直そうとしたがユーザーから
猛反発食らってあきらめた。現実ばかりを見て理想を追いかけない駄目な設計者。
273:デフォルトの名無しさん
08/05/22 14:54:56
デファクトスタンダードと言う言葉を送ろう。
最近の悪例 Windows 別に利用者がダメとは思わない。
274:デフォルトの名無しさん
08/05/22 18:38:08
さらに彼の欠点はコンパイラの実装者よりも言語ユーザーを重視した設計をすることだ。
EC++ の設計を見習うべきです。
275:デフォルトの名無しさん
08/05/24 21:04:40
つまりCをつかってりゃよかったって話なのか？
276:デフォルトの名無しさん
08/05/26 00:11:25
その通り。
ためしにCを知らない新人にいきなりC++を勉強させてみるとよい。
C++のプログラムを作らせるとCを知らないはずがCスタイルになる。
つまりCは人間の直感に合っているのだ。
277:デフォルトの名無しさん
08/05/26 00:29:03
言いたいことは分かる気がする。
俺1人でプログラムを書くと、核となる処理は結局、手続き型。
ただ、OOP言語だと、その部分をうまく書くために、
いろんなクラスを書くという感じになる。
278:デフォルトの名無しさん
08/05/26 07:31:34
赤ん坊を無人島に放置して勝手に育ってｾｯｸﾙのやり方もわからない状態を
人間の直感にあってるとか言われてもねぇ
279:デフォルトの名無しさん
08/05/26 10:32:00
>>276
「数学を学ばないと未知数を x と書かずに○と書く」みたいな話だな。
「抽象的なものは勉強すべき」ということは欠点でもなんでもないんじゃないの？
280:デフォルトの名無しさん
08/05/26 17:37:34
>>276
そんなに直感にあった言語だったら今頃大学生は皆Cが書けるように
なってるはずだが。
それどころか現実は日本の技術者激減で国家滅亡の危機なわけだが
281:デフォルトの名無しさん
08/05/26 18:20:57
古い言い伝えを思い出すな。
紀元前七世紀、エジプト王プサメティコス一世は臣下に命じ、生まれたばかりの赤ん坊を一切のプログラミング言語とは無縁に育てさせた。
そして赤ん坊がある程度大きくなった時、ある質問をした。
「"Hello world"はどう記述する？」
答えて曰く「# include <stdio.h>
int main(void) {printf("Hello, world!\n"); return 0;}」
王はC言語が最古のプログラミング言語だと確信したという……。
282:デフォルトの名無しさん
08/05/26 18:35:03
AとBはどこ行った?w
283:デフォルトの名無しさん
08/05/26 19:40:52
勝手に確信する分には別に構わんが、言い伝えるのは勘弁してほしいな
284:デフォルトの名無しさん
08/05/26 22:53:10
駆逐できそうにないですね
285:デフォルトの名無しさん
08/05/26 23:09:44
>281
俺が3丁目の角のタバコ屋の長老から聞いた話だと、その王様がCで
バベルの塔問題を解かせようとプログラミングをしていたら、OOPの神様が
お怒りになり、kill -9の雷を降らせ、以降言語がC++やらObjective Cやら
JAVAやらC#やら諸々へと分裂していったと。
そして、崩れ落ちるcoredumpの中で最後に残っていたのがCshだったそうな。
286:デフォルトの名無しさん
08/05/26 23:23:47
>>276
素人の直感は専門家の正しい知見から180度ずれるという宇宙的な法則があってだな･･･
たとえば、システムヘッダの中で、アンダーバーで始まる名前が
多用されているのを見て、そのまま真似したりする。
30度でも90度でもなく180度だ。これは物理的な必然だ。･･･いや、忘れてくれ･･･
287:デフォルトの名無しさん
08/05/27 09:00:15
そして、C++のOOPを覚えたと思ったら、また180度ずれて、トータル360度ずれて元に戻る。
まさに真理の哲学ですね。
288:デフォルトの名無しさん
08/05/27 20:27:43
CプログラマがC++を使わない理由を探す理由を知りたい。
289:デフォルトの名無しさん
08/05/27 20:47:04
その前に>>288がなぜそんなことを聞くのか理由を知りたい
290:デフォルトの名無しさん
08/05/27 20:50:18
>>288組み込み系では、Cが最適開発環境であることは多い。
291:デフォルトの名無しさん
08/05/27 21:49:33
CプログラマってCだけしか使ってない人？そんなひといるのかな。
少なくともLLの一つや二つは使ってるでしょ。C++は要らないけど。
292:デフォルトの名無しさん
08/05/27 22:07:11
C言語と日本語と英語が使えます。
293:デフォルトの名無しさん
08/05/27 23:42:22
その昔、asahi.comでの求人でプログラマ職若干名ってのがあってね、そのときの
条件ってのが「言語: C言語(日常会話レベル)」だったってのが冗談じゃなくてあった。
職場で同僚とためしに「 printf("hello, world!\n");」「break;」とやってみたが、
ゴメン、俺には無理だわと応募をあきらめた。
294:デフォルトの名無しさん
08/05/27 23:58:49
うちの場合は
「CよりC++のほうがいいのは分かったよ、でも使いません」
のような感じでいつも終わってしまう。
295:デフォルトの名無しさん
08/05/28 00:17:12
考えるのがめんどくさい
息をするのもめんどくさい
296:デフォルトの名無しさん
08/05/28 00:20:34
ゆうちゃんとめんどくさいさい
297:デフォルトの名無しさん
08/05/29 20:16:05
組み込みで使うとかいわれても幅が広くてわかりにくいんだが
携帯ゲーム機用ソフトとかもCで組んでたりすんの？
298:デフォルトの名無しさん
08/05/29 20:44:31
GBAのときはCの方がC++より多かったと思う。今は分からない。
299:デフォルトの名無しさん
08/05/29 21:27:12
なるほど、GBA⇒DSだと性能差は十倍にもなってない感じだし
まだCが多かったりするんだろか。PS3が組み込み系に分類されてたり
携帯電話を組み込み系と言ったら笑われたり、俺にはよくわからん
300:デフォルトの名無しさん
08/05/29 22:48:42
>>299
>携帯電話を組み込み系と言ったら笑われたり
そうなの？ カーナビと携帯は組み込みの2大巨頭だと思ってたよ。
301:デフォルトの名無しさん
08/05/29 23:55:42
「JavaVM乗るような潤沢な環境を組み込みと言うかｗｗ」
っていう考えの人も居るっていうだけの話だが、
実際組み込みって言葉はピンキリで随分曖昧な気がする
302:デフォルトの名無しさん
08/05/30 00:39:26
>組み込みで使うとかいわれても幅が広くてわかりにくいんだが
幅が広いからCでないと厳しい環境もあるっていうんじゃダメかね？
オレが今取りかかってるシステムはRAMが32Kしかないんだが
Cとアセンブラ以外使おうとは思わないよ。とにかくリソースがぎりぎり。
処理時間、セクションやスタックの使用量とかも仕様で出さなきゃならんしな。
必ずしもプロファイラがあるわけでもないし。
303:デフォルトの名無しさん
08/05/30 01:27:45
>301
大量に生産するため、リソースを贅沢にすることは即コストに直結する。
開発コストよりも製造コストが重視される。それが量販製品における
組み込み系の特徴の一つ。携帯電話はこれが極端に当てはまる。
JVMが乗っかるのは潤沢な環境なのではなく、それがために他にくるしわ寄せを
吸収しなければならない分、余計につらいってことだね。
正直、いくら携帯電話の機能が大きくなったといっても、本当にリソースが
豊富に使えるなら、基本が機能追加でコードの流用が効く携帯で、毎度毎度
あそこまでデスマにはならない。
304:デフォルトの名無しさん
08/05/30 01:42:25
アセンブラで組むのが一番だと思うが、極端に可読性が落ちる。
C++だと余計なことをしてくれて自分が望むアセンブラに展開してくれない。
だからC。
305:デフォルトの名無しさん
08/05/30 18:08:50
C++ が C と比較してコンパイル結果を予想しにくくしているものは以下のよう
なものがあると思う。逆にこれらを使わなければほぼ予想通りのコンパイル結果
になるはずだ。
- 非 static メンバー関数の暗黙の this の存在
- コンストラクタからの基本クラスとメンバ変数のコンストラクタ自動呼び出し
- デストラクタからの基本クラスとメンバ変数のデストラクタ自動呼び出し
- 静的変数のコンストラクタとデストラクタの呼び出しとそのタイミング
- コンストラクタを持つ静的局所変数の暗黙の初期化チェック
- 自動変数のデストラクタの呼び出し
- 暗黙の型変換の呼び出し
- 一時オブジェクトのデストラクタの呼び出し
- 仮想関数の呼び出しオーバーヘッド
- 実行時型情報の時間コストと空間コスト
- 多重継承と仮想基本クラスによるオーバーヘッド
- メンバーポインタ操作の時間コスト
- 例外処理の時間コスト (特にデストラクタを持つ自動変数が存在するとき)
- inline 関数の出力コード (ただし大域最適化したときはCでも同じ)
- 複雑なテンプレートの出力コード
- 実体を持たない const 変数がある (ただし大域最適化したときはCでも同じ)
306:デフォルトの名無しさん
08/05/30 18:09:21
C++ に慣れてくれば上のような機能を使っても C 並にコンパイル結果を予想
できるようになってくる。ただし複雑なテンプレートの出力コードの予想はか
なり難易度が高い。
C でもがんばれば上のような機能を実現できるが、結局 C++ の速度と変わら
なくなってしまうはずだ。そのようなソースコードのメンテナンスはよほどの
天才でないとできないと思う。
自分が考える C++ の欠点は
- 複雑なテンプレート使用時のコンパイル時間
- テンプレートと名前空間により中間ファイルのサイズが膨張
- コンパイラのバージョン間で ABI が変わりやすい
- 仕様が大きいので学習が大変
307:デフォルトの名無しさん
08/05/30 21:23:52
さらに C++ の欠点の追加
- 標準準拠度の高いコンパイラが少ない (特にテンプレート)
- テンプレート関連のエラー表示が分かりにくい
308:デフォルトの名無しさん
08/05/30 21:38:24
C++の一番の欠点は、そうやっていちいち他の言語に対する「自分が有利と思う点」を
開陳してまわらないと気がすまない、鬱陶しい奴が多いことだろう。
309:デフォルトの名無しさん
08/05/30 21:53:45
ピアソンやオライリーの本に書いてあることを垂れ流してるだけじゃね？
スレの流れのリソースが厳しい環境での答えにもなってなければ
スレの主題への評価にもなっていない。
310:デフォルトの名無しさん
08/05/30 21:56:59
>>308
どのレスの話？
311:デフォルトの名無しさん
08/05/30 22:19:31
>>308 それは言語の欠点ではなく俺の欠点だ。
>>309 ピアソンやオライリーの本はよく読んでいるから影響を受けているに違いない。
しかしこれ以外の本よく読んでいる。
コンパイル結果を予想できればある程度必要なリソースの見積もりが可能だ。
そしてリソース消費がCとほとんど変わらないプログラムをC++で作れる。
さらにバイト単位でリソース消費を抑えたければ最適化無しのアセンブラで組むしかない。
C++がCの代わりになるかもしれないことを主張しているのだからそれほどスレの
主題から離れていないだろ。
312:デフォルトの名無しさん
08/05/30 22:30:05
>>305
>逆にこれらを使わなければ
C でオケ
313:デフォルトの名無しさん
08/05/30 23:15:52
>>312
だな。>>305をコーディング規約にでも書いた日には
「Cでいいじゃねえか!!」と言われそう。
314:デフォルトの名無しさん
08/05/30 23:57:34
Cがこれだけ普及したのは、あまり抽象化しなかったから。
このCに抽象化の手術を施したのが、C++でありJavaでありC#等々。
基本的に無理筋なんだ。
315:デフォルトの名無しさん
08/05/31 01:04:39
抽象化＝クラスと信じて疑わないのがきもい
316:デフォルトの名無しさん
08/05/31 01:25:34
>>312, >>313
>>305を使わなくてもCより遥かに安全で保守が容易なプログラムを作れるようになるのだ。
さらに iniline 関数と const 変数(最後の項目)を使えば安全かつ効率のいいものを作れる。
後は徐々に使う機能を増やしていけばよい。
特にデストラクタの利用は効果的だ。
317:デフォルトの名無しさん
08/05/31 02:27:19
>>313
実は>>305は最後の項を除くと割りと簡単にルールを説明できる。
- コンストラクタ、デストラクタ、非 static メンバー関数を定義しない
- 多重継承を使わない
- 演算子 .* と ->* を使わない
- try, catch, throw を使わない
- inline 関数を定義しない
- template を使わない
最後の項は基本的にうれしいことなので、あえて使いたくないときは
extern を使うなり、アドレスを取得するなりすればよい。
318:デフォルトの名無しさん
08/05/31 03:05:12
>>316
>Cより遥かに安全で保守が容易なプログラムを作れるようになるのだ。
ﾜﾗﾀw
319:デフォルトの名無しさん
08/05/31 04:46:23
・安全で
・保守が用意
共にどこまで把握したことを活用できるか、という問題じゃん？
煽り地味た笑いは早計かと思ふ。
でもC++を一人で神経質にやってもそうはいかんという経験自体は誰もが持ってるだろうしな
共同作業時の問題とか考えると尚更なあ
OOPの幻想
デザインパターン振り回してテンプレート禁止とか言い出すSmalltalk厨の上司
JavaScriptなんて素人の言語だとか時代遅れな事いいやがって
手前の遅刻を棚に上げて帰るのが早過ぎるとかどの面下げて言う
間違った仕様書いといて実装に逆切れしやがって 徹夜して直すと自己管理ミスとかもうね
原付のブレーキ切ったろか
切るべきか 切るべきだな けけけけけけ
>>316
ﾜﾗ太
320:デフォルトの名無しさん
08/05/31 05:15:39
C++否定側の皮肉なジョークだろ？>>305,>>316
321:デフォルトの名無しさん
08/05/31 14:01:59
すこし見ていないうちに話のレベルが少し上がっているな（笑）。まあ、
「新規の言語はすべて旧来の言語のアンチテーゼ」
ある時点で一気に主流になった言語を駆逐するのもそう簡単ではないだろ。
新たな概念も良いけど「誰でも理解できる」という条件を満たさないと意味がない。
「誰でも理解できる」「簡潔に書ける」「効率」等の条件を満たさないと・・・
考えているうちに「自分が生きている内に駆逐されるなら、是非それを経験したい」と思ったよ。
322:デフォルトの名無しさん
08/05/31 19:51:13
>>321
駆逐されたと言う基準はなんだ?
COBOLやFORTRANは駆逐されたのか?
君の生まれる遥か前に生まれたと思うぞ、FORTRANは51歳で未だに現役だ。
323:デフォルトの名無しさん
08/05/31 20:09:07
>>320 決してジョークではない
今までの流れからCプログラマ(特に組込み系)のC++に対する懸念は以下の2つと考えている。
- 生成されるコードが大きくて遅い(例えベターCとして使っても)
- 暗黙の処理によって生成されるコードやリソースが予想しにくい
コードの大きさと速さに関しては、ゼロオーバーヘッドルールによってCのソースコードを
C++コンパイラでコンパイルしてもほぼ同じになると考えてよい。
(ただし最適化の出来が悪いとそうならないときがある)
しかもC++はCとの(道理にかなった)非互換性を選択したことでCの危険なプログラムを
エラーにすることができる。特にコンパイル時とリンク時の型安全の検査は有名だ。
予想しにくい件に関しては>>317のルールに従い、さらに以下のC++機能を使うとよい。
- うっかりミスの防止する機能
非先頭変数宣言、アクセス指定子、C++キャスト演算子、new演算子、参照
- プログラムを組織化し、大規模化しやすくする機能
継承、staticメンバ(関数と変数)、入れ子構造体、構造体内typedef、名前空間
- あれば便利、見通しをよくする機能
関数と演算子のオーバーロード、デフォルト引数、構造体タグ名が型名
これらの機能は全くオーバヘッドがないか、Cと同じぐらい処理が自明だ。
そしてプログラムを安全にし保守を容易にする。
324:デフォルトの名無しさん
08/05/31 20:21:23
>>323
>決してジョークではない
ジョークじゃないなら、そろそろ終わりにしなよ
見ていて辛いわ
325:デフォルトの名無しさん
08/05/31 20:26:55
なら見るのを止めるのがおすすめ
326:デフォルトの名無しさん
08/05/31 20:30:07
やっぱりネタかよw
327:デフォルトの名無しさん
08/05/31 20:34:48
C++を知らないから使っていないんだという前提が痛過ぎる
328:デフォルトの名無しさん
08/05/31 20:40:41
>>323
所で、VC++の最適化にはすばらしいものを感じているが。
今のC言語にあそこまでに最適化があるのか？
無ければ、VC++でCらしく書いたほうが優秀と思われ。
VCのはいたASM見たこと有る?
329:デフォルトの名無しさん
08/05/31 20:46:37
ここはC++を無理矢理Cとして使うスレだっけ?
330:デフォルトの名無しさん
08/05/31 21:28:23
いくらなんでも、非静的メンバ関数の使用はありだろ。
暗黙の引数thisが予想できないというのが理解できない。
普通の関数で引数1つ増えるのと比べて何もオーバーヘッドは変わらない。
むしろ呼出規約によってはthisだけレジスタ渡しになって、素の状態ではやや有利な場合すらあり得る。
331:デフォルトの名無しさん
08/05/31 21:36:05
時折Objective-Cを思い出しては、絶望するスレ。
332:デフォルトの名無しさん
08/05/31 22:17:11
ObjC はとっても C 的で良いんだけど、C を置き換える為の物ではないよね
333:デフォルトの名無しさん
08/05/31 22:18:00
字面がｷﾓすぎ
334:デフォルトの名無しさん
08/05/31 22:25:31
事実上Apple版DLRになってるObj-Cランタイムに価値がある訳で
CからObj-Cランタイムを扱うための言語拡張に過ぎないとも言える
C++やC#とは狙いが違う感じ
335:デフォルトの名無しさん
08/05/31 22:26:07
ここのC++厨はPC上で動くアプリしか作ったことないんだろ。
秋月のキットでも買って出直してこいよ。
336:デフォルトの名無しさん
08/05/31 22:28:02
どんな言語でも見た目が気になるのは初学者のうちだけだよ
文法がまずいとそうもいかないけど
337:デフォルトの名無しさん
08/05/31 22:30:24
>>335
恐らくウィンドウズ以外の経験が全く無いんだろうさ
338:デフォルトの名無しさん
08/05/31 22:44:40
C を駆逐出来るのは C だけだな。C++ は失敗作。
誰か C 1x の仕様策定プロセスを始めてくれないかな。
339:デフォルトの名無しさん
08/05/31 23:03:54
Cから発生した言語は、みんなそのルートを通る。
いまさら新しいCを作ってどうする?
340:デフォルトの名無しさん
08/05/31 23:05:18
どのルート？
341:デフォルトの名無しさん
08/05/31 23:09:53
Cを継承する、拡張する、駆逐する、いわゆる後継のために。
C++も最初はCにクラスが付いただけの言語だった。
342:デフォルトの名無しさん
08/05/31 23:12:46
C++ はもう良いだろ。C を駆逐するのに失敗した言語はスレ違い。
343:デフォルトの名無しさん
08/06/01 00:06:27
CはC99で失敗したからもう発展しない。
VCはC99未対応、gccは -std=c99 が必要
344:デフォルトの名無しさん
08/06/01 00:08:52
VCは要らん
345:デフォルトの名無しさん
08/06/01 00:42:17
>>328
さすがにCとC++の最適化ルーチンは共通化しているでしょう。
疑いもしていないので調べたことはないけど。
346:321
08/06/01 11:47:24
>>322
曖昧な言葉「駆逐」の定義をまた始めるのか？自分はそれに参加する気はないね。
ここはスレタイに曖昧な言葉を使った雑談スレだと思っていたぞ。
レス内容に対してレスせずに発言者に対してレスする、このようなレスがレベルを下げるのを理解して欲しいね。
#答えよう。自分はFORTRANより年上だ。
347:デフォルトの名無しさん
08/06/01 12:01:43
間違いなくここは雑談スレだけど、それを表立って表明してはいけない約束だぜ。
つか、この板のほとんどのスレが雑談スレだ。初学者には雑談以上の話かもしれんけど。
348:デフォルトの名無しさん
08/06/01 13:00:25
C++がCを駆逐できなかったのはJavaのような誇大広告を怠ったからだよ。
「C++は2年以内にCを完全に殺す」のような宣伝をしていればCにダメージを与えていたのに。
あの会社の立場上難しいだろうけど。
349:デフォルトの名無しさん
08/06/01 14:36:50
Why I No Longer Like or Use C++
URLﾘﾝｸ(www.hyuki.com)
350:デフォルトの名無しさん
08/06/01 14:55:59
>>349
C++ではなくCを使う理由にはなっていないんだよ。
環境によっては Java, C#, Python, Ruby などを使う理由にはなるが。
351:デフォルトの名無しさん
08/06/01 15:00:47
>>350
言語が単純で、枯れていて、速くて、資産が沢山あって、
スクリプト言語との連携が良いからだよ。Cでなければ
いけない理由は無いが、C以外にそんな言語は無いからな。
352:デフォルトの名無しさん
08/06/01 15:03:35
原文のほう見ると
URLﾘﾝｸ(prophipsi.blogspot.com)
このスレで先ほどまで力説してた誰かのようなコメントがいきなりついてますな。
353:デフォルトの名無しさん
08/06/01 15:07:09
うーん、やはり見えない敵と戦うタイプだな。
いっそこのスレに呼べばいいんじゃないか？
Another common theme among the posters was that one can get by just
fine in C++ by ignoring the more complicated aspects of C++ and just
focusing on the basic procedural and object oriented features of C++.
In practice this means never touching templates and focusing on class
and function based abstractions. I guess use of exceptions and MI
would be optional and handled on a case by case basis.
I actually don't have a problem going this route. The problem is that
this is NOT the route that the C++ standards people are going and it
certainly isn't the route the C++ literati/intelligentsia are going.
354:デフォルトの名無しさん
08/06/01 15:50:27
>>351
>言語が単純で、枯れていて、速くて、資産が沢山あって、
>スクリプト言語との連携が良いからだよ。
>>317で残った部分は十分に単純で枯れているぞ。
そして速さはCと同じでCとC++の資産も使えるぞ。
スクリプト言語との連携もインタフェース部分だけ
extern "C" すればいいぞ。
>C以外にそんな言語は無いからな。
さらに>>323の機能を使えば安全で便利だぞ。
C++もそういう言語として使えるんじゃないか?
355:デフォルトの名無しさん
08/06/01 16:11:02
「残った部分」とかんな抽象的な。
言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。
毎回チェックするのも大変だし。
>>317で禁止されてる項目はC++がCに比べておいしい所そのものなわけで
これ禁止なら素直にCを使ったほうが早い。
356:デフォルトの名無しさん
08/06/01 16:23:52
>>354
>>>317で残った部分は十分に単純で枯れているぞ。
もう 317 は忘れろ。二度と俺にその話を振るな。
誰も賛同しない物を何でここまで引っ張るかね。
357:デフォルトの名無しさん
08/06/01 16:27:45
もうC++のことは忘れろ。C++はJavaに負けたんだよ。
MSでさえC++は捨ててJavaのパクリを推奨してる。
358:デフォルトの名無しさん
08/06/01 16:32:12
>>355
同意だな
>>317ルールは論外だろ
ちっとも美味しくもなんとも無い"better C"とやらを使うことによって、
少なくともC++のグダグダのABIと、それによるコンパイラ間
非互換性といったおマケはついてくる
それならCのほうがずっといい
無論C99ではなくC89な
359:デフォルトの名無しさん
08/06/01 16:40:41
10 年前ならいざ知らず、今時 C++ をこれだけマンセーするなんて
どれだけ時代が読めないんだろうねえ。しかも中途半端な俺ルールを
ゴリ押ししようだなんて驚くわ。C++ は仕方が無く細々と使うもんだぜ。
360:デフォルトの名無しさん
08/06/01 18:44:34
>>355
>言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。
「言語仕様にある限り使う」と言われればそれまでだが、高々7つ単純な項目ぐらい意識して
開発できるでしょう。しかもinline関数と定数としてのconst変数はいい意味で期待はずれの
結果になるだけで一般的にはルールから外してもいい。さらに暗黙の this を許容できれば
もっと単純になる。
一番簡単なのはプロファイル定義をコンパイラに指定できればいいと思っているが。>>265
>これ禁止なら素直にCを使ったほうが早い。
個人的な経験から>>323の機能があればCと比較して十分開発がやりやすくなると思っている。
本当はデストラクタを使えれば最高だが、見えにくいオーバーヘッドは避けられないので
敬遠されるだろう。
361:デフォルトの名無しさん
08/06/01 18:45:01
>>358
>C++のグダグダのABIと、それによるコンパイラ間非互換性といったおマケはついてくる
まあ>>306でも少し触れたがこれはC++の有名な問題だ。
これを避けるためにboost風のライブラリ命名規則を使ってバイナリを分けたり、
ライブラリのインタフェースのみをCにして実装をC++にするという方法もある。
ABIの問題はC++の利点に比べれば小さいことだと思ってる。
Cでも全くABI問題がないわけではないし。
362:デフォルトの名無しさん
08/06/01 19:35:33
> ABIの問題はC++の利点に比べれば小さいことだと思ってる。
いや、その「C++の利点」を自ら自分ルールで縛りましょうと
言ってるから突っ込まれてるわけだろ。クラスもテンプレートも捨てるのでは
C++の利点の大半をドブに捨てているのと同じだ。そしてABIの欠点は
残る。
ただの自分ルールだから、違反してもコンパイラでチェックも出来ないし
共同開発のチームのメンバに糞ったれなルールを周知し押し付けるための
コストもかかる。
C++のABIの問題は決して小さくは無いだろ。
何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。
363:デフォルトの名無しさん
08/06/01 23:48:27
>>362
>>360にも書いたがチームメンバの問題はそれほど深刻ではないと思っている。
組織が大きくても検査ツールの導入ぐらい(Cプログラムの保守に比べれば)
たいしたコストでもないだろうし。
ちなみに>>317ではクラスの禁止は提案していないぞ。もちろん単一継承の禁止も。
これらのルールはあくまで動作が読みにくい機能を最高に削っただけで環境に合わ
せて緩めるべきだ。
>何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。
COM的なものをC++のABI問題の解決のために利用しているのは少数派でしょ。
個人的にその手のものをC++で使ったのはDirectナントカぐらいしかないよ。
多分COMの人気がなくなったのは.NETの影響じゃないか? .NETじゃCの代わりに
なるとは思えないが。
364:デフォルトの名無しさん
08/06/02 19:50:18
>>363
>チームメンバの問題はそれほど深刻ではないと思っている。
君のチームがどんなプロジェクトで何を作っていて、
どんな人員構成かも分からんのに参考にはならんよ。
ここの人間がどう思っているかは既に分かってるだろ。
君のローカルルールを採用したい人間は誰も居ない。
検討するだけの価値がある様にも思えない。
365:デフォルトの名無しさん
08/06/02 22:13:53
結局Ｃは現役続行てことでおｋ？
366:デフォルトの名無しさん
08/06/02 22:38:52
今Cが使われてるのって、ファーム、ドライバ、OSのカーネルとかか？
それらを駆逐すればいいんじゃね？
367:デフォルトの名無しさん
08/06/02 23:03:35
なんか抽象化の方策でもあるのか？
368:デフォルトの名無しさん
08/06/03 01:41:34
>>364
>君のローカルルールを採用したい人間は誰も居ない。
>検討するだけの価値がある様にも思えない。
何も俺のルールである必要はないんだぞ。あくまでも1つの例として出しただけだから。
強制しているように見えたなら悪かったよ。
Cで生産性上げるためのもっといいアイデアあったら教えて。
369:デフォルトの名無しさん
08/06/03 01:44:25
クソコードをチェックしてくれるデバッガーを大量に雇う
370:デフォルトの名無しさん
08/06/03 01:55:16
そーいえばEC++(embedded C++)ってどーなってるんだ？
あれってリソース要求がシビアな環境向けのC++なんじゃなかったっけ
371:デフォルトの名無しさん
08/06/03 02:08:16
>>370
御大のお言葉をよくお聴きなされ
URLﾘﾝｸ(www.research.att.com)
> "To the best of my knowledge EC++ is dead (2004),
> and if it isn't it ought to be."
try, catch, throw を使わない、template を使わない、
多重継承を使わない C++ のサブセットなんてダメだってさ。
372:デフォルトの名無しさん
08/06/03 12:37:11
>>370
名前空間がないのが信じられない。実行のオーバーヘッドは全くないのに。
しかもそのせいでサブセットですらなくなった。
373:デフォルトの名無しさん
08/06/03 18:00:11
embeddedだからってサブセットにする必要性がない。
ランタイムライブらっりを小さくし、必要に応じたライブラリを使えばいいだけだし。ちょっとテンプレートの使い方を工夫すれば小さくなるもん
374:デフォルトの名無しさん
08/06/03 21:17:58
小さいの概念がデスクトップとは違うんだろう。
例外機構も入れたくないくらい小さくしたいみたいだから。
375:デフォルトの名無しさん
08/06/03 22:33:22
EC++はC++を小さくするというコンセプトはいいのに
小さくするやり方がまったくおかしいので使い物にならん
仕様考えた奴はC++をよくわかってないアホとしか思えん
376:デフォルトの名無しさん
08/06/04 00:53:36
確かEC++は日本人が中心になって考えたんだよ。
電機メーカーはコンパイラ作りになれていないからコンパイラの実装が楽な
仕様を選んだんじゃないか。
377:デフォルトの名無しさん
08/06/04 03:30:33
某h立で集まった人員の中でパーサ経験ある奴が俺しかいなかったな
コンビネーションパーシングの考え方／作り方の講習係で終わった
その後どうなったのやら話も聞かんけど、C++のサブセット作りたがってたのだけは記憶しとる
378:デフォルトの名無しさん
08/06/04 09:21:02
>>376
コンパイラの実装が楽なはずの機能まで外れているし
何考えてるんだか俺には全くわからない
379:デフォルトの名無しさん
08/06/04 20:07:08
>>378
バイナリのサイズを小さくする
コンパイラの実装を平易にする
これら以外の目的で削られた機能って具体的にどれの事を言ってるの？
380:デフォルトの名無しさん
08/06/05 01:26:39
378じゃないけど namespace
削った目的は分からない。
リンクが済んだらバイナリのサイズは変わらない。
実装は2週間以内が目安(D&Eより)、もちろん実装者によって違うが。
381:デフォルトの名無しさん
08/06/05 02:13:47
namespaceを無くすると名前マングリングが単純化できて、C互換のobjが吐けるとか？
382:デフォルトの名無しさん
08/06/05 03:17:22
>>381
名前マングリングはtype-safeリンケージのために名前空間なんぞを
導入するずっと前から行ってることだろ
オーバーロードのようなものがある限り、type-safeリンケージは必須だ
383:デフォルトの名無しさん
08/06/05 20:30:38
必要ならextern "C"を使えば済むとは思う。
どうでもいいかもしれないけど、
extern "C"が名前空間内でも使用可なのには最初驚いた。
384:デフォルトの名無しさん
08/06/06 22:50:16
const_cast, reinterpret_cast, static_cast, mutable も性能に影響を
与えないし実装は比較的簡単だと思う。
dynamic_cast だけ外すと分かりにくい仕様になるかもしれないが。
385:デフォルトの名無しさん
08/06/07 00:21:26
組み込み向けで小さいコードしか書かないから、きっと要らないのだろう。
386:デフォルトの名無しさん
08/06/07 09:42:06
コンパイラを実装する人の都合で削ったように見えるな。
C++からCへ変換するプリプロセッサで実現できそうな機能しか残ってない。
387:デフォルトの名無しさん
08/06/07 14:12:32
>>386
>コンパイラを実装する人の都合
これは実際非常に重要なのだけれど、C++ ではツールを含めた言語環境を
作る人間と、それを使う人間が完全に分離してしまっているのが不思議。
388:デフォルトの名無しさん
08/06/07 14:33:41
C++談義でもりあがってるところ悪いけど、そんなことより
FORTRAN 77をさっさと完全駆逐してほしい。算術IFとかなんだよあれ。
大文字コードはSQLだけで充分だ。
389:デフォルトの名無しさん
08/06/07 14:40:43
>>388
FORTRAN は多分大型コンピュータと共に死滅するんじゃないかな？
390:デフォルトの名無しさん
08/06/07 14:46:31
いやいや、Fortran 90以降は好きだし使ってるけどな。2kからは
オブジェクト指向になるらしいし。Fortran 77がクソ過ぎて困る。
391:デフォルトの名無しさん
08/06/07 18:17:24
高速な数値計算が必要なところは FORTRAN で作って extern "FORTRAN" で
C++ から呼べばいいんじゃないか?
392:デフォルトの名無しさん
08/06/07 18:20:30
それを更に C で wrap して Fortran から呼び出したらいいんじゃない？
393:デフォルトの名無しさん
08/06/08 00:59:14
>388
算術IF文と論理IF文までしかなかったのはFORTRAN 66。
FORTRAN 77ならブロックIF文が使えるはずだが。
算術IFが廃止されたのはFORTRAN 95からだが、過去の資産の使いまわしに困る
ようなFORTRANに存在価値ってあるのかな。
394:デフォルトの名無しさん
08/06/08 01:10:18
>>393
>、過去の資産の使いまわしに困るようなFORTRAN
FORTRANってベクトルマシンと趣味ユース以外で使われてんの？
395:デフォルトの名無しさん
08/06/08 01:42:38
微妙な計算ライブラリとか結構使われている。
自分が関わった某産業分野の制御でも使ってた。
396:デフォルトの名無しさん
08/06/08 02:15:24
そうなのか。
……未だに何故Fortranなのかが判らん分野なんだよなー。
Haskellやmlなんかの関数型も数学向いてるって聞くけど
取って代わられる可能性あんのかな
397:デフォルトの名無しさん
08/06/08 03:58:14
秘伝のソースを一子相伝で守り続けている世界だよ
魔法が息づいているうちは、早々簡単に取って代わられない
398:デフォルトの名無しさん
08/06/08 18:23:42
楽にプログラミングしたい訳では無くて、楽に計算させたいだけだからね。
学術計算用途ではFortranが長いこと使われててライブラリが豊富にあった。
Fortranから他への移行なんて、ここ10年くらいの話じゃないかな？
それもCとかC++だから、数値計算を専門でやってる人以外は、Fortranの
ほうが楽でいいじゃんとか思う人も多いわけよ。別に困ってた訳じゃないから。
399:デフォルトの名無しさん
08/06/08 18:29:53
Cは蓄積だけでなく、実際実際ベクトル／行列計算の分野では
性能的にFortranに勝てんのでしょ
C++は式テンプレートのような遅延評価での高速化テクニックが最近
出てきてるようだけど、どうなんだろう
400:デフォルトの名無しさん
08/06/08 18:52:01
ベクトル／行列計算の性能を追求するなら、Linuxでクラスタ組んで
Cのライブラリを使うのが主流。
スパコンTOP500とかに並んでるのは、ほとんどそういう用途だわな。
401:デフォルトの名無しさん
08/06/08 18:57:26
Cには多次元配列がない、C99まで標準にはrestrictポインタがない、
複素数がないとかいろいろあるからなあ。科学技術計算にC++とかは
お笑いなんで無視していいけど。
402:デフォルトの名無しさん
08/06/08 19:27:12
>>401
>科学技術計算にC++とかは
>お笑いなんで
そうなんか。識者とお見受け
後学のために詳しく聞きたいです。その用途でC++の難点って例えばどんなあたりですか？
403:デフォルトの名無しさん
08/06/08 19:37:58
PGI とか C++ にも対応してるけど、科学技術計算でダメなんか?
まあ C++ なんかどうでも良いけど。
404:デフォルトの名無しさん
08/06/09 22:52:58
スパコン使う分野はともかく現在の数値計算の最前線(新米二等兵とも言う)では
圧倒的にC++が使われているよ。
Fortranの時代と比べてどちらがマシかは判断しかねる。
405:デフォルトの名無しさん
08/06/11 18:53:28
CもC++も、<適度に・中途半端に>なんでもやれる言語だからね、良くも悪くも。
406:デフォルトの名無しさん
08/06/11 19:06:05
C よりも C++ を先に駆逐して欲しいな
既に朽ち始めているから気に病む必要も無いかもしれんが
407:デフォルトの名無しさん
08/06/11 20:31:32
逆に Java や C# に限界を感じて C++ は再評価され始めているんじゃないか?
408:デフォルトの名無しさん
08/06/11 20:41:02
JavaやC#の限界ってなんのこと？
409:デフォルトの名無しさん
08/06/11 21:09:19
VMの外の人と話せないこととか
410:デフォルトの名無しさん
08/06/11 21:49:55
つ JNI
411:デフォルトの名無しさん
08/06/11 21:57:42
むしろＣ＋＋が再評価ってなんのこと？？？
412:デフォルトの名無しさん
08/06/12 09:27:16
C++/CLIのことだろう
413:デフォルトの名無しさん
08/06/12 11:00:04
>>412
あれ便利っつーか楽っつーか、確かにいいんだけど
言語仕様としては究極の汚さだよなあ。
414:デフォルトの名無しさん
08/06/13 18:10:15
Javaのようにオブジェクト指向を強制する言語には限界がある。
C++のように、低水準プログラミング、構造化プログラミング、OOプログラミング、
テンプレートメタプログラミングを混ぜて使えるほうが現場で役立つ。
415:デフォルトの名無しさん
08/06/13 19:05:32
1 行目と 2 行目以降は全く関係無いね
416:デフォルトの名無しさん
08/06/13 21:16:58
役立たないとはっきり書いてほしかったのかな?
417:デフォルトの名無しさん
08/06/13 21:18:29
自己紹介には及ばん
418:デフォルトの名無しさん
08/06/14 17:00:28
アセンブラから見てCってどうなの？
419:デフォルトの名無しさん
08/06/14 17:08:30
ブロックの先頭でしか局所変数を宣言できない C90 の仕様は勘弁してほしい。
あと inline 関数が標準化されていないのも困る。
組込み環境ではそれだけの理由でも C++ の方を使いたいよ。
無理やり C を使わせられたら発狂しそうだ。
420:デフォルトの名無しさん
08/06/14 17:10:57
C99 か GCC でオケ
421:デフォルトの名無しさん
08/06/14 17:14:18
#define INLINE _inline
422:デフォルトの名無しさん
08/06/14 17:26:15
#pragma inline 使うコンパイラがあるので #define だけではすまない。
423:デフォルトの名無しさん
08/06/15 00:49:57
そこで_Pragma演算子よ、って結局C99というオチ。
424:デフォルトの名無しさん
08/06/15 00:55:33
C++
425:デフォルトの名無しさん
08/06/15 13:00:19
C以外の中級言語つくろうって動きはないのかね
426:デフォルトの名無しさん
08/06/15 13:44:05
Dは無視ですか、そうですか
427:デフォルトの名無しさん
08/06/15 15:36:22
C90 はポータビリティを考えたら外部識別子が 6 文字までしか使えないから使いにくい。
C++ は 1024 文字まで保障されている。
428:デフォルトの名無しさん
08/06/15 15:43:45
そういやそんなのあったな・・・全く守ってねーや
429:デフォルトの名無しさん
08/06/15 16:49:15
>>427
もっともC++処理系自体にはポータビリティがないがなw
430:デフォルトの名無しさん
08/06/15 17:03:02
きっと処理系のできは時間が解決してくれるよ。
431:デフォルトの名無しさん
08/06/15 17:05:51
もう時代の審判が下るくらいの時間は経ってると思うが、
今後これ以上何かあるかなあ…
432:デフォルトの名無しさん
08/06/15 18:24:16
今の C++ コンパイラってそんなに標準準拠度が悪いの?
組み込みなら C のように標準ライブラリの一部が削られているかもしれないけど。
VC9 と GCC4.x は問題ない範囲だと思うけど、準拠度の低いのってどんなのある?
433:デフォルトの名無しさん
08/06/18 15:20:55
>>431
B言語でもやってろ
434:デフォルトの名無しさん
08/06/18 15:55:05
C 言語のように構造体メンバのアクセス制限のない言語を使って複数人で開発するのは難しく
ないですか? 以下の開発方法しか思いつかないのですが。
- 構造体オブジェクトへのアクセスは必ずその構造体用の関数を経由するように周知徹底する
- 構造体定義を利用者から隠してメンバへのアクセスを不可能し、ヒープからオブジェクトを
生成する関数を用意する
- 構造体の文書を整備し、定義に変更があったらその構造体を使っている場所を点検し直す
インライン関数があれば最初の方法が現実的かな。
435:デフォルトの名無しさん
08/06/18 16:40:50
- 一度定めた構造体の定義に対して互換性がなくなるような変更をしない
436:デフォルトの名無しさん
08/06/18 18:13:08
>>435
それはpointみたいに非常に単純なものでない限りは
現実問題としては無理なので、
opaqueな型にしてしかもメンバにmagic number仕込むとかやったほうがいいな
437:デフォルトの名無しさん
08/06/18 19:18:44
何か無理やりOOをやりたいのか？C++じゃないんだが。
438:デフォルトの名無しさん
08/06/18 20:03:38
>>434
拡張子をだなcppに変えて（ｒｙ
439:デフォルトの名無しさん
08/06/18 20:44:55
>>437
OO まではいかないけど抽象データ型を使うとプログラムの変更に強くなるし楽だと思う。
C の標準ライブラリでは FILE ぐらいしか思いつかないけど、Windows ではよくハンドルを
使っているようです。C の場合整数のハンドルより構造体のポインタを使ったほうが型安全
でいいかもしれませんね。
コンテナのようにある程度複雑の構造だと抽象データ型じゃないとつらいんじゃないかな。
440:デフォルトの名無しさん
08/06/18 23:57:02
>>434
むしろOO的には、一番目と二番目を徹底すべきじゃないのか？
C++であっても。
441:デフォルトの名無しさん
08/06/19 00:38:02
>>439
いや、構造体をクラスに見立ててOOしたいんだろ？
じゃなきゃ、>>434の1行目のようなアクセス制限が云々なんて前提が出てくるとは思えない。
Cのパラダイムを無視して、突然こんな前提で設計しろと言われたらオレは難色示すね。
というわけでお前の考え方では、複数人での開発は難しくなるだろう。
これまで培われたコンセンサスに乗っ取った構造体の使い方をすればいい。
無理してオレ流OOルールを持ち出せば、上で叩かれているC++のローカルルールと同じ問題になると思うがね。
お前はCのパラダイムを無理やりOOに当てはめて解釈しようとしてるんじゃないのか？
ああ、それと今オレがCで書いているシステムは、ヒープ割り当てができないようになってて、
スタックは1Kしか使えないんだがどうするんだい？
オレ流OOルールをもうひとつ追加するのか？RAMも16Kに減らされそうなんだが。
442:デフォルトの名無しさん
08/06/19 00:45:25
RAMが16Kbyteもあるなんて贅沢だw
443:デフォルトの名無しさん
08/06/19 01:07:40
オブジェクト指向は言語と直行した概念だから C で OOP しても何の問題も無い。
構文の助けが無い分、面倒臭いのは我慢する必要があるけど。
URLﾘﾝｸ(www.gnome.gr.jp)
URLﾘﾝｸ(ja.wikipedia.org)
URLﾘﾝｸ(www.sage-p.com)
シンプルな C に多少のルールを追加するのと、カオスな C++ から便利機能を
削除するのは別次元の話だと思うよ。
444:デフォルトの名無しさん
08/06/19 02:07:30
C++はいらないけど、C++コンパイラは必要。
CのソースをC++でコンパイルすると型チェックが厳密なんで
バグ出しにたすかる。プロトタイプ宣言の型が省略可能とか
mallocが暗黙的に型変換されるとかありえない。あとNULLも0で
統一してくれ。
445:デフォルトの名無しさん
08/06/19 02:11:53
>>443
COOL 見たけどかなり面倒くさそう。
書くときの面倒くささよりコンパイラの安全性チェックができなくて
変更を間違ったときに気づかなくてバグになりそう。
これなら20年ぐらい前のC++仕様でも楽に安全に作れると思う。
446:デフォルトの名無しさん
08/06/19 02:22:14
CでOOPLならObjective-Cがあるじゃん。あれもあれで変な言語だけど。
447:デフォルトの名無しさん
08/06/19 02:28:21
Objective-C は C Compiler でコンパイル出来ないから、、、
と思ったけど POC を忘れてたわ。
URLﾘﾝｸ(users.pandora.be)
C++ より Objective-C の方が C の発想に近いよね。
448:デフォルトの名無しさん
08/06/19 02:35:35
URLﾘﾝｸ(grape.mtk.nao.ac.jp)
ここに書かれている通り C は「悪い方がよい」原則。ObjC も同じ。
C++ はどちらかというと CL の辿った道に近い気がする。
つまり「正しい」アプローチで作られた「複雑巨大システム」。
449:デフォルトの名無しさん
08/06/19 02:42:51
「悪い方がよい」原則って、意味のある言葉じゃないだろ。
いいものが定着するとなにも言わずに、悪いものが定着すると
「悪い方がよい」って言えばいいんだから。
450:デフォルトの名無しさん
08/06/19 02:46:57
>>441
抽象データ型なんて昔から C で普通にやっていることだよ。
C++ の前の C with Classes でもこれをやりやすくするためにアクセス保護を導入したし。
構造体の定義が可視ならヒープにとる必要もないしスタックにもオブジェクトを置けるよ。
定義が可視ならもちろんアクセス保護があったほうが安心だけど。