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

1 ：デフォルトの名無しさん：2008/05/07(水) 20:11:42

どうすればいい？

2 ：デフォルトの名無しさん：2008/05/07(水) 20:13:02

クソすれ立てる人間を完全に駆逐するためには

どうすればいい？

3 ：デフォルトの名無しさん：2008/05/07(水) 20:17:12

駆逐する意図が分からん

4 ：デフォルトの名無しさん：2008/05/07(水) 20:30:05

C言語は生産性低い。
コーディングしててイライラする。
もうC言語はうんざりだ。
しかしパフォーマンスやらなんやらの点からC言語を選ばざるを得ないこともある。

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

5 ：デフォルトの名無しさん：2008/05/07(水) 20:42:07

そんなキミにD

6 ：デフォルトの名無しさん：2008/05/07(水) 20:43:26

>>4
で、なぜはほんとう？

7 ：デフォルトの名無しさん：2008/05/07(水) 21:11:28

言語厨召喚スレ

8 ：デフォルトの名無しさん：2008/05/07(水) 21:37:00

Cのパフォーマンス、スクリプト言語並のゆるい型付け、
Smalltalkから受け継いだオブジェクト指向、
そう、つまりObjective-Cの出番だな。

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

9 ：デフォルトの名無しさん：2008/05/07(水) 21:41:29

MISRAやら、あの系統のコーディング規約とかを目にすることがあるけど、
あそこまでガチガチにするなら、素直にPascalつかっとけよって感じだけど。

10 ：デフォルトの名無しさん：2008/05/07(水) 21:50:45

C++はCを（完全には）駆逐することは出来なかった。
なぜ？

11 ：デフォルトの名無しさん：2008/05/07(水) 22:09:35

慣れてるから。実績があるから。
切替えによる不具合がないといいきれないから。
教育コストがかかるから。機能的に必要ないから。

12 ：デフォルトの名無しさん：2008/05/07(水) 22:14:30

そりゃ、ハードウェアをある程度仮想化できて、汎用性と生産性が高い
アセンブラが登場してくれば……たぶんCとほとんど同じようなものに
なるだけだな、きっと。

13 ：デフォルトの名無しさん：2008/05/07(水) 22:20:38

>>10
MFCとシステムハンガリアンのせいだったりして

14 ：デフォルトの名無しさん：2008/05/07(水) 22:31:59

みんなに聞きたいんだが、みんなの意見はどれに近い？

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

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

15 ：デフォルトの名無しさん：2008/05/07(水) 22:52:37

>>14
２
古臭さを感じるけど、メジャーな代替言語が無いからなぁ
あんまり言うと言語厨が沸くから、この辺で

16 ：デフォルトの名無しさん：2008/05/07(水) 23:02:04

>>14
2
環境制限なしでC++ or CならC++を取りたいな。
たぶん組み込みやってるから若干3よりではある。

17 ：デフォルトの名無しさん：2008/05/08(木) 00:22:35

>>10
STLでprintfのような書き方できないから

18 ：デフォルトの名無しさん：2008/05/08(木) 00:29:53

>>10
C++はC++で問題が多いからな
むしろC++は駆逐される側にまわってしまった感がある

19 ：デフォルトの名無しさん：2008/05/08(木) 06:29:39

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

20 ：デフォルトの名無しさん：2008/05/08(木) 11:19:14

まあ同意なんだけど、それってどれも欠点の裏返しとして槍玉に上がる利点なんだよな
なんか止揚っつーか、パラダイムシフトが欲しい所なのかもね

21 ：デフォルトの名無しさん：2008/05/08(木) 11:51:05

他にCの代替になる優良な言語があるならともかく、
無い現状で駆逐しようとか気勢上げてもしょうがないだろう。
順番が逆。

22 ：デフォルトの名無しさん：2008/05/08(木) 13:49:11

>>21
Javaとか言い出す奴が出そうだなｗ

23 ：デフォルトの名無しさん：2008/05/08(木) 14:00:28

Cと全く同じことがCが動く全プラットフォームでできて
なおかつ機能が少なくとも同等でパフォーマンスが少なくとも同等な言語があれば
Cは一気に駆逐されると思うぜ

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

24 ：デフォルトの名無しさん：2008/05/08(木) 14:59:03

それってただのまがいもの

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

25 ：デフォルトの名無しさん：2008/05/08(木) 18:33:49

C+CoreFoundation
C+GObject

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

26 ：デフォルトの名無しさん：2008/05/08(木) 18:48:41

>>21
だからCの代替になる言語を作ろう(あるいは見つけてこよう)という話じゃないの？

27 ：デフォルトの名無しさん：2008/05/08(木) 20:03:31

>>8
Apple信者の俺でもそれはねーよｗ

28 ：デフォルトの名無しさん：2008/05/08(木) 20:41:35

ハードウェアが根本から変わったらCは駆逐される。
ハードウェアがノイマン型のうちはCは無くならんよ。

29 ：デフォルトの名無しさん：2008/05/08(木) 21:51:45

Cには標準で動的にサイズが変わるコレクションが無いっていうのがいや。

30 ：デフォルトの名無しさん：2008/05/08(木) 22:05:50

でも、それで充分な内容もたくさんあるってことだね。

31 ：デフォルトの名無しさん：2008/05/08(木) 22:45:42

>>26
結局Cみたいなもんしかできあがらんだろうなってのが
大方の意見だと思われ。

32 ：デフォルトの名無しさん：2008/05/09(金) 01:53:40

OSでUNIX(POSIX)的なものを完全に駆逐できれば可能かもね

33 ：デフォルトの名無しさん：2008/05/09(金) 02:30:25

Inferno を思い出した

34 ：デフォルトの名無しさん：2008/05/09(金) 03:21:42

>>29
裏で勝手にメモリ取らないというのがCのポリシーだろ。
その意味でstrdupは異端。

35 ：デフォルトの名無しさん：2008/05/09(金) 03:52:58

>>34
>Cのポリシー

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

36 ：デフォルトの名無しさん：2008/05/09(金) 09:17:04

俺解釈だろ

37 ：デフォルトの名無しさん：2008/05/09(金) 12:37:27

>>32
Unixと共に産まれUnixと共に滅ぶのならCも本望だろう。
どっちも死にそうに無いけど。

38 ：デフォルトの名無しさん：2008/05/09(金) 17:20:01

ハード寄りな言語がCしか無いのってのが現状。
カーネルやデバイスドライバとかいじろうとするとCしか選択肢がないんだよ。

39 ：デフォルトの名無しさん：2008/05/09(金) 17:31:17

tomoyo Linux最高

40 ：デフォルトの名無しさん：2008/05/09(金) 19:19:10

Cの文法上の不満点は？

41 ：デフォルトの名無しさん：2008/05/09(金) 19:47:02

そういうレベルじゃないだろ

42 ：デフォルトの名無しさん：2008/05/09(金) 19:56:30

>>40
宣言の文法は、異常。
もっとスッキリできなかったのか？

43 ：デフォルトの名無しさん：2008/05/09(金) 20:22:02

Cはタイプ量が多くなる。
他の先進的な言語と比べて１０倍くらいタイプが必要だろ。

44 ：デフォルトの名無しさん：2008/05/09(金) 20:26:39

それはGUIみたいな無駄かつ無意味な処理を書くから。

45 ：デフォルトの名無しさん：2008/05/09(金) 20:29:29

C++はC+程度に留めておけばCに止めを刺せたかもしれないのにな。
ちょっと欲張りすぎたね。

46 ：デフォルトの名無しさん：2008/05/09(金) 20:39:26

Cの宣言の文法は一貫性があって良いと思うんだけど、なかなか賛同が得られない

47 ：デフォルトの名無しさん：2008/05/09(金) 20:55:38

文法にすら不満が無いのならなんで駆逐させたいんだ

48 ：デフォルトの名無しさん：2008/05/09(金) 21:52:40

クラスが無いのが不満。
CでOOぽくコーディングするとキモくなる。

49 ：デフォルトの名無しさん：2008/05/09(金) 21:59:45

>>48
いやそれCの不満点として挙げる必要ないだろｗ
ま、C++使っちゃいけない場合が多すぎるのもあるけど

50 ：デフォルトの名無しさん：2008/05/09(金) 22:01:40

関数プログラミングができないのが不満

51 ：デフォルトの名無しさん：2008/05/09(金) 22:17:26

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

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

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

52 ：デフォルトの名無しさん：2008/05/09(金) 22:23:45

GCは要らない。GCなんか入れたらC言語の利点が失なわれてしまう
代数的データ型とか、制限付きの無名関数とか、強力なマクロとか、パターンマッチとか、
そういうこまごましたものが欲しい

53 ：デフォルトの名無しさん：2008/05/09(金) 22:28:22

オブジェクトシステムを入れるなら単一継承にして欲しいし、そうなるだろうな

54 ：デフォルトの名無しさん：2008/05/09(金) 22:30:48

Cのリプレースを目指すわけじゃなく単純に哲学を受け継いだ正常進化系の言語ってありそうなもんだけど
結局メジャーになるようなものは出てきてないな。

55 ：デフォルトの名無しさん：2008/05/09(金) 22:31:03

そんな難しい機能入れたって、C厨に使えるわけないだろ。

56 ：デフォルトの名無しさん：2008/05/09(金) 22:38:40

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

57 ：デフォルトの名無しさん：2008/05/09(金) 22:39:29

今の時代にCだけしか使っていない人間が生き残っているとも考えづらいし、
高級言語はそれなりに触っている事だろう。

58 ：デフォルトの名無しさん：2008/05/09(金) 22:42:31

>>57
入社してCの部署に配属されて、Cしか触ったことないってやつとかいっぱいいそうだけど。

59 ：デフォルトの名無しさん：2008/05/09(金) 22:47:50

ハード寄りの組み込みの人たちとかUNIX系OSのカーネル開発者系の人達とかはたとえ
先進的言語について精通していたとしても自分の仕事ではCを使う、みたいな感じで
生き残り続けるんじゃない？

60 ：デフォルトの名無しさん：2008/05/09(金) 22:52:19

>>58
うちの会社では見た事無いな。Javaの研修がほぼ必須になってるし。
組み込み機器メーカーのソフト開発部門とかだとC専業部隊があるのかな。

61 ：デフォルトの名無しさん：2008/05/09(金) 23:06:24

>>56
コボルはまだまだ残る
なぜか残る

62 ：デフォルトの名無しさん：2008/05/09(金) 23:46:18

>>48
そこでObjective-Cですよ！
…ごめん俺もなんか無理>>8

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

63 ：デフォルトの名無しさん：2008/05/09(金) 23:58:47

C言語と一緒にCシェルも駆逐してくれ。

64 ：デフォルトの名無しさん：2008/05/10(土) 00:02:17

むしろBシェルがイヤっす
あーいう曖昧なのを許容するなんて出来ない
あれがデフォなせいでLinuxやら使いたくない

65 ：デフォルトの名無しさん：2008/05/10(土) 00:19:13

何か曖昧だったっけ？

66 ：デフォルトの名無しさん：2008/05/10(土) 00:24:05

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

67 ：デフォルトの名無しさん：2008/05/10(土) 01:46:46

わざわざノイマン型コンピュータと明言する必要でもあるのか？

68 ：デフォルトの名無しさん：2008/05/10(土) 06:08:06

まぁ、出世してエラくなれば、言語使ってPGなんてしなくなるから、
どうでもよくなるよ。

69 ：デフォルトの名無しさん：2008/05/10(土) 06:55:54

仮面ライダーBLACKが一度死んでRXとして復活したように
Javaも一度死ぬべきだ
そして真の神仕様の言語として復活すべし

70 ：デフォルトの名無しさん：2008/05/10(土) 07:10:58

逆だな、Javaはもっとカオスになってくれないと
リファクタリングしたときの効果が薄くていかん。
D言語みたいに中途半端になってしまう。

71 ：デフォルトの名無しさん：2008/05/10(土) 08:08:13

>>1
先ずは、KernelとコンパイラをC以外で書いてみれば？

72 ：デフォルトの名無しさん：2008/05/10(土) 08:31:08

javaとC#とあとはオブジェクト指向スクリプト言語しか使ったこと無い俺に
C++がCより劣ってる点を教えてくれ。

73 ：デフォルトの名無しさん：2008/05/10(土) 08:56:37

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

74 ：デフォルトの名無しさん：2008/05/10(土) 09:03:16

>>73
しょうもない質問で申し訳ない。

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

75 ：デフォルトの名無しさん：2008/05/10(土) 09:04:31

>>72
斜め上の機能を使いにくい
GCはまあ使えるがcall/ccとか無理ぽ

76 ：デフォルトの名無しさん：2008/05/10(土) 09:06:03

>>72
すぐにコンパイル・リンクにめちゃくちゃ時間がかかるようになること。

77 ：デフォルトの名無しさん：2008/05/10(土) 09:06:31

>>74
しっ！そこ突っ込んじゃ可哀想！

78 ：デフォルトの名無しさん：2008/05/10(土) 09:12:02

俺の理解ではコンパイラはアセンブラを吐いて
アセンブラがバイナリを吐くということになっている。
アセンブラまで含めてのコンパイラというなら
コンパイラの出力はバイナリ。

79 ：デフォルトの名無しさん：2008/05/10(土) 09:15:44

>>66
オブジェクト指向っていうのは、構造化の延長線上じゃないの?

80 ：デフォルトの名無しさん：2008/05/10(土) 09:19:17

>>73
そこらへんの高級言語よりは速いコードを生み出すと信じられているから。

81 ：デフォルトの名無しさん：2008/05/10(土) 09:29:21

http://shootout.alioth.debian.org/debian/

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

82 ：デフォルトの名無しさん：2008/05/10(土) 10:33:28

>>79
C++とかJavaとかCの延長線上の言語でオブジェクト指向を見ると
そう見えるかもしれんね

83 ：デフォルトの名無しさん：2008/05/10(土) 11:24:39

>>72
バイナリがやたらでかくなる
ネームマングリングの所為でシンボルダンプやスタックトレースが読み辛い

84 ：デフォルトの名無しさん：2008/05/10(土) 12:26:13

>>72
技量の低い私にはコンパイラの出力がどーなっているか C は分かっても C++ はわからない。
私のような技量の低いプログラマーを駆逐する方が本来の目的に近づけるのかも。

85 ：デフォルトの名無しさん：2008/05/10(土) 12:31:12

>>78
では、「んなもん実装次第」だということを理解しましょう。

86 ：デフォルトの名無しさん：2008/05/10(土) 17:08:29

(1)多くのOSがC言語の関数群として表現されている
(2)他言語のコンパイラも多くはC言語で書かれている。
(3)(1,2)を他言語に換装する作業が面倒＆標準言語が未定。

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

87 ：デフォルトの名無しさん：2008/05/10(土) 17:22:33

Objective-CってMac専用だろ
その時点でCにとって代わるのは無理

88 ：デフォルトの名無しさん：2008/05/10(土) 18:46:40

>>73
そりゃ自分の言語がいろんなプラットフォームで動くようにしたいからでしょ。
だから言語は C でかくか、JavaVM で動かすかのどっちか。
変態系は lisp で書いたりするけど。

89 ：デフォルトの名無しさん：2008/05/10(土) 19:10:35

>>87
専用って訳じゃないと思う、、(^^;
ttp://wwwa.dcns.ne.jp/~nito/objective-c/answer-17.html

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

90 ：デフォルトの名無しさん：2008/05/10(土) 22:28:04

そんなん過渡期にこういうのありましたよ、って紹介でしか知りません

91 ：デフォルトの名無しさん：2008/05/10(土) 23:40:28

>>86
> (1)多くのOSがC言語の関数群として表現されている 

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

92 ：デフォルトの名無しさん：2008/05/10(土) 23:50:51

Objective-CってMac専用ってイメージなのか。
俺はずっとNext専用ってイメージしかなかったから、ちょっとびっくり。

93 ：デフォルトの名無しさん：2008/05/11(日) 05:42:43

Objective-Cは取り敢えず[]で括るのがキモイ

94 ：デフォルトの名無しさん：2008/05/11(日) 11:19:20

C++でガベージコレクション使わんのがある程度Cの代用に
なるんじゃないのか

95 ：デフォルトの名無しさん：2008/05/11(日) 11:49:29

最近はC++の記法の方がキモく感じられるようになった。
Objective-Cはかなり良いのだけど、これ以上広がることはないだろうな、まったく残念ながら。

96 ：デフォルトの名無しさん：2008/05/11(日) 12:05:21

ちょっと興味はあるんだが検索してもサンプルコードらしきコードが全然出てこないな

97 ：デフォルトの名無しさん：2008/05/11(日) 12:16:54

オブジェクト指向言語の比較
http://hmdt.jp/oop/index.html

ちょっと興味深かった。

98 ：デフォルトの名無しさん：2008/05/11(日) 12:53:49

>>86
2 は重要かな?
Lisp のコンパイラは大抵 Lisp 自身で書かれているし、
確認していないけど javac は C++ で書かれてるよね?
その他、JavaScript のコンパイラは Java, OCaml, SML,
JavaScript, C++, etc. で書かれた実装があったと思う。

99 ：デフォルトの名無しさん：2008/05/11(日) 14:26:14

最初のC++コンパイラはCで書くしかないからな
そのコードを捨ててC++で書き直す意味が分からん

100 ：デフォルトの名無しさん：2008/05/11(日) 14:35:38

>>99
>最初のC++コンパイラはCで書くしかないからな

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

101 ：デフォルトの名無しさん：2008/05/11(日) 14:53:21

それどうやってコンパイルしたんだろ
手か
俺は絶対に嫌だが

102 ：デフォルトの名無しさん：2008/05/11(日) 14:55:07

つ　bootstrap

103 ：デフォルトの名無しさん：2008/05/11(日) 15:00:24

我々はもう既にオブジェクト指向から拡張した新たなるパラダイムに接している。

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

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

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

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

104 ：デフォルトの名無しさん：2008/05/11(日) 15:09:09

ここだけ 1990 年代のスレですか?

105 ：デフォルトの名無しさん：2008/05/11(日) 15:36:58

JavaChip上でJavaOSが動けばCも捨てられるんだろうけどね

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

106 ：デフォルトの名無しさん：2008/05/11(日) 15:38:52

だからもっとまともな高級アセンブラが欲しいって話じゃないのか

107 ：デフォルトの名無しさん：2008/05/11(日) 15:51:51

D言語があるじゃまいか！

108 ：デフォルトの名無しさん：2008/05/11(日) 16:08:58

皆に黙殺されるD言語

109 ：デフォルトの名無しさん：2008/05/11(日) 18:50:50

真のオブジェクト指向言語はLOGO

110 ：デフォルトの名無しさん：2008/05/11(日) 21:40:39

Objective-D++が有れば最強……かも。

111 ：デフォルトの名無しさん：2008/05/11(日) 23:01:18

>99
最初のC++の実装は、確かCへのトランスレータじゃなかったっけかな。
国内でもPC向けのC++実装はトランスレータの時代があった。MIWA C++とかさ。

112 ：デフォルトの名無しさん：2008/05/11(日) 23:15:47

C++は生れた時から今までずっと、C with class だろ？
CとC++で、OOなコードを書こうとする時、コード量が増える以外の
違いってあるのかな？

113 ：デフォルトの名無しさん：2008/05/12(月) 00:11:27

>>99-101
「最初のC++コンパイラはC with Classesで書かれた」が答えというオチ？

114 ：デフォルトの名無しさん：2008/05/12(月) 12:10:39

Zortech C++ のバージョン1使ってたぞ。Cへのトランスレータだった
ちなみに作者はWalter Bright
Dの作者でもある

115 ：デフォルトの名無しさん：2008/05/12(月) 13:35:53

Zortech C++は最初からトランスレータじゃなくてnative compilerだったと
思うけど。PC向けに国内で初めて手に入ったnative compilerってことで俺も
買って、そして余りのバギーさに枕を濡らした記憶がある。

116 ：デフォルトの名無しさん：2008/05/12(月) 22:34:49

仮想関数があるとパフォーマンス落ちるから継承がある言語はCの代わりにはなれないな。

117 ：デフォルトの名無しさん：2008/05/12(月) 22:45:17

パフォーマンス(笑)

118 ：デフォルトの名無しさん：2008/05/12(月) 22:47:50

あんたの笑いのツボはよく分からんな

119 ：デフォルトの名無しさん：2008/05/12(月) 22:50:04

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

120 ：デフォルトの名無しさん：2008/05/12(月) 22:54:48

Java(笑)

121 ：デフォルトの名無しさん：2008/05/12(月) 23:16:42

継承無しのクラスに価値はあるのか？

122 ：デフォルトの名無しさん：2008/05/12(月) 23:18:04

継承はクズ。これからは委譲。

123 ：デフォルトの名無しさん：2008/05/12(月) 23:19:55

オブジェクト指向を根本から否定かよ。

124 ：デフォルトの名無しさん：2008/05/12(月) 23:35:13

>>120
C言語（笑）

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

125 ：デフォルトの名無しさん：2008/05/12(月) 23:35:35

なぜ継承がクズかkwsk

126 ：デフォルトの名無しさん：2008/05/12(月) 23:40:23

>>123
delegationも立派なオブジェクト指向の手法。継承だけがOOPLじゃないのよ。
>>125
オブジェクトの関係を固定してしまうから変化に弱い。

127 ：デフォルトの名無しさん：2008/05/12(月) 23:42:18

>>126
初心者の俺でも分かるようにもっとｋｗｓｋ

128 ：デフォルトの名無しさん：2008/05/12(月) 23:52:28

仮想関数は実行時に差し替えることができない。だから継承しまくる
デリゲートはそれができる。だから継承いらない

129 ：デフォルトの名無しさん：2008/05/13(火) 00:19:14

処理の委譲とインタフェースの実装はまるで別な機能だろ。
ストリーム関係が継承を必要とする最もたる例だと思うが。

130 ：デフォルトの名無しさん：2008/05/13(火) 00:22:48

CとC++/C#/Javaなんて唯の兄弟喧嘩だろ
しかも偉大な兄(C)を越えられない
Cを駆逐するなら、全く別のアプローチしか無い

131 ：デフォルトの名無しさん：2008/05/13(火) 00:26:02

超えようと機能を追加していったのがC++で、別のアプローチのつもりが
気がついたらナナメ上だったのがJAVAだと。

132 ：デフォルトの名無しさん：2008/05/13(火) 00:28:09

C言語なんてハードウェアよりじゃないかぎり使う方が馬鹿だと思うが。

133 ：デフォルトの名無しさん：2008/05/13(火) 00:30:32

つまり Apache はハードウェアよりと…

134 ：デフォルトの名無しさん：2008/05/13(火) 00:33:34

ハードウェア寄りじゃ無い場面で、Cの幻影を引き摺ってる言語を使ってる
時点でダメだよな。

135 ：デフォルトの名無しさん：2008/05/13(火) 00:35:09

世間はそう思ってないみたいだが、どうなのよ？

136 ：デフォルトの名無しさん：2008/05/13(火) 00:37:24

ちなみに Perl も Python も Ruby も SpiderMonkey も Tcl/Tk も C だよね

137 ：デフォルトの名無しさん：2008/05/13(火) 00:40:26

フリーの言語処理系だけ並べられても

138 ：デフォルトの名無しさん：2008/05/13(火) 00:40:42

>>134
Java が出なければ SML が主役になる筈だったと言ってる人が居たけど…

139 ：デフォルトの名無しさん：2008/05/13(火) 00:43:22

>>137
ハードウェアよりじゃない所で、実装言語を確認出来る良い例だから。

140 ：デフォルトの名無しさん：2008/05/13(火) 00:46:04

STLが無いってだけでC言語は糞だろ。
生産性の無い言語は現場から去るべき。

141 ：デフォルトの名無しさん：2008/05/13(火) 00:47:31

マルチプラットフォームでパフォーマンスが求められるとどうしてもCになるねえ

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

142 ：デフォルトの名無しさん：2008/05/13(火) 00:47:33

C++が糞じゃなかったらとっくに現場から去ってるって

143 ：デフォルトの名無しさん：2008/05/13(火) 00:48:26

PerlとTclはちょっと違うな。
Cも含めた闇鍋風バカ言語。もちろん良い意味で。

144 ：デフォルトの名無しさん：2008/05/13(火) 00:58:21

STLが無いと生産性の上らない>>140は現場から・・・

145 ：デフォルトの名無しさん：2008/05/13(火) 01:00:52

>>144の苦しい言い訳とか、Cが如何に使えないかよくわかる。

146 ：デフォルトの名無しさん：2008/05/13(火) 01:01:11

STLなめんな。

147 ：デフォルトの名無しさん：2008/05/13(火) 01:03:09

未だにテンプレート禁止のところもあるというのに

148 ：デフォルトの名無しさん：2008/05/13(火) 01:03:22

ちょ、子供の喧嘩は勘弁な

149 ：デフォルトの名無しさん：2008/05/13(火) 01:13:09

>>141
今やCの守備範囲とFortran,COBOLが生き残ってるところは、ほとんど被ってないからなぁ
Fortanを駆逐するのは(可能がどうか別にして)Camlでいいと思うが、COBOLは何だろう？

150 ：デフォルトの名無しさん：2008/05/13(火) 01:13:27

つーかこの急激なスレの伸びはなんなのよｗ

151 ：デフォルトの名無しさん：2008/05/13(火) 01:18:03

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

152 ：デフォルトの名無しさん：2008/05/13(火) 01:29:53

そこで組み込みスクリプト言語ですよ

153 ：デフォルトの名無しさん：2008/05/13(火) 02:02:19

>>151
finallyも使いやすいとは思えないけどな。
C#のusingとかDのscopeとかみたいな仕組みくらいのほうがいい。
C++デストラクタもまああり。

154 ：デフォルトの名無しさん：2008/05/13(火) 05:06:38

C++はネイチブ生成の宿命があるのに
その場合エラー専用処理がものすごく非効率って問題が

155 ：デフォルトの名無しさん：2008/05/14(水) 09:01:09

>>153
んなもんケースによるだろ。
ケースによるのにfinallyがないのが糞なんだよ。

156 ：デフォルトの名無しさん：2008/05/14(水) 09:42:43

finally相当の機能なら、C++/CLIでついたんじゃなかったっけ?

157 ：デフォルトの名無しさん：2008/05/14(水) 10:34:32

まるでC++/CLIがC++の後継みたいな言い方だな

158 ：デフォルトの名無しさん：2008/05/14(水) 13:30:06

C++/CLIはC++じゃない

159 ：デフォルトの名無しさん：2008/05/14(水) 15:37:48

>>150
それだけみんなCに不満もってるってことだ。
総力を挙げて潰さないとこの業界に未来はないよ。

160 ：デフォルトの名無しさん：2008/05/14(水) 16:04:13

形式仕様から、最終的にバイナリコード(FPGAベースのチップ向けの)を
生成する研究が実用化されれば、Cだけでなく、現状のほとんどの言語を使わなくなる。

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

161 ：デフォルトの名無しさん：2008/05/14(水) 20:24:35

問題領域向けのDSLを記述+DSLで動作記述
↑
これのコンパイラは結局Cでかかれると。

162 ：デフォルトの名無しさん：2008/05/14(水) 20:27:14

最近は言語処理系は関数型言語か C++ で書くのが流行の様だよ
C++ がもう少しまともだったらな

163 ：デフォルトの名無しさん：2008/05/14(水) 20:29:28

コンパイラはリッチな環境の上で動かせるから選択肢の数が全然違う

164 ：デフォルトの名無しさん：2008/05/14(水) 20:57:24

C言語で開発しとけばなんかあったとき安心、見たいのがあるのかね？
性能をどうしてもあと１０％上げなきゃいけない、なんてときもCなら何とかなるとか。

165 ：デフォルトの名無しさん：2008/05/14(水) 21:02:28

Cで書いた所でそれ程ハードルが高くなる訳じゃない
特に拘りがないだけじゃないの

166 ：デフォルトの名無しさん：2008/05/14(水) 21:33:09

俺はCだとハードルかなり高くなる。
それで飛び越えられなくなるわけじゃないとしても、いちいち高めにジャンプしなきゃいけないのがむかつく。

167 ：デフォルトの名無しさん：2008/05/14(水) 21:47:37

コンパイラをCで書くとか、嗜虐癖があるとしか思えん

168 ：デフォルトの名無しさん：2008/05/14(水) 21:49:54

>>164
C で書いておけば色んな言語と混ぜられる。
C のルーチンを LL から呼び出すのは至極楽ちん。

169 ：デフォルトの名無しさん：2008/05/14(水) 22:07:14

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

170 ：デフォルトの名無しさん：2008/05/14(水) 22:15:07

CはLLのインラインアセンブラや〜

171 ：デフォルトの名無しさん：2008/05/14(水) 22:35:22

>>168
C#とPowerShellその他.NETなLLの親和性は異常
CというかシステムコールをOOなLLでラッピングとかもう面倒でやってらんない

172 ：デフォルトの名無しさん：2008/05/14(水) 23:56:55

何でシステムコールが出てくる？
シスコール生で叩かせるLLなんてあるのか？

173 ：デフォルトの名無しさん：2008/05/14(水) 23:57:26

>>171
そういえば、.NETってなんとなくスルーしてたなぁ。
趣味として使うとしたら学ぶ価値ある？
普段はRuby使ってます。

174 ：デフォルトの名無しさん：2008/05/14(水) 23:58:22

>8
＞Cのパフォーマンス
これほんと？

175 ：デフォルトの名無しさん：2008/05/15(木) 00:07:41

>>174
C だけ使えば C と同じ性能。
C++ でもよく使われる言い回し。

176 ：デフォルトの名無しさん：2008/05/15(木) 01:35:36

>>174
例えばある変数の値を、1から10000までカウントupみたいなのは、Cは高速。

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

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

↓参考:プログラミング言語ベンチマーク
ttp://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=all

177 ：デフォルトの名無しさん：2008/05/15(木) 02:38:24

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

178 ：デフォルトの名無しさん：2008/05/15(木) 02:43:57

>>88
人を変態よばわりしないでください。
R6RS準拠のコンパイラがでたんですって？

179 ：デフォルトの名無しさん：2008/05/15(木) 08:35:10

Cに文句言うより86アセンブラをまず駆逐しろよ・・・
Intelでさえできなかったんだぞ

180 ：デフォルトの名無しさん：2008/05/15(木) 08:37:36

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

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

181 ：デフォルトの名無しさん：2008/05/15(木) 13:54:39

>173
> そういえば、.NETってなんとなくスルーしてたなぁ。
> 趣味として使うとしたら学ぶ価値ある？

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

182 ：173：2008/05/15(木) 18:43:57

>>181
レスさんくす。
C#でもかじってみるか。
（そういえばIronRubyはどうなったんだ？とんと話を聞かないが。）

183 ：デフォルトの名無しさん：2008/05/16(金) 18:44:40

開発言語をアセンブラからCに変えて解放されることって

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

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

184 ：デフォルトの名無しさん：2008/05/16(金) 18:54:16

とりあえずage

185 ：デフォルトの名無しさん：2008/05/16(金) 19:23:40

CはどんなCPUでも同じ文法で動く、“共通アセンブラ”みたいな位置づけ。
他の言語と比べること自体がナンセンス。 もう機能追加とかしない方がいい。
CにはOOだのGCだの必要なし。それはLLとかに任せればいい。

186 ：デフォルトの名無しさん：2008/05/16(金) 19:30:17

namespaceとstructに関数ぶら下げるのとoverloadがあると気分的にだいぶ楽になるな。
IDEとの親和性も爆上がるし。

187 ：デフォルトの名無しさん：2008/05/16(金) 19:42:34

>>185
ただ、cppにはもうちょっと賢くなってほしいけどなあ。

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

188 ：デフォルトの名無しさん：2008/05/17(土) 00:00:28

>>183
Cはメモリーもスタックも管理しないだろ

189 ：デフォルトの名無しさん：2008/05/17(土) 00:07:03

自動変数の事じゃないの

190 ：183：2008/05/17(土) 00:20:31

スタックの管理は自動変数、
メモリーの管理はmalloc&free,大域変数のつもりで書いた。

191 ：デフォルトの名無しさん：2008/05/17(土) 11:00:14

OO言語としてC++は置いといて高級アセンブラとしてCを凌駕する
ポストC的な言語がほとんど話題にならない時点で結論が出ているわけだが。

192 ：デフォルトの名無しさん：2008/05/17(土) 12:10:51

c++を駆逐してほしいんだが

193 ：デフォルトの名無しさん：2008/05/17(土) 12:38:39

学習コスト＜＜駆逐コスト

194 ：デフォルトの名無しさん：2008/05/17(土) 13:08:01

>>191
高級アセンブラが使われる環境を駆逐したいんじゃない？

195 ：デフォルトの名無しさん：2008/05/17(土) 13:17:15

入れ子が{}じゃなくて
ポインタが*じゃないC言語ください

196 ：デフォルトの名無しさん：2008/05/17(土) 13:35:32

なぜ組み込みの世界であんなに C++ が嫌われるのか理解できない。
些細なデメリット避けるために大きなメリットを失っている。

197 ：デフォルトの名無しさん：2008/05/17(土) 13:53:06

The C Programming Language 274ページ

http://www.amazon.co.jp/Programming-Language-Version-Prentice-Software/dp/0131103628

The C++ Programming Language 1030ページ

http://www.amazon.co.jp/C-Programming-Language-Bjarne-Stroustrup/dp/0201700735

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

198 ：デフォルトの名無しさん：2008/05/17(土) 13:53:49

>>192
今田舎に別荘を建てて隠遁する準備が進んでいるよ
200x 年には完成する見込みらしい

199 ：デフォルトの名無しさん：2008/05/17(土) 14:01:51

>>196
C++ は遅い・複雑・でかいの3重苦だから組み込みには向いていない
特にリンクやロードが遅いのは致命的

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

200 ：デフォルトの名無しさん：2008/05/17(土) 14:37:41

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

201 ：デフォルトの名無しさん：2008/05/17(土) 14:51:55

>>200
>リンクやロードが遅い理由はよく分からないが、それは言語の問題じゃないん
>じゃない?

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

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

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

202 ：デフォルトの名無しさん：2008/05/17(土) 15:39:45

そういうのはいいから説明してくれよ

203 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/05/17(土) 19:13:25

dhrystone で測れるのはループの中の計算時間だけだからね

205 ：デフォルトの名無しさん：2008/05/17(土) 19:27:25

ループの中で結構関数呼び出しもしてるよ。

206 ：デフォルトの名無しさん：2008/05/17(土) 19:28:51

リンクやロードも?

207 ：デフォルトの名無しさん：2008/05/17(土) 20:04:19

>>200
C+αなんかではなく、ポテンシャル全開でC++を使うときの
コンパイル・リンクの遅さの原因の半分は言語仕様だと思う。
残りの半分は実装の問題。

208 ：デフォルトの名無しさん：2008/05/17(土) 21:51:56

＋αでない残りのポテンシャルの部分って具体的に何よ？
例外とか？

209 ：デフォルトの名無しさん：2008/05/17(土) 21:54:58

テンプレートじゃね？

210 ：デフォルトの名無しさん：2008/05/17(土) 23:04:00

>>206
リンクは C が 0.10257s で C++ が 0.10281s です。
ロードは Windows の場合だと実行と切り離せないのでうまい計測方法が分かりません。

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

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

211 ：デフォルトの名無しさん：2008/05/18(日) 01:34:45

>>195
入れ子が begin end,
ポインタが ^ でもいい？

212 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/05/18(日) 11:03:42

VC は優秀だな。

215 ：デフォルトの名無しさん：2008/05/18(日) 12:21:33

いろんな分野でC++はPythonに置き換わりつつあるな
Rubyなんてのを与えられた日本人は世界から置いてけぼり

216 ：デフォルトの名無しさん：2008/05/18(日) 12:30:09

何のスレだここは

217 ：デフォルトの名無しさん：2008/05/18(日) 13:43:40

cソースはcppソースに変換後にコンパイルされるんだが。

218 ：デフォルトの名無しさん：2008/05/18(日) 14:59:17

cpp ってCプリプロセッサのこと?
確かに gcc はそういう手順になっていると思います。

219 ：デフォルトの名無しさん：2008/05/18(日) 16:06:49

>>214
C コンパイラが C++ 並みに遅いのは優秀とは言えないと思うけど…
アセンブラ出力かシンボルダンプが見てみたいね

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

220 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/05/18(日) 19:32:20

>>220
ちゃんと C++ としてコンパイルしてる?
共有ライブラリのリンク情報かシンボルダンプかアセンブラ出力か、
何でも良いけど晒してみて。最適化オプション無しだとどうなる?

222 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/05/19(月) 00:33:34

tccを使えば解決、と言ってみる。
ttp://alohakun.blog7.fc2.com/blog-entry-667.html

224 ：デフォルトの名無しさん：2008/05/19(月) 00:46:36

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

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

225 ：デフォルトの名無しさん：2008/05/19(月) 14:40:12

>>224
OS というよりもほとんどの場合コンパイラとリンカで決まると思います。
(Windows の場合は実行時の最適化もやりかねないけど)

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

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

226 ：デフォルトの名無しさん：2008/05/19(月) 20:31:42

その駄目コンパイラ…
気になる…

227 ：デフォルトの名無しさん：2008/05/20(火) 13:43:51

>>201

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

C++の設計と進化
ttp://www.amazon.co.jp/C-%E3%81%AE%E8%A8%AD%E8%A8%88%E3%81%A8%E9%80%B2%E5%8C%96-%E3%83%93%E3%83%A7%E3%83%BC%E3%83%B3-%E3%82%B9%E3%83%88%E3%83%A9%E3%82%A6%E3%82%B9%E3%83%88%E3%83%A9%E3%83%83%E3%83%97/dp/4797328541

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

228 ：デフォルトの名無しさん：2008/05/20(火) 18:25:10

あーその本、もってるけど全然読んでないな。
ちゃんと読んでみるかな。

229 ：デフォルトの名無しさん：2008/05/20(火) 18:59:36

>>227
C++は遅いし、コンパイラの事を知らない人間が作った言語だよ。

230 ：デフォルトの名無しさん：2008/05/20(火) 19:08:21

AT&T に居たんだから Aho なりに相談すれば良かったのにな

231 ：デフォルトの名無しさん：2008/05/20(火) 19:08:45

暴言ｷﾀ━━＞▽＜━━━

232 ：デフォルトの名無しさん：2008/05/20(火) 19:15:22

いやだってやたらと信じやすい人が居たから…
C++ をマンセーするのも良いけど程々にね

233 ：デフォルトの名無しさん：2008/05/20(火) 19:37:24

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

234 ：デフォルトの名無しさん：2008/05/20(火) 20:21:11

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

235 ：デフォルトの名無しさん：2008/05/20(火) 20:23:45

>>234
下2行は禿上がる程同意。その言い訳も>>227の本に書いてあるかな？

236 ：デフォルトの名無しさん：2008/05/20(火) 21:42:19

GLS がストラウストラップ 1/10 でも現実を見ていれば
あんなアプリケーションの起動が糞遅くなる事も無かっただろうさ。

237 ：デフォルトの名無しさん：2008/05/20(火) 22:08:58

C のどこが起動が遅いって?

238 ：デフォルトの名無しさん：2008/05/20(火) 22:15:11

なんでCが出てくるんだ

239 ：デフォルトの名無しさん：2008/05/20(火) 22:20:34

>>238
GLS 知らんのか?

240 ：デフォルトの名無しさん：2008/05/20(火) 22:27:31

ぐぐったら、
予備校とサーバとガラステレビ台が出て来た語学センターとガールズラブサーチってのが出て来た

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

241 ：デフォルトの名無しさん：2008/05/20(火) 22:32:21

起動は?

242 ：デフォルトの名無しさん：2008/05/20(火) 22:50:13

>>225
>OS というよりもほとんどの場合コンパイラとリンカで決まると思います。

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

243 ：デフォルトの名無しさん：2008/05/20(火) 23:29:12

>>239
Guy L Steel Jr.の事だと思って読んだけど違うの？

244 ：デフォルトの名無しさん：2008/05/20(火) 23:36:44

なら、そんな疑問は浮かばないだろ

245 ：デフォルトの名無しさん：2008/05/20(火) 23:39:59

Guy L Steel Jr.とC言語の関係が分からん

246 ：デフォルトの名無しさん：2008/05/20(火) 23:40:27

ガイ・スティールと聞いてJavaを最初に思い出したとか？＞起動が糞遅く
まあ言語仕様の著者ではあるが無理感じるな

247 ：デフォルトの名無しさん：2008/05/20(火) 23:41:17

>>245
ANSI標準化

248 ：デフォルトの名無しさん：2008/05/20(火) 23:41:51

なぜSchemeが出ない

249 ：デフォルトの名無しさん：2008/05/20(火) 23:42:17

つか、何で知らないなら調べようとしないかね…

250 ：デフォルトの名無しさん：2008/05/20(火) 23:44:46

>>247
すまん、もうちょい詳しく

251 ：デフォルトの名無しさん：2008/05/20(火) 23:47:14

ググっても出てこないのはSteelじゃなくてSteeleだからだ

252 ：デフォルトの名無しさん：2008/05/20(火) 23:56:40

>>235
書いていないな。

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

253 ：デフォルトの名無しさん：2008/05/21(水) 00:02:40

テンプレートこそC++の特徴であり価値の一つだと思うんだけど

254 ：252：2008/05/21(水) 00:09:26

>>253
そりゃそうだ。テンプレートなしでC++使うなんて気にはなれないし、
実際、そんな機会は全然ないから
「Cと比べて気になるほどなるとは思えない」というのは自分の想像でしかない。
すれ違いすまん。

255 ：デフォルトの名無しさん：2008/05/21(水) 00:20:09

C++ に無理矢理似非クロージャを入れて喜んでるくせに GLS も知らないんだよな…

256 ：デフォルトの名無しさん：2008/05/21(水) 01:45:37

そもそもGLSって略称一般的かなあ

257 ：デフォルトの名無しさん：2008/05/21(水) 01:56:54

スティールが設計に深く関わった高性能な言語は Fortress ぐらいしかないんじゃない?

258 ：デフォルトの名無しさん：2008/05/21(水) 02:13:36

>>235
D&E 15.10 あたりで問題は認識しいるようですよ。
最近のコンパイラはプリコンパイルヘッダーや簡易ビルドの技術が発達しているので
ずいぶん良くなったと思います。
モジュール分けしてそれぞれの依存度を少なく設計すればそれほどストレスを感じません。

259 ：デフォルトの名無しさん：2008/05/21(水) 07:38:05

>>258
他の言語だってモジュール分けすればもっと速いよ
C++ と違って小細工しなくても常識的な速さだけど

260 ：デフォルトの名無しさん：2008/05/21(水) 08:31:09

まあビルドの速い言語ほどその後の処理負担が大きいけどな。ユーザーが多いほどコストが増大。

261 ：デフォルトの名無しさん：2008/05/21(水) 08:57:38

C++が遅いのは文法の問題だから一般的なまともな言語と比較しても意味無い。

262 ：デフォルトの名無しさん：2008/05/21(水) 09:10:21

>>261 詳しく。
>>259 モジュール分割や依存度下げは小細工かよ。まあ前方宣言はそうかもしれないが。

263 ：デフォルトの名無しさん：2008/05/21(水) 09:20:06

C/C++は糞。
Cは必要悪だがC++は必要ですらない。

264 ：デフォルトの名無しさん：2008/05/21(水) 14:58:16

ベターCとしてのC++は悪くない

ただたまに勘違いしたやつがいらんところで、継承とかテンプレートを
使いまくる。

265 ：デフォルトの名無しさん：2008/05/21(水) 16:41:10

プロファイルを定義して違反したらコンパイル時にエラーか警告出すような
機能を付けてくれないかな。

266 ：デフォルトの名無しさん：2008/05/21(水) 17:59:57

ほほう、それでC++が晴れてベターCになれると。

267 ：デフォルトの名無しさん：2008/05/21(水) 19:36:41

>>266 問題点を指摘して、もっといい方法を教えてください。

268 ：デフォルトの名無しさん：2008/05/21(水) 20:26:33

>>262
>>>261 詳しく。

http://www.nobugs.org/developer/parsingcpp/

C++ 使いって基本的に自分で調べたり勉強したりしないよな…
まあだからこそ未だに C++ をマンセー出来るんだろうけど

269 ：デフォルトの名無しさん：2008/05/22(木) 03:03:43

全体のビルド時間に占める構文解析の時間はそんなに大きいものかね？
第一 C++ の構文解析を複雑にしているのはほとんど C の文法を引き
ずっている部分だよ。D&E を読めば構文解析に配慮していることが分
かるよ。

270 ：デフォルトの名無しさん：2008/05/22(木) 03:10:14

配慮はしてるけど何もしてないってことだろ。俺も自分がニートなのに配慮してる
けど特に就職活動とかしてない

271 ：デフォルトの名無しさん：2008/05/22(木) 03:10:59

>C++ の構文解析を複雑にしているのはほとんど C の文法を
>引きずっている部分だよ
Cからすれば勝手に引き摺って勝手に泥沼に走り去った後ろ姿しか見えない訳で。

ようも色々余計な物引き摺って、そんな泥沼に邁進してるなと。

272 ：デフォルトの名無しさん：2008/05/22(木) 14:36:52

言語屋からの賛成を得てC文法の良くないところを直そうとしたがユーザーから
猛反発食らってあきらめた。現実ばかりを見て理想を追いかけない駄目な設計者。

273 ：デフォルトの名無しさん：2008/05/22(木) 14:54:56

デファクトスタンダードと言う言葉を送ろう。
最近の悪例　Windows　　別に利用者がダメとは思わない。

274 ：デフォルトの名無しさん：2008/05/22(木) 18:38:08

さらに彼の欠点はコンパイラの実装者よりも言語ユーザーを重視した設計をすることだ。
EC++ の設計を見習うべきです。

275 ：デフォルトの名無しさん：2008/05/24(土) 21:04:40

つまりCをつかってりゃよかったって話なのか？

276 ：デフォルトの名無しさん：2008/05/26(月) 00:11:25

その通り。
ためしにCを知らない新人にいきなりC++を勉強させてみるとよい。
C++のプログラムを作らせるとCを知らないはずがCスタイルになる。
つまりCは人間の直感に合っているのだ。

277 ：デフォルトの名無しさん：2008/05/26(月) 00:29:03

言いたいことは分かる気がする。

俺1人でプログラムを書くと、核となる処理は結局、手続き型。
ただ、OOP言語だと、その部分をうまく書くために、
いろんなクラスを書くという感じになる。

278 ：デフォルトの名無しさん：2008/05/26(月) 07:31:34

赤ん坊を無人島に放置して勝手に育ってｾｯｸﾙのやり方もわからない状態を
人間の直感にあってるとか言われてもねぇ

279 ：デフォルトの名無しさん：2008/05/26(月) 10:32:00

>>276
「数学を学ばないと未知数を x と書かずに○と書く」みたいな話だな。
「抽象的なものは勉強すべき」ということは欠点でもなんでもないんじゃないの？

280 ：デフォルトの名無しさん：2008/05/26(月) 17:37:34

>>276
そんなに直感にあった言語だったら今頃大学生は皆Cが書けるように
なってるはずだが。

それどころか現実は日本の技術者激減で国家滅亡の危機なわけだが

281 ：デフォルトの名無しさん：2008/05/26(月) 18:20:57

古い言い伝えを思い出すな。

紀元前七世紀、エジプト王プサメティコス一世は臣下に命じ、生まれたばかりの赤ん坊を一切のプログラミング言語とは無縁に育てさせた。
そして赤ん坊がある程度大きくなった時、ある質問をした。
「"Hello world"はどう記述する？」
答えて曰く「# include <stdio.h>
int main(void) {printf("Hello, world!\n"); return 0;}」
王はC言語が最古のプログラミング言語だと確信したという……。

282 ：デフォルトの名無しさん：2008/05/26(月) 18:35:03

AとBはどこ行った?w

283 ：デフォルトの名無しさん：2008/05/26(月) 19:40:52

勝手に確信する分には別に構わんが、言い伝えるのは勘弁してほしいな

284 ：デフォルトの名無しさん：2008/05/26(月) 22:53:10

駆逐できそうにないですね

285 ：デフォルトの名無しさん：2008/05/26(月) 23:09:44

>281
俺が3丁目の角のタバコ屋の長老から聞いた話だと、その王様がCで
バベルの塔問題を解かせようとプログラミングをしていたら、OOPの神様が
お怒りになり、kill -9の雷を降らせ、以降言語がC++やらObjective Cやら
JAVAやらC#やら諸々へと分裂していったと。
そして、崩れ落ちるcoredumpの中で最後に残っていたのがCshだったそうな。

286 ：デフォルトの名無しさん：2008/05/26(月) 23:23:47

>>276
素人の直感は専門家の正しい知見から180度ずれるという宇宙的な法則があってだな･･･
たとえば、システムヘッダの中で、アンダーバーで始まる名前が
多用されているのを見て、そのまま真似したりする。
30度でも90度でもなく180度だ。これは物理的な必然だ。･･･いや、忘れてくれ･･･

287 ：デフォルトの名無しさん：2008/05/27(火) 09:00:15

そして、C++のOOPを覚えたと思ったら、また180度ずれて、トータル360度ずれて元に戻る。
まさに真理の哲学ですね。

288 ：デフォルトの名無しさん：2008/05/27(火) 20:27:43

CプログラマがC++を使わない理由を探す理由を知りたい。

289 ：デフォルトの名無しさん：2008/05/27(火) 20:47:04

その前に>>288がなぜそんなことを聞くのか理由を知りたい

290 ：デフォルトの名無しさん：2008/05/27(火) 20:50:18

>>288組み込み系では、Cが最適開発環境であることは多い。

291 ：デフォルトの名無しさん：2008/05/27(火) 21:49:33

CプログラマってCだけしか使ってない人？そんなひといるのかな。
少なくともLLの一つや二つは使ってるでしょ。C++は要らないけど。

292 ：デフォルトの名無しさん：2008/05/27(火) 22:07:11

C言語と日本語と英語が使えます。

293 ：デフォルトの名無しさん：2008/05/27(火) 23:42:22

その昔、asahi.comでの求人でプログラマ職若干名ってのがあってね、そのときの
条件ってのが「言語: C言語(日常会話レベル)」だったってのが冗談じゃなくてあった。

職場で同僚とためしに「 printf("hello, world!\n");」「break;」とやってみたが、
ゴメン、俺には無理だわと応募をあきらめた。

294 ：デフォルトの名無しさん：2008/05/27(火) 23:58:49

うちの場合は
「CよりC++のほうがいいのは分かったよ、でも使いません」
のような感じでいつも終わってしまう。

295 ：デフォルトの名無しさん：2008/05/28(水) 00:17:12

考えるのがめんどくさい
息をするのもめんどくさい

296 ：デフォルトの名無しさん：2008/05/28(水) 00:20:34

ゆうちゃんとめんどくさいさい

297 ：デフォルトの名無しさん：2008/05/29(木) 20:16:05

組み込みで使うとかいわれても幅が広くてわかりにくいんだが
携帯ゲーム機用ソフトとかもCで組んでたりすんの？

298 ：デフォルトの名無しさん：2008/05/29(木) 20:44:31

GBAのときはCの方がC++より多かったと思う。今は分からない。

299 ：デフォルトの名無しさん：2008/05/29(木) 21:27:12

なるほど、GBA⇒DSだと性能差は十倍にもなってない感じだし
まだCが多かったりするんだろか。PS3が組み込み系に分類されてたり
携帯電話を組み込み系と言ったら笑われたり、俺にはよくわからん

300 ：デフォルトの名無しさん：2008/05/29(木) 22:48:42

>>299
>携帯電話を組み込み系と言ったら笑われたり

そうなの？　カーナビと携帯は組み込みの2大巨頭だと思ってたよ。

301 ：デフォルトの名無しさん：2008/05/29(木) 23:55:42

「JavaVM乗るような潤沢な環境を組み込みと言うかｗｗ」
っていう考えの人も居るっていうだけの話だが、
実際組み込みって言葉はピンキリで随分曖昧な気がする

302 ：デフォルトの名無しさん：2008/05/30(金) 00:39:26

>組み込みで使うとかいわれても幅が広くてわかりにくいんだが

幅が広いからCでないと厳しい環境もあるっていうんじゃダメかね？
オレが今取りかかってるシステムはRAMが32Kしかないんだが
Cとアセンブラ以外使おうとは思わないよ。とにかくリソースがぎりぎり。
処理時間、セクションやスタックの使用量とかも仕様で出さなきゃならんしな。
必ずしもプロファイラがあるわけでもないし。

303 ：デフォルトの名無しさん：2008/05/30(金) 01:27:45

>301
大量に生産するため、リソースを贅沢にすることは即コストに直結する。
開発コストよりも製造コストが重視される。それが量販製品における
組み込み系の特徴の一つ。携帯電話はこれが極端に当てはまる。
JVMが乗っかるのは潤沢な環境なのではなく、それがために他にくるしわ寄せを
吸収しなければならない分、余計につらいってことだね。

正直、いくら携帯電話の機能が大きくなったといっても、本当にリソースが
豊富に使えるなら、基本が機能追加でコードの流用が効く携帯で、毎度毎度
あそこまでデスマにはならない。

304 ：デフォルトの名無しさん：2008/05/30(金) 01:42:25

アセンブラで組むのが一番だと思うが、極端に可読性が落ちる。
C++だと余計なことをしてくれて自分が望むアセンブラに展開してくれない。
だからC。

305 ：デフォルトの名無しさん：2008/05/30(金) 18:08:50

C++ が C と比較してコンパイル結果を予想しにくくしているものは以下のよう
なものがあると思う。逆にこれらを使わなければほぼ予想通りのコンパイル結果
になるはずだ。

- 非 static メンバー関数の暗黙の this の存在
- コンストラクタからの基本クラスとメンバ変数のコンストラクタ自動呼び出し
- デストラクタからの基本クラスとメンバ変数のデストラクタ自動呼び出し
- 静的変数のコンストラクタとデストラクタの呼び出しとそのタイミング
- コンストラクタを持つ静的局所変数の暗黙の初期化チェック
- 自動変数のデストラクタの呼び出し
- 暗黙の型変換の呼び出し
- 一時オブジェクトのデストラクタの呼び出し
- 仮想関数の呼び出しオーバーヘッド
- 実行時型情報の時間コストと空間コスト
- 多重継承と仮想基本クラスによるオーバーヘッド
- メンバーポインタ操作の時間コスト
- 例外処理の時間コスト (特にデストラクタを持つ自動変数が存在するとき)
- inline 関数の出力コード (ただし大域最適化したときはCでも同じ)
- 複雑なテンプレートの出力コード
- 実体を持たない const 変数がある (ただし大域最適化したときはCでも同じ)

306 ：デフォルトの名無しさん：2008/05/30(金) 18:09:21

C++ に慣れてくれば上のような機能を使っても C 並にコンパイル結果を予想
できるようになってくる。ただし複雑なテンプレートの出力コードの予想はか
なり難易度が高い。
C でもがんばれば上のような機能を実現できるが、結局 C++ の速度と変わら
なくなってしまうはずだ。そのようなソースコードのメンテナンスはよほどの
天才でないとできないと思う。

自分が考える C++ の欠点は
- 複雑なテンプレート使用時のコンパイル時間
- テンプレートと名前空間により中間ファイルのサイズが膨張
- コンパイラのバージョン間で ABI が変わりやすい
- 仕様が大きいので学習が大変

307 ：デフォルトの名無しさん：2008/05/30(金) 21:23:52

さらに C++ の欠点の追加
- 標準準拠度の高いコンパイラが少ない (特にテンプレート)
- テンプレート関連のエラー表示が分かりにくい

308 ：デフォルトの名無しさん：2008/05/30(金) 21:38:24

C++の一番の欠点は、そうやっていちいち他の言語に対する「自分が有利と思う点」を
開陳してまわらないと気がすまない、鬱陶しい奴が多いことだろう。

309 ：デフォルトの名無しさん：2008/05/30(金) 21:53:45

ピアソンやオライリーの本に書いてあることを垂れ流してるだけじゃね？
スレの流れのリソースが厳しい環境での答えにもなってなければ
スレの主題への評価にもなっていない。

310 ：デフォルトの名無しさん：2008/05/30(金) 21:56:59

>>308
どのレスの話？

311 ：デフォルトの名無しさん：2008/05/30(金) 22:19:31

>>308 それは言語の欠点ではなく俺の欠点だ。

>>309 ピアソンやオライリーの本はよく読んでいるから影響を受けているに違いない。
しかしこれ以外の本よく読んでいる。

コンパイル結果を予想できればある程度必要なリソースの見積もりが可能だ。
そしてリソース消費がCとほとんど変わらないプログラムをC++で作れる。
さらにバイト単位でリソース消費を抑えたければ最適化無しのアセンブラで組むしかない。

C++がCの代わりになるかもしれないことを主張しているのだからそれほどスレの
主題から離れていないだろ。

312 ：デフォルトの名無しさん：2008/05/30(金) 22:30:05

>>305
>逆にこれらを使わなければ

C でオケ

313 ：デフォルトの名無しさん：2008/05/30(金) 23:15:52

>>312
だな。>>305をコーディング規約にでも書いた日には
「Cでいいじゃねえか!!」と言われそう。

314 ：デフォルトの名無しさん：2008/05/30(金) 23:57:34

Cがこれだけ普及したのは、あまり抽象化しなかったから。
このCに抽象化の手術を施したのが、C++でありJavaでありC#等々。
基本的に無理筋なんだ。

315 ：デフォルトの名無しさん：2008/05/31(土) 01:04:39

抽象化＝クラスと信じて疑わないのがきもい

316 ：デフォルトの名無しさん：2008/05/31(土) 01:25:34

>>312, >>313

>>305を使わなくてもCより遥かに安全で保守が容易なプログラムを作れるようになるのだ。
さらに iniline 関数と const 変数(最後の項目)を使えば安全かつ効率のいいものを作れる。
後は徐々に使う機能を増やしていけばよい。
特にデストラクタの利用は効果的だ。

317 ：デフォルトの名無しさん：2008/05/31(土) 02:27:19

>>313

実は>>305は最後の項を除くと割りと簡単にルールを説明できる。

- コンストラクタ、デストラクタ、非 static メンバー関数を定義しない
- 多重継承を使わない
- 演算子 .* と ->* を使わない
- try, catch, throw を使わない
- inline 関数を定義しない
- template を使わない

最後の項は基本的にうれしいことなので、あえて使いたくないときは
extern を使うなり、アドレスを取得するなりすればよい。

318 ：デフォルトの名無しさん：2008/05/31(土) 03:05:12

>>316
>Cより遥かに安全で保守が容易なプログラムを作れるようになるのだ。

ﾜﾗﾀw

319 ：デフォルトの名無しさん：2008/05/31(土) 04:46:23

・安全で
・保守が用意
共にどこまで把握したことを活用できるか、という問題じゃん？
煽り地味た笑いは早計かと思ふ。

でもC++を一人で神経質にやってもそうはいかんという経験自体は誰もが持ってるだろうしな
共同作業時の問題とか考えると尚更なあ
OOPの幻想
デザインパターン振り回してテンプレート禁止とか言い出すSmalltalk厨の上司
JavaScriptなんて素人の言語だとか時代遅れな事いいやがって
手前の遅刻を棚に上げて帰るのが早過ぎるとかどの面下げて言う
間違った仕様書いといて実装に逆切れしやがって　徹夜して直すと自己管理ミスとかもうね
原付のブレーキ切ったろか
切るべきか　切るべきだな　けけけけけけ

>>316
ﾜﾗ太

320 ：デフォルトの名無しさん：2008/05/31(土) 05:15:39

C++否定側の皮肉なジョークだろ？>>305,>>316

321 ：デフォルトの名無しさん：2008/05/31(土) 14:01:59

すこし見ていないうちに話のレベルが少し上がっているな（笑）。まあ、
「新規の言語はすべて旧来の言語のアンチテーゼ」
ある時点で一気に主流になった言語を駆逐するのもそう簡単ではないだろ。
新たな概念も良いけど「誰でも理解できる」という条件を満たさないと意味がない。
「誰でも理解できる」「簡潔に書ける」「効率」等の条件を満たさないと・・・
考えているうちに「自分が生きている内に駆逐されるなら、是非それを経験したい」と思ったよ。

322 ：デフォルトの名無しさん：2008/05/31(土) 19:51:13

>>321
駆逐されたと言う基準はなんだ?
COBOLやFORTRANは駆逐されたのか?
君の生まれる遥か前に生まれたと思うぞ、FORTRANは51歳で未だに現役だ。

323 ：デフォルトの名無しさん：2008/05/31(土) 20:09:07

>>320 決してジョークではない

今までの流れからCプログラマ(特に組込み系)のC++に対する懸念は以下の2つと考えている。
- 生成されるコードが大きくて遅い(例えベターCとして使っても)
- 暗黙の処理によって生成されるコードやリソースが予想しにくい

コードの大きさと速さに関しては、ゼロオーバーヘッドルールによってCのソースコードを
C++コンパイラでコンパイルしてもほぼ同じになると考えてよい。
(ただし最適化の出来が悪いとそうならないときがある)
しかもC++はCとの(道理にかなった)非互換性を選択したことでCの危険なプログラムを
エラーにすることができる。特にコンパイル時とリンク時の型安全の検査は有名だ。

予想しにくい件に関しては>>317のルールに従い、さらに以下のC++機能を使うとよい。

- うっかりミスの防止する機能
非先頭変数宣言、アクセス指定子、C++キャスト演算子、new演算子、参照

- プログラムを組織化し、大規模化しやすくする機能
継承、staticメンバ(関数と変数)、入れ子構造体、構造体内typedef、名前空間

- あれば便利、見通しをよくする機能
関数と演算子のオーバーロード、デフォルト引数、構造体タグ名が型名

これらの機能は全くオーバヘッドがないか、Cと同じぐらい処理が自明だ。
そしてプログラムを安全にし保守を容易にする。

324 ：デフォルトの名無しさん：2008/05/31(土) 20:21:23

>>323
>決してジョークではない

ジョークじゃないなら、そろそろ終わりにしなよ
見ていて辛いわ

325 ：デフォルトの名無しさん：2008/05/31(土) 20:26:55

なら見るのを止めるのがおすすめ

326 ：デフォルトの名無しさん：2008/05/31(土) 20:30:07

やっぱりネタかよw

327 ：デフォルトの名無しさん：2008/05/31(土) 20:34:48

C++を知らないから使っていないんだという前提が痛過ぎる

328 ：デフォルトの名無しさん：2008/05/31(土) 20:40:41

>>323
所で、VC++の最適化にはすばらしいものを感じているが。
今のC言語にあそこまでに最適化があるのか？
無ければ、VC++でCらしく書いたほうが優秀と思われ。
VCのはいたASM見たこと有る?

329 ：デフォルトの名無しさん：2008/05/31(土) 20:46:37

ここはC++を無理矢理Cとして使うスレだっけ?

330 ：デフォルトの名無しさん：2008/05/31(土) 21:28:23

いくらなんでも、非静的メンバ関数の使用はありだろ。
暗黙の引数thisが予想できないというのが理解できない。

普通の関数で引数1つ増えるのと比べて何もオーバーヘッドは変わらない。
むしろ呼出規約によってはthisだけレジスタ渡しになって、素の状態ではやや有利な場合すらあり得る。

331 ：デフォルトの名無しさん：2008/05/31(土) 21:36:05

時折Objective-Cを思い出しては、絶望するスレ。

332 ：デフォルトの名無しさん：2008/05/31(土) 22:17:11

ObjC はとっても C 的で良いんだけど、C を置き換える為の物ではないよね

333 ：デフォルトの名無しさん：2008/05/31(土) 22:18:00

字面がｷﾓすぎ

334 ：デフォルトの名無しさん：2008/05/31(土) 22:25:31

事実上Apple版DLRになってるObj-Cランタイムに価値がある訳で
CからObj-Cランタイムを扱うための言語拡張に過ぎないとも言える

C++やC#とは狙いが違う感じ

335 ：デフォルトの名無しさん：2008/05/31(土) 22:26:07

ここのC++厨はPC上で動くアプリしか作ったことないんだろ。
秋月のキットでも買って出直してこいよ。

336 ：デフォルトの名無しさん：2008/05/31(土) 22:28:02

どんな言語でも見た目が気になるのは初学者のうちだけだよ
文法がまずいとそうもいかないけど

337 ：デフォルトの名無しさん：2008/05/31(土) 22:30:24

>>335
恐らくウィンドウズ以外の経験が全く無いんだろうさ

338 ：デフォルトの名無しさん：2008/05/31(土) 22:44:40

C を駆逐出来るのは C だけだな。C++ は失敗作。
誰か C 1x の仕様策定プロセスを始めてくれないかな。

339 ：デフォルトの名無しさん：2008/05/31(土) 23:03:54

Cから発生した言語は、みんなそのルートを通る。
いまさら新しいCを作ってどうする?

340 ：デフォルトの名無しさん：2008/05/31(土) 23:05:18

どのルート？

341 ：デフォルトの名無しさん：2008/05/31(土) 23:09:53

Cを継承する、拡張する、駆逐する、いわゆる後継のために。
C++も最初はCにクラスが付いただけの言語だった。

342 ：デフォルトの名無しさん：2008/05/31(土) 23:12:46

C++ はもう良いだろ。C を駆逐するのに失敗した言語はスレ違い。

343 ：デフォルトの名無しさん：2008/06/01(日) 00:06:27

CはC99で失敗したからもう発展しない。
VCはC99未対応、gccは -std=c99 が必要

344 ：デフォルトの名無しさん：2008/06/01(日) 00:08:52

VCは要らん

345 ：デフォルトの名無しさん：2008/06/01(日) 00:42:17

>>328
さすがにCとC++の最適化ルーチンは共通化しているでしょう。
疑いもしていないので調べたことはないけど。

346 ：321：2008/06/01(日) 11:47:24

>>322
曖昧な言葉「駆逐」の定義をまた始めるのか？自分はそれに参加する気はないね。
ここはスレタイに曖昧な言葉を使った雑談スレだと思っていたぞ。
レス内容に対してレスせずに発言者に対してレスする、このようなレスがレベルを下げるのを理解して欲しいね。
#答えよう。自分はFORTRANより年上だ。

347 ：デフォルトの名無しさん：2008/06/01(日) 12:01:43

間違いなくここは雑談スレだけど、それを表立って表明してはいけない約束だぜ。
つか、この板のほとんどのスレが雑談スレだ。初学者には雑談以上の話かもしれんけど。

348 ：デフォルトの名無しさん：2008/06/01(日) 13:00:25

C++がCを駆逐できなかったのはJavaのような誇大広告を怠ったからだよ。
「C++は2年以内にCを完全に殺す」のような宣伝をしていればCにダメージを与えていたのに。
あの会社の立場上難しいだろうけど。

349 ：デフォルトの名無しさん：2008/06/01(日) 14:36:50

Why I No Longer Like or Use C++
ttp://www.hyuki.com/yukiwiki/wiki.cgi?WhyINoLongerLikeOrUseCPlusPlus

350 ：デフォルトの名無しさん：2008/06/01(日) 14:55:59

>>349
C++ではなくCを使う理由にはなっていないんだよ。
環境によっては Java, C#, Python, Ruby などを使う理由にはなるが。

351 ：デフォルトの名無しさん：2008/06/01(日) 15:00:47

>>350
言語が単純で、枯れていて、速くて、資産が沢山あって、
スクリプト言語との連携が良いからだよ。Cでなければ
いけない理由は無いが、C以外にそんな言語は無いからな。

352 ：デフォルトの名無しさん：2008/06/01(日) 15:03:35

原文のほう見ると
http://prophipsi.blogspot.com/2008/03/why-i-no-longer-like-or-use-c.html
このスレで先ほどまで力説してた誰かのようなコメントがいきなりついてますな。

353 ：デフォルトの名無しさん：2008/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 ：デフォルトの名無しさん：2008/06/01(日) 15:50:27

>>351

>言語が単純で、枯れていて、速くて、資産が沢山あって、
>スクリプト言語との連携が良いからだよ。

>>317で残った部分は十分に単純で枯れているぞ。
そして速さはCと同じでCとC++の資産も使えるぞ。
スクリプト言語との連携もインタフェース部分だけ
extern "C" すればいいぞ。

>C以外にそんな言語は無いからな。
さらに>>323の機能を使えば安全で便利だぞ。
C++もそういう言語として使えるんじゃないか?

355 ：デフォルトの名無しさん：2008/06/01(日) 16:11:02

「残った部分」とかんな抽象的な。

言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。
毎回チェックするのも大変だし。
>>317で禁止されてる項目はC++がCに比べておいしい所そのものなわけで
これ禁止なら素直にCを使ったほうが早い。

356 ：デフォルトの名無しさん：2008/06/01(日) 16:23:52

>>354
>>>317で残った部分は十分に単純で枯れているぞ。

もう 317 は忘れろ。二度と俺にその話を振るな。
誰も賛同しない物を何でここまで引っ張るかね。

357 ：デフォルトの名無しさん：2008/06/01(日) 16:27:45

もうC++のことは忘れろ。C++はJavaに負けたんだよ。
MSでさえC++は捨ててJavaのパクリを推奨してる。

358 ：デフォルトの名無しさん：2008/06/01(日) 16:32:12

>>355
同意だな
>>317ルールは論外だろ
ちっとも美味しくもなんとも無い"better C"とやらを使うことによって、
少なくともC++のグダグダのABIと、それによるコンパイラ間
非互換性といったおマケはついてくる

それならCのほうがずっといい
無論C99ではなくC89な

359 ：デフォルトの名無しさん：2008/06/01(日) 16:40:41

10 年前ならいざ知らず、今時 C++ をこれだけマンセーするなんて
どれだけ時代が読めないんだろうねえ。しかも中途半端な俺ルールを
ゴリ押ししようだなんて驚くわ。C++ は仕方が無く細々と使うもんだぜ。

360 ：デフォルトの名無しさん：2008/06/01(日) 18:44:34

>>355
>言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。

「言語仕様にある限り使う」と言われればそれまでだが、高々7つ単純な項目ぐらい意識して
開発できるでしょう。しかもinline関数と定数としてのconst変数はいい意味で期待はずれの
結果になるだけで一般的にはルールから外してもいい。さらに暗黙の this を許容できれば
もっと単純になる。
一番簡単なのはプロファイル定義をコンパイラに指定できればいいと思っているが。>>265

>これ禁止なら素直にCを使ったほうが早い。

個人的な経験から>>323の機能があればCと比較して十分開発がやりやすくなると思っている。
本当はデストラクタを使えれば最高だが、見えにくいオーバーヘッドは避けられないので
敬遠されるだろう。

361 ：デフォルトの名無しさん：2008/06/01(日) 18:45:01

>>358
>C++のグダグダのABIと、それによるコンパイラ間非互換性といったおマケはついてくる

まあ>>306でも少し触れたがこれはC++の有名な問題だ。
これを避けるためにboost風のライブラリ命名規則を使ってバイナリを分けたり、
ライブラリのインタフェースのみをCにして実装をC++にするという方法もある。
ABIの問題はC++の利点に比べれば小さいことだと思ってる。
Cでも全くABI問題がないわけではないし。

362 ：デフォルトの名無しさん：2008/06/01(日) 19:35:33

> ABIの問題はC++の利点に比べれば小さいことだと思ってる。

いや、その「C++の利点」を自ら自分ルールで縛りましょうと
言ってるから突っ込まれてるわけだろ。クラスもテンプレートも捨てるのでは
C++の利点の大半をドブに捨てているのと同じだ。そしてABIの欠点は
残る。
ただの自分ルールだから、違反してもコンパイラでチェックも出来ないし
共同開発のチームのメンバに糞ったれなルールを周知し押し付けるための
コストもかかる。

C++のABIの問題は決して小さくは無いだろ。
何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。

363 ：デフォルトの名無しさん：2008/06/01(日) 23:48:27

>>362

>>360にも書いたがチームメンバの問題はそれほど深刻ではないと思っている。
組織が大きくても検査ツールの導入ぐらい(Cプログラムの保守に比べれば)
たいしたコストでもないだろうし。

ちなみに>>317ではクラスの禁止は提案していないぞ。もちろん単一継承の禁止も。
これらのルールはあくまで動作が読みにくい機能を最高に削っただけで環境に合わ
せて緩めるべきだ。

>何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。

COM的なものをC++のABI問題の解決のために利用しているのは少数派でしょ。
個人的にその手のものをC++で使ったのはDirectナントカぐらいしかないよ。
多分COMの人気がなくなったのは.NETの影響じゃないか? .NETじゃCの代わりに
なるとは思えないが。

364 ：デフォルトの名無しさん：2008/06/02(月) 19:50:18

>>363
>チームメンバの問題はそれほど深刻ではないと思っている。

君のチームがどんなプロジェクトで何を作っていて、
どんな人員構成かも分からんのに参考にはならんよ。
ここの人間がどう思っているかは既に分かってるだろ。
君のローカルルールを採用したい人間は誰も居ない。
検討するだけの価値がある様にも思えない。

365 ：デフォルトの名無しさん：2008/06/02(月) 22:13:53

結局Ｃは現役続行てことでおｋ？

366 ：デフォルトの名無しさん：2008/06/02(月) 22:38:52

今Cが使われてるのって、ファーム、ドライバ、OSのカーネルとかか？
それらを駆逐すればいいんじゃね？

367 ：デフォルトの名無しさん：2008/06/02(月) 23:03:35

なんか抽象化の方策でもあるのか？

368 ：デフォルトの名無しさん：2008/06/03(火) 01:41:34

>>364
>君のローカルルールを採用したい人間は誰も居ない。
>検討するだけの価値がある様にも思えない。

何も俺のルールである必要はないんだぞ。あくまでも1つの例として出しただけだから。
強制しているように見えたなら悪かったよ。
Cで生産性上げるためのもっといいアイデアあったら教えて。

369 ：デフォルトの名無しさん：2008/06/03(火) 01:44:25

クソコードをチェックしてくれるデバッガーを大量に雇う

370 ：デフォルトの名無しさん：2008/06/03(火) 01:55:16

そーいえばEC++(embedded C++)ってどーなってるんだ？
あれってリソース要求がシビアな環境向けのC++なんじゃなかったっけ

371 ：デフォルトの名無しさん：2008/06/03(火) 02:08:16

>>370
御大のお言葉をよくお聴きなされ

http://www.research.att.com/~bs/bs_faq.html#EC++

> "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 ：デフォルトの名無しさん：2008/06/03(火) 12:37:11

>>370
名前空間がないのが信じられない。実行のオーバーヘッドは全くないのに。
しかもそのせいでサブセットですらなくなった。

373 ：デフォルトの名無しさん：2008/06/03(火) 18:00:11

embeddedだからってサブセットにする必要性がない。
ランタイムライブらっりを小さくし、必要に応じたライブラリを使えばいいだけだし。ちょっとテンプレートの使い方を工夫すれば小さくなるもん

374 ：デフォルトの名無しさん：2008/06/03(火) 21:17:58

小さいの概念がデスクトップとは違うんだろう。
例外機構も入れたくないくらい小さくしたいみたいだから。

375 ：デフォルトの名無しさん：2008/06/03(火) 22:33:22

EC++はC++を小さくするというコンセプトはいいのに
小さくするやり方がまったくおかしいので使い物にならん
仕様考えた奴はC++をよくわかってないアホとしか思えん

376 ：デフォルトの名無しさん：2008/06/04(水) 00:53:36

確かEC++は日本人が中心になって考えたんだよ。
電機メーカーはコンパイラ作りになれていないからコンパイラの実装が楽な
仕様を選んだんじゃないか。

377 ：デフォルトの名無しさん：2008/06/04(水) 03:30:33

某h立で集まった人員の中でパーサ経験ある奴が俺しかいなかったな
コンビネーションパーシングの考え方／作り方の講習係で終わった
その後どうなったのやら話も聞かんけど、C++のサブセット作りたがってたのだけは記憶しとる

378 ：デフォルトの名無しさん：2008/06/04(水) 09:21:02

>>376
コンパイラの実装が楽なはずの機能まで外れているし
何考えてるんだか俺には全くわからない

379 ：デフォルトの名無しさん：2008/06/04(水) 20:07:08

>>378
バイナリのサイズを小さくする
コンパイラの実装を平易にする

これら以外の目的で削られた機能って具体的にどれの事を言ってるの？

380 ：デフォルトの名無しさん：2008/06/05(木) 01:26:39

378じゃないけど namespace
削った目的は分からない。

リンクが済んだらバイナリのサイズは変わらない。
実装は2週間以内が目安(D&Eより)、もちろん実装者によって違うが。

381 ：デフォルトの名無しさん：2008/06/05(木) 02:13:47

namespaceを無くすると名前マングリングが単純化できて、C互換のobjが吐けるとか？

382 ：デフォルトの名無しさん：2008/06/05(木) 03:17:22

>>381
名前マングリングはtype-safeリンケージのために名前空間なんぞを
導入するずっと前から行ってることだろ
オーバーロードのようなものがある限り、type-safeリンケージは必須だ

383 ：デフォルトの名無しさん：2008/06/05(木) 20:30:38

必要ならextern "C"を使えば済むとは思う。
どうでもいいかもしれないけど、
extern "C"が名前空間内でも使用可なのには最初驚いた。

384 ：デフォルトの名無しさん：2008/06/06(金) 22:50:16

const_cast, reinterpret_cast, static_cast, mutable も性能に影響を
与えないし実装は比較的簡単だと思う。
dynamic_cast だけ外すと分かりにくい仕様になるかもしれないが。

385 ：デフォルトの名無しさん：2008/06/07(土) 00:21:26

組み込み向けで小さいコードしか書かないから、きっと要らないのだろう。

386 ：デフォルトの名無しさん：2008/06/07(土) 09:42:06

コンパイラを実装する人の都合で削ったように見えるな。
C++からCへ変換するプリプロセッサで実現できそうな機能しか残ってない。

387 ：デフォルトの名無しさん：2008/06/07(土) 14:12:32

>>386
>コンパイラを実装する人の都合

これは実際非常に重要なのだけれど、C++ ではツールを含めた言語環境を
作る人間と、それを使う人間が完全に分離してしまっているのが不思議。

388 ：デフォルトの名無しさん：2008/06/07(土) 14:33:41

C++談義でもりあがってるところ悪いけど、そんなことより
FORTRAN 77をさっさと完全駆逐してほしい。算術IFとかなんだよあれ。
大文字コードはSQLだけで充分だ。

389 ：デフォルトの名無しさん：2008/06/07(土) 14:40:43

>>388
FORTRAN は多分大型コンピュータと共に死滅するんじゃないかな？

390 ：デフォルトの名無しさん：2008/06/07(土) 14:46:31

いやいや、Fortran 90以降は好きだし使ってるけどな。2kからは
オブジェクト指向になるらしいし。Fortran 77がクソ過ぎて困る。

391 ：デフォルトの名無しさん：2008/06/07(土) 18:17:24

高速な数値計算が必要なところは FORTRAN で作って extern "FORTRAN" で
C++ から呼べばいいんじゃないか?

392 ：デフォルトの名無しさん：2008/06/07(土) 18:20:30

それを更に C で wrap して Fortran から呼び出したらいいんじゃない？

393 ：デフォルトの名無しさん：2008/06/08(日) 00:59:14

>388
算術IF文と論理IF文までしかなかったのはFORTRAN 66。
FORTRAN 77ならブロックIF文が使えるはずだが。

算術IFが廃止されたのはFORTRAN 95からだが、過去の資産の使いまわしに困る
ようなFORTRANに存在価値ってあるのかな。

394 ：デフォルトの名無しさん：2008/06/08(日) 01:10:18

>>393
>、過去の資産の使いまわしに困るようなFORTRAN
FORTRANってベクトルマシンと趣味ユース以外で使われてんの？

395 ：デフォルトの名無しさん：2008/06/08(日) 01:42:38

微妙な計算ライブラリとか結構使われている。
自分が関わった某産業分野の制御でも使ってた。

396 ：デフォルトの名無しさん：2008/06/08(日) 02:15:24

そうなのか。
……未だに何故Fortranなのかが判らん分野なんだよなー。
Haskellやmlなんかの関数型も数学向いてるって聞くけど
取って代わられる可能性あんのかな

397 ：デフォルトの名無しさん：2008/06/08(日) 03:58:14

秘伝のソースを一子相伝で守り続けている世界だよ
魔法が息づいているうちは、早々簡単に取って代わられない

398 ：デフォルトの名無しさん：2008/06/08(日) 18:23:42

楽にプログラミングしたい訳では無くて、楽に計算させたいだけだからね。
学術計算用途ではFortranが長いこと使われててライブラリが豊富にあった。
Fortranから他への移行なんて、ここ10年くらいの話じゃないかな？
それもCとかC++だから、数値計算を専門でやってる人以外は、Fortranの
ほうが楽でいいじゃんとか思う人も多いわけよ。別に困ってた訳じゃないから。

399 ：デフォルトの名無しさん：2008/06/08(日) 18:29:53

Cは蓄積だけでなく、実際実際ベクトル／行列計算の分野では
性能的にFortranに勝てんのでしょ

C++は式テンプレートのような遅延評価での高速化テクニックが最近
出てきてるようだけど、どうなんだろう

400 ：デフォルトの名無しさん：2008/06/08(日) 18:52:01

ベクトル／行列計算の性能を追求するなら、Linuxでクラスタ組んで
Cのライブラリを使うのが主流。
スパコンTOP500とかに並んでるのは、ほとんどそういう用途だわな。

401 ：デフォルトの名無しさん：2008/06/08(日) 18:57:26

Cには多次元配列がない、C99まで標準にはrestrictポインタがない、
複素数がないとかいろいろあるからなあ。科学技術計算にC++とかは
お笑いなんで無視していいけど。

402 ：デフォルトの名無しさん：2008/06/08(日) 19:27:12

>>401
>科学技術計算にC++とかは
>お笑いなんで
そうなんか。識者とお見受け
後学のために詳しく聞きたいです。その用途でC++の難点って例えばどんなあたりですか？

403 ：デフォルトの名無しさん：2008/06/08(日) 19:37:58

PGI とか C++ にも対応してるけど、科学技術計算でダメなんか?
まあ C++ なんかどうでも良いけど。

404 ：デフォルトの名無しさん：2008/06/09(月) 22:52:58

スパコン使う分野はともかく現在の数値計算の最前線(新米二等兵とも言う)では
圧倒的にC++が使われているよ。
Fortranの時代と比べてどちらがマシかは判断しかねる。

405 ：デフォルトの名無しさん：2008/06/11(水) 18:53:28

CもC++も、<適度に・中途半端に>なんでもやれる言語だからね、良くも悪くも。

406 ：デフォルトの名無しさん：2008/06/11(水) 19:06:05

C よりも C++ を先に駆逐して欲しいな
既に朽ち始めているから気に病む必要も無いかもしれんが

407 ：デフォルトの名無しさん：2008/06/11(水) 20:31:32

逆に Java や C# に限界を感じて C++ は再評価され始めているんじゃないか?

408 ：デフォルトの名無しさん：2008/06/11(水) 20:41:02

JavaやC#の限界ってなんのこと？

409 ：デフォルトの名無しさん：2008/06/11(水) 21:09:19

VMの外の人と話せないこととか

410 ：デフォルトの名無しさん：2008/06/11(水) 21:49:55

つ JNI

411 ：デフォルトの名無しさん：2008/06/11(水) 21:57:42

むしろＣ＋＋が再評価ってなんのこと？？？

412 ：デフォルトの名無しさん：2008/06/12(木) 09:27:16

C++/CLIのことだろう

413 ：デフォルトの名無しさん：2008/06/12(木) 11:00:04

>>412
あれ便利っつーか楽っつーか、確かにいいんだけど
言語仕様としては究極の汚さだよなあ。

414 ：デフォルトの名無しさん：2008/06/13(金) 18:10:15

Javaのようにオブジェクト指向を強制する言語には限界がある。
C++のように、低水準プログラミング、構造化プログラミング、OOプログラミング、
テンプレートメタプログラミングを混ぜて使えるほうが現場で役立つ。

415 ：デフォルトの名無しさん：2008/06/13(金) 19:05:32

1 行目と 2 行目以降は全く関係無いね

416 ：デフォルトの名無しさん：2008/06/13(金) 21:16:58

役立たないとはっきり書いてほしかったのかな?

417 ：デフォルトの名無しさん：2008/06/13(金) 21:18:29

自己紹介には及ばん

418 ：デフォルトの名無しさん：2008/06/14(土) 17:00:28

アセンブラから見てCってどうなの？

419 ：デフォルトの名無しさん：2008/06/14(土) 17:08:30

ブロックの先頭でしか局所変数を宣言できない C90 の仕様は勘弁してほしい。
あと inline 関数が標準化されていないのも困る。
組込み環境ではそれだけの理由でも C++ の方を使いたいよ。
無理やり C を使わせられたら発狂しそうだ。

420 ：デフォルトの名無しさん：2008/06/14(土) 17:10:57

C99 か GCC でオケ

421 ：デフォルトの名無しさん：2008/06/14(土) 17:14:18

#define INLINE _inline

422 ：デフォルトの名無しさん：2008/06/14(土) 17:26:15

#pragma inline 使うコンパイラがあるので #define だけではすまない。

423 ：デフォルトの名無しさん：2008/06/15(日) 00:49:57

そこで_Pragma演算子よ、って結局C99というオチ。

424 ：デフォルトの名無しさん：2008/06/15(日) 00:55:33

C++

425 ：デフォルトの名無しさん：2008/06/15(日) 13:00:19

C以外の中級言語つくろうって動きはないのかね

426 ：デフォルトの名無しさん：2008/06/15(日) 13:44:05

Dは無視ですか、そうですか

427 ：デフォルトの名無しさん：2008/06/15(日) 15:36:22

C90 はポータビリティを考えたら外部識別子が 6 文字までしか使えないから使いにくい。
C++ は 1024 文字まで保障されている。

428 ：デフォルトの名無しさん：2008/06/15(日) 15:43:45

そういやそんなのあったな・・・全く守ってねーや

429 ：デフォルトの名無しさん：2008/06/15(日) 16:49:15

>>427
もっともC++処理系自体にはポータビリティがないがなw

430 ：デフォルトの名無しさん：2008/06/15(日) 17:03:02

きっと処理系のできは時間が解決してくれるよ。

431 ：デフォルトの名無しさん：2008/06/15(日) 17:05:51

もう時代の審判が下るくらいの時間は経ってると思うが、
今後これ以上何かあるかなあ…

432 ：デフォルトの名無しさん：2008/06/15(日) 18:24:16

今の C++ コンパイラってそんなに標準準拠度が悪いの?
組み込みなら C のように標準ライブラリの一部が削られているかもしれないけど。
VC9 と GCC4.x は問題ない範囲だと思うけど、準拠度の低いのってどんなのある?

433 ：デフォルトの名無しさん：2008/06/18(水) 15:20:55

>>431
B言語でもやってろ

434 ：デフォルトの名無しさん：2008/06/18(水) 15:55:05

C 言語のように構造体メンバのアクセス制限のない言語を使って複数人で開発するのは難しく
ないですか? 以下の開発方法しか思いつかないのですが。

- 構造体オブジェクトへのアクセスは必ずその構造体用の関数を経由するように周知徹底する
- 構造体定義を利用者から隠してメンバへのアクセスを不可能し、ヒープからオブジェクトを
　生成する関数を用意する
- 構造体の文書を整備し、定義に変更があったらその構造体を使っている場所を点検し直す

インライン関数があれば最初の方法が現実的かな。

435 ：デフォルトの名無しさん：2008/06/18(水) 16:40:50

- 一度定めた構造体の定義に対して互換性がなくなるような変更をしない

436 ：デフォルトの名無しさん：2008/06/18(水) 18:13:08

>>435
それはpointみたいに非常に単純なものでない限りは
現実問題としては無理なので、
opaqueな型にしてしかもメンバにmagic number仕込むとかやったほうがいいな

437 ：デフォルトの名無しさん：2008/06/18(水) 19:18:44

何か無理やりOOをやりたいのか？C++じゃないんだが。

438 ：デフォルトの名無しさん：2008/06/18(水) 20:03:38

>>434
拡張子をだなcppに変えて（ｒｙ

439 ：デフォルトの名無しさん：2008/06/18(水) 20:44:55

>>437
OO まではいかないけど抽象データ型を使うとプログラムの変更に強くなるし楽だと思う。
C の標準ライブラリでは FILE ぐらいしか思いつかないけど、Windows ではよくハンドルを
使っているようです。C の場合整数のハンドルより構造体のポインタを使ったほうが型安全
でいいかもしれませんね。
コンテナのようにある程度複雑の構造だと抽象データ型じゃないとつらいんじゃないかな。

440 ：デフォルトの名無しさん：2008/06/18(水) 23:57:02

>>434
むしろOO的には、一番目と二番目を徹底すべきじゃないのか？
C++であっても。

441 ：デフォルトの名無しさん：2008/06/19(木) 00:38:02

>>439
いや、構造体をクラスに見立ててOOしたいんだろ？
じゃなきゃ、>>434の1行目のようなアクセス制限が云々なんて前提が出てくるとは思えない。
Cのパラダイムを無視して、突然こんな前提で設計しろと言われたらオレは難色示すね。
というわけでお前の考え方では、複数人での開発は難しくなるだろう。
これまで培われたコンセンサスに乗っ取った構造体の使い方をすればいい。
無理してオレ流OOルールを持ち出せば、上で叩かれているC++のローカルルールと同じ問題になると思うがね。
お前はCのパラダイムを無理やりOOに当てはめて解釈しようとしてるんじゃないのか？

ああ、それと今オレがCで書いているシステムは、ヒープ割り当てができないようになってて、
スタックは1Kしか使えないんだがどうするんだい？
オレ流OOルールをもうひとつ追加するのか？RAMも16Kに減らされそうなんだが。

442 ：デフォルトの名無しさん：2008/06/19(木) 00:45:25

RAMが16Kbyteもあるなんて贅沢だw

443 ：デフォルトの名無しさん：2008/06/19(木) 01:07:40

オブジェクト指向は言語と直行した概念だから C で OOP しても何の問題も無い。
構文の助けが無い分、面倒臭いのは我慢する必要があるけど。

http://www.gnome.gr.jp/docs/glib-2.2.x-refs/gobject/pr01.html
http://ja.wikipedia.org/wiki/Core_Foundation
http://www.sage-p.com/process/cool.htm

シンプルな C に多少のルールを追加するのと、カオスな C++ から便利機能を
削除するのは別次元の話だと思うよ。

444 ：デフォルトの名無しさん：2008/06/19(木) 02:07:30

C++はいらないけど、C++コンパイラは必要。

CのソースをC++でコンパイルすると型チェックが厳密なんで
バグ出しにたすかる。プロトタイプ宣言の型が省略可能とか
mallocが暗黙的に型変換されるとかありえない。あとNULLも0で
統一してくれ。

445 ：デフォルトの名無しさん：2008/06/19(木) 02:11:53

>>443
COOL 見たけどかなり面倒くさそう。
書くときの面倒くささよりコンパイラの安全性チェックができなくて
変更を間違ったときに気づかなくてバグになりそう。
これなら20年ぐらい前のC++仕様でも楽に安全に作れると思う。

446 ：デフォルトの名無しさん：2008/06/19(木) 02:22:14

CでOOPLならObjective-Cがあるじゃん。あれもあれで変な言語だけど。

447 ：デフォルトの名無しさん：2008/06/19(木) 02:28:21

Objective-C は C Compiler でコンパイル出来ないから、、、
と思ったけど POC を忘れてたわ。

http://users.pandora.be/stes/compiler.html

C++ より Objective-C の方が C の発想に近いよね。

448 ：デフォルトの名無しさん：2008/06/19(木) 02:35:35

http://grape.mtk.nao.ac.jp/~makino/articles/worse-is-better-ja.html

ここに書かれている通り C は「悪い方がよい」原則。ObjC も同じ。
C++ はどちらかというと CL の辿った道に近い気がする。
つまり「正しい」アプローチで作られた「複雑巨大システム」。

449 ：デフォルトの名無しさん：2008/06/19(木) 02:42:51

「悪い方がよい」原則って、意味のある言葉じゃないだろ。
いいものが定着するとなにも言わずに、悪いものが定着すると
「悪い方がよい」って言えばいいんだから。

450 ：デフォルトの名無しさん：2008/06/19(木) 02:46:57

>>441
抽象データ型なんて昔から C で普通にやっていることだよ。
C++ の前の C with Classes でもこれをやりやすくするためにアクセス保護を導入したし。

構造体の定義が可視ならヒープにとる必要もないしスタックにもオブジェクトを置けるよ。
定義が可視ならもちろんアクセス保護があったほうが安心だけど。

451 ：デフォルトの名無しさん：2008/06/19(木) 02:52:50

>>449
リンク先を読めば意図は分かると思うけど、気になるなら
「New Jersey アプローチ」と読み替えても良いよ。

452 ：デフォルトの名無しさん：2008/06/19(木) 02:59:11

Java も「悪い方がよい」原則のような気がする。

453 ：デフォルトの名無しさん：2008/06/19(木) 03:23:24

>>451
>>449をよく読めば意図が分かると思うけど、気になるなら
「悪いものが定着したときは「New Jersey アプローチ」って言えばいいんだから」
と読み替えても伊井よ

454 ：デフォルトの名無しさん：2008/06/19(木) 03:30:42

それ元ネタが凝った角度でモノ書こうとして失敗してる例に感じるな
タイトル先行で書き下されたかのような。

完璧を求めると複雑巨大になり弊害がある
単純さを求めると完全ではなくなり弊害がある

一長一短って話だろ　なんでworse is betterやねん

455 ：デフォルトの名無しさん：2008/06/19(木) 08:29:56

>>454
>一長一短って話だろ

違うよ。Lisper が Lisper に向けて何故 Lisp 族が失敗したかを考察した文章で、
Lisp は敗北したという前提だから、一長一短ではなく Worse Is Better なの。

http://www.kt.rim.or.jp/~hisashim/gabriel/WorseIsBetter.ja.html

456 ：デフォルトの名無しさん：2008/06/19(木) 17:50:52

あ、なるほど。その文書読んでから読み直すと少し納得
少なくともタイトル先行な面白書きではない訳ですな

で、改めて読み直してみたけど、やっぱり俺には誤解が残る
Lispの造型が足りないせいか、頭が足りないせいかな

457 ：デフォルトの名無しさん：2008/06/19(木) 20:59:37

LISPの造型が足りないというのは、カッコの数が少なすぎるということかな？

458 ：デフォルトの名無しさん：2008/06/19(木) 21:19:58

>>455
だから、Lisperじゃない普通の人にとってはWorse is Betterには意味がない
ってことじゃないの。
こんなの何でも適当できるよ。

Linux使い「Windowsが普及してるのはWorse is Betterだから」
元共産主義者「資本主義が普及しているのはWorse is Betterだから」
チャーチル「民主主義が普及してるのはWorse is Betterだから」

459 ：デフォルトの名無しさん：2008/06/19(木) 21:40:30

>>457
あ、造詣か鬱氏　どうやら後者のようだ

460 ：デフォルトの名無しさん：2008/06/19(木) 21:43:13

>>458
よく読みな

つ http://grape.mtk.nao.ac.jp/~makino/articles/worse-is-better-ja.html

461 ：デフォルトの名無しさん：2008/06/19(木) 21:49:08

つうか、現実の「複雑巨大システム」であるMulticsとPL/Iの失敗への
反省・アンチテーゼとしてUnix/Cが生まれたわけで、そのことさえ抑えておけば十分。

なぜかその論文？ではその有名な事実に触れてもいないけどね。
Unixの「New Jerseyアプローチ」は、理由もなく／何も無いところから
産まれ出てきたものでは無い。

データも何も無い、分析とは言いがたい内容で、単に「Worse is Better」とか
題目だけ唱えてもそれは題目でしかなく、何の意味も無いと思う。
まあ、一種のネタ文書なんだろうな。

462 ：デフォルトの名無しさん：2008/06/19(木) 21:49:30

自分で考える前に質問してしまう人がいるのは何でなんだぜ？

463 ：デフォルトの名無しさん：2008/06/19(木) 21:50:55

>>460
ほら、自分の言葉で説明できないだろ。Worse is Betterってのは
単なるお題目なんだよ。

464 ：デフォルトの名無しさん：2008/06/19(木) 21:55:19

>>461
>なぜかその論文？ではその有名な事実に触れてもいない

それはそういう文脈じゃないからだよ。
当然 MIT の連中が Multics を知らない訳はないでしょ。この文脈では
彼らにとっては Multics より ITS の方が現実的な意味を持っているだけ。
そこら辺の歴史は自分で勉強してチョ。

465 ：デフォルトの名無しさん：2008/06/19(木) 22:01:19

>>463
文章を読んで理解出来なかった奴に説明するのは無理だよ。
それは俺の能力ではどうしようもない。諦めてくれ。

466 ：デフォルトの名無しさん：2008/06/19(木) 22:01:30

つまりわかりやすく言えばLisperの僻みだろ。

「こんなに素晴らしく美しい言語であるLispが天下を取れないのはなぜか？！
　それは普及するものがWorse is Betterだからだ！Lispは悪くない！」

っていう発想の転換、悪く言えば現実逃避をしてるだけ。一般人には
共感が得られない。

467 ：デフォルトの名無しさん：2008/06/19(木) 22:03:37

>>466
君読んでないのがバレバレだよ。

468 ：デフォルトの名無しさん：2008/06/19(木) 22:07:03

つか Worse って言葉に引き摺られて論旨が見えてないでしょ。
別に UNIX/C を馬鹿にしてる文章じゃないんだぜ。とほほ…

469 ：デフォルトの名無しさん：2008/06/19(木) 22:08:13

>>465
そういう言い方がカルトくさいんだよ

「文章を読んで大作先生の素晴らしさを理解出来なかった奴に
説明するのは無理だよ。それは俺の能力ではどうしようもない。諦めてくれ。 」
とか、
「君、大白蓮華読んでないのがバレバレだよ。」
って言ってるのと変わらん。そんなの知るかボケ、と言わせてもらおう。

470 ：デフォルトの名無しさん：2008/06/19(木) 22:10:20

さて、自転車置き場の議論が始まりそうだから退散するとしますか…

471 ：デフォルトの名無しさん：2008/06/19(木) 23:08:12

>>448
俺はC++も「悪い」に属すると思う。
そうでなければここまで広まらなかったに違いない。

472 ：デフォルトの名無しさん：2008/06/20(金) 12:38:14

広まったのは単にMSのせいかも

473 ：デフォルトの名無しさん：2008/06/20(金) 13:55:19

SunはMSを潰すためにJavaを出した。MSはJavaとの共倒れを狙ってC#を出した。

474 ：デフォルトの名無しさん：2008/06/20(金) 14:07:48

実装が単純ならば移植しやすく広まりやすい。
正しいものを広めるより広まったものを改善するほうが簡単。
完全に正しいものを作ろうとすると最後の20%に努力の80%が費やされる。

つまり「悪い」の定義は単純な実装と最低限の品質で最大限の評価を得ること。

475 ：デフォルトの名無しさん：2008/06/20(金) 14:23:55

それなんてエロゲ？

476 ：デフォルトの名無しさん：2008/06/20(金) 19:08:09

>>472
MFCのせいでC++が浸透しないのかも

477 ：デフォルトの名無しさん：2008/06/20(金) 19:13:46

MFC以外のもっと使いやすいC++用RADがあったら
普及したかもなぁ・・・ってBCBは？！

478 ：デフォルトの名無しさん：2008/06/20(金) 19:24:27

>>477
VC++にVCLが標準装備だったらなあ

479 ：デフォルトの名無しさん：2008/06/20(金) 21:57:16

VCLそのものがC++で書かれていないのが痛い

480 ：デフォルトの名無しさん：2008/06/21(土) 10:21:37

くだすれ、落ちてねえ?

481 ：デフォルトの名無しさん：2008/06/23(月) 08:15:11

>>448
これだから日本語しか読まない奴は。

Worse Is Better - Richard P. Gabriel
http://www.dreamsongs.com/WorseIsBetter.html
> Decide for yourselves.

おっと。日本語訳もあった。
http://www.kt.rim.or.jp/~hisashim/gabriel/WorseIsBetter.ja.html

482 ：デフォルトの名無しさん：2008/06/23(月) 08:18:04

Jim Waldo の "Worse is worse" も翻訳があった。助かるな。
http://www.kt.rim.or.jp/~hisashim/waldo/worseisworse.ja.html

483 ：デフォルトの名無しさん：2008/06/23(月) 09:09:28

>>481-482
どっちも既に読んでるよ。ご苦労。

484 ：デフォルトの名無しさん：2008/06/23(月) 20:56:16

しかも前者に至っては既出

485 ：デフォルトの名無しさん：2008/06/24(火) 00:00:14

そんなことよりWordsworth読もうぜ！
ttp://www.bartleby.com/145/ww260.html

486 ：デフォルトの名無しさん：2008/06/24(火) 00:25:54

Yeats >> Blake >>> (越えられない壁) >> Wordsworthだろ
常識的に考えて・・・

まあ、英国詩人全部合わせてもRimbaud一人に勝てないけどな

487 ：デフォルトの名無しさん：2008/06/24(火) 00:27:15

ランボーってベトナム帰りのあいつか？

488 ：デフォルトの名無しさん：2008/06/24(火) 00:29:07

元ネタだから、yesと言っても間違いじゃない。

489 ：デフォルトの名無しさん：2008/06/24(火) 00:38:16

Close To The Edgeは名盤だよな

490 ：デフォルトの名無しさん：2008/06/24(火) 20:53:56

俺はHeart Of The Sunriseの方が好き。

491 ：デフォルトの名無しさん：2008/06/25(水) 01:01:07

C言語のプログラマは、自分たちを一番優等だと思ってるところが問題だ。

492 ：デフォルトの名無しさん：2008/06/25(水) 01:54:54

つまりプログラマの殆どはそんなこと思っているのか。

493 ：デフォルトの名無しさん：2008/06/25(水) 08:28:14

言語の違いなんてバイオリンとピアノの違いでしかない。
道具が違うからって音楽家は人を馬鹿にしたりしないだろ。
それと同じこと。


ただし、ヴィオリストは馬鹿だけど。

494 ：デフォルトの名無しさん：2008/06/25(水) 08:40:33

ベーシストをDISる厨バンドマンならいくらでも

495 ：デフォルトの名無しさん：2008/06/25(水) 11:04:51

>>493
>道具が違うからって音楽家は人を馬鹿にしたりしないだろ。
譬えの誤謬だ。
カズー奏者はどう頑張ってもバカにされる対象。

496 ：デフォルトの名無しさん：2008/06/25(水) 21:50:27

>>493
>ただし、ヴィオリストは馬鹿だけど。

(^^;;;;;

なぜ Va は自虐的なんでしょうね、てスレ違いですけど。

497 ：デフォルトの名無しさん：2008/06/25(水) 22:21:01

他の言語を貶す言語廚は、自分の推す言語使いこなせななくて自信がないから他の言語を貶すんだろうね。

自分の目的に合致している言語を使いこなしているのなら、他の言語なんて眼中にないだろう普通

498 ：デフォルトの名無しさん：2008/06/25(水) 22:27:33

>>497
誰しもそこから出発するわけでして、許してあげましょうよ。

499 ：デフォルトの名無しさん：2008/06/25(水) 22:30:02

このスレの主旨はそういう言語戦争とは違うと思うけど？
そろそろCに変わる言語が欲しいね、という前向きな話だよ。

500 ：デフォルトの名無しさん：2008/06/26(木) 02:44:29

BCPLとK&Rの頃から愛してる

C99になってもっと恋しくなった

BSDとEmacsも愛してる

Cを知ったその日から
僕のプログラミング地獄に音楽は絶えない

501 ：デフォルトの名無しさん：2008/06/26(木) 11:02:04

K&Rからなら信じるけど。
BCPLからなんて誰が信じるか。

502 ：デフォルトの名無しさん：2008/06/26(木) 23:12:49

そこマジレスするところじゃなくね？w

503 ：デフォルトの名無しさん：2008/06/26(木) 23:15:28

1億と2千年たってもＣ言語は健在だお。

504 ：デフォルトの名無しさん：2008/06/26(木) 23:46:41

そんなに人類生きてんのかな

505 ：デフォルトの名無しさん：2008/06/27(金) 00:08:34

マジレス乙ｗ

506 ：デフォルトの名無しさん：2008/06/27(金) 06:25:07

そのころには人類は量子コンピュータ上でシュミレーティッド
された世界に住んでるんだろな。動作言語はもちろんC-100002000

507 ：デフォルトの名無しさん：2008/06/27(金) 07:07:17

シュミレーティッド

508 ：デフォルトの名無しさん：2008/06/27(金) 23:47:05

C++の何がまずいかは語りつくされたようだから、
次はＤのなにがまずいかについて聞かせてくれまいか。

509 ：デフォルトの名無しさん：2008/06/27(金) 23:49:19

D言語は良く知らない

510 ：デフォルトの名無しさん：2008/06/28(土) 00:02:19

DこそＣを駆逐してやるという目的で生まれた言語だよね？

511 ：デフォルトの名無しさん：2008/06/28(土) 02:01:19

でもDコンパイラってCと100%互換なんじゃなかった？
むしろ共存したいんじゃないの？

512 ：デフォルトの名無しさん：2008/06/30(月) 16:30:47

互換性は罠だな。
共存すると見せかけてＣプログラマをＤに取り込んでおいて、
Ｃに戻れないほど脳みそを蝕んでおいてからはしごをはずすんだろう。

513 ：デフォルトの名無しさん：2008/07/02(水) 12:14:30

なんか方向性が逆じゃないか？
スタック変数の自動管理と、一般的な制御構文の使える高級アセンブラがあればいい。

514 ：デフォルトの名無しさん：2008/07/02(水) 13:17:54

そんなやつはもはや少数派なんだよ

515 ：デフォルトの名無しさん：2008/07/02(水) 18:36:13

>>513
マクロアセンブラで遊んでてください。

516 ：デフォルトの名無しさん：2008/07/02(水) 23:57:30

Java とか.netのVMのアセンブラを使えば、幸せになれるんじゃないか？

517 ：513：2008/07/03(木) 02:13:15

>>516
JVMとか.netのCLRとかは、それこそJavaやC#使えばいいだろ。
Cの本領発揮は、もはや絶対アドレスやIOポート参照が必要なところか、
CPUレベルの最適化が必要なところだけなんだから、だったらそこだけ
高級アセンブラで書いて、残りは本当の高級言語で書けばいい。

518 ：デフォルトの名無しさん：2008/07/03(木) 15:18:31

>>513 >>517
>高級アセンブラ
それがCじゃないのか？

519 ：デフォルトの名無しさん：2008/07/03(木) 18:18:37

Cはポータビリティのために、効率が悪い点が多いんだよ。
低級言語は、機種依存な部分だけに使えばいい。

520 ：デフォルトの名無しさん：2008/07/04(金) 18:31:29

>>519
ここで低級言語といってるのはCのこと？アセンブラのこと？

521 ：デフォルトの名無しさん：2008/07/06(日) 15:47:30

>>511
惜しい。コンパイラは互換性無いよ。
互換性があるのはリンカ。

522 ：デフォルトの名無しさん：2008/07/06(日) 16:18:21

>>520
低級はローレベル。すなわちステムに近いことを示す。システム記述言語であるアセンブラやC/C++などじゃないか。

523 ：デフォルトの名無しさん：2008/07/07(月) 13:42:35

ttp://ja.wikipedia.org/wiki/%E4%BD%8E%E7%B4%9A%E8%A8%80%E8%AA%9E

524 ：デフォルトの名無しさん：2008/07/12(土) 23:15:15

>>522
Cと他言語(Java等)を比べて低級な方って意味で言ってるのか、
それともCとアセンブラを比べて低(ry
ってことだろじょしこー

525 ：デフォルトの名無しさん：2008/07/14(月) 11:01:59

いや俺はJKよりJCのほうｇ

526 ：デフォルトの名無しさん：2008/07/14(月) 12:03:02

もっとも低級言語に近い高級言語Ｃ。この独特のポジションにいる限りCobolやVBが滅びても
Ｃが滅びることはないように思う。

527 ：デフォルトの名無しさん：2008/07/14(月) 15:32:42

>>526
当然だな

528 ：デフォルトの名無しさん：2008/07/14(月) 23:47:27

そもそも、現在生き残っている OS で C を使わないものが、どれだけ存在するのか？
それ等の OS が全て駆逐されないかぎり、C は駆逐されないのは自明

529 ：デフォルトの名無しさん：2008/07/15(火) 00:42:27

まったくだ。リア工の俺にはCの無かった時代というのが想像できない。

530 ：デフォルトの名無しさん：2008/07/15(火) 01:08:16

LISPマシンが市場抑えていたらどうなったんだろう、って想像くらいか
マシン語が括弧だらけになるんだろうな
サンもJavaマシンとか考えてたな　あれは夢想に終わったんだっけか

後者はマシン語がJavaVMのバイトコードに置き換わるだけだな
実現していたところで、結局その上にCコンパイラとか出て来て意味不明な事になってたんだろうな

531 ：デフォルトの名無しさん：2008/07/15(火) 05:16:55

>>530
ICOT のアレは？

532 ：デフォルトの名無しさん：2008/07/15(火) 19:58:25

34bitアーキテクチャが流行っただろうな

533 ：デフォルトの名無しさん：2008/07/15(火) 21:13:20

将来、
GPUにDSP系のプロセッサを乗せて
そいつにコードを転送する必要が生じたとき、
そのコードはC言語をはじめ、手続き型言語では記述できない

組み込み系も視野に入れるなら、C言語の立ち入ることのできない領域は今でもあるよ。
FPGAとかあるし。

534 ：デフォルトの名無しさん：2008/07/15(火) 21:24:01

>手続き型言語では記述できない

すまん。
俺にはそんなものがあるとはちょっと想像が付かない。
どういうこと？

535 ：デフォルトの名無しさん：2008/07/15(火) 22:16:17

>>534
FPGAとかゲートアレイっていう、電子回路をプログラミングできるチップがあって、
そいつをプログラミングするにはSystem-CとかHDLとかいう言語を使うんだ。
基本的には
「○番ポートと○番ポートの入力を足したり割ったりして、○番ポートに出力せよ」
という宣言の羅列になる。

本物のハードよりは遅いけれど、ソフトウェアよりは速い。
ソフトウェアより融通が聞かないけれど、ハードウェアよりは融通がきく。
という建前だった。

今は知らないけど。

536 ：デフォルトの名無しさん：2008/07/16(水) 01:48:03

それって手続き型言語で記述できないのか？

537 ：デフォルトの名無しさん：2008/07/16(水) 01:55:14

できるでしょ

538 ：デフォルトの名無しさん：2008/07/16(水) 02:34:18

手続き型言語を procedural language の訳語とするなら無理だろう
逐次実行であることが第一義だから対極にある
ただ、C言語を駆逐する方向という意味では、全く逆に取り込まれていく方向にあると思う
これは、言語・ソフト的にという意味では無くて、ハード的にという意味だが

539 ：デフォルトの名無しさん：2008/07/16(水) 06:06:11

SystemCはC++で書けるんだが

540 ：デフォルトの名無しさん：2008/07/16(水) 07:06:43

>>534
大雑把に書くと
手続き型言語は演算子を順番に評価実行する。
HDLなどの記述言語は、すべての演算子が同時に評価され常に評価結果が反映される。

HDLに適した処理を手続き型言語で書き直すと処理時間が遅くなりすぎる。
手続き型言語に適した処理をHDLで書くと回路規模が大きくなりすぎる。まあこれは、HDLでCPUを書いてしまえば解決できるというのがノイマン型コンピュータというか手続き型言語の原点かな。

541 ：デフォルトの名無しさん：2008/07/16(水) 07:17:51

記述できるじゃないか。

542 ：デフォルトの名無しさん：2008/07/16(水) 08:12:41

まぁ、手頃なスクリプト言語で書くほうが無難ってことだな。

543 ：デフォルトの名無しさん：2008/07/16(水) 08:36:05

haskellでHDL書きたい

544 ：デフォルトの名無しさん：2008/07/16(水) 09:04:28

>>543
atomでいいんじゃないか？
http://funhdl.org/wiki/doku.php/atom

545 ：デフォルトの名無しさん：2008/07/16(水) 12:15:23

>>541
記述できてもパフォーマンスを満たせない

546 ：デフォルトの名無しさん：2008/07/16(水) 15:31:49

できないじゃなくて現実的じゃないってことか、把握

547 ：デフォルトの名無しさん：2008/07/23(水) 08:10:10

CはどんなCPUでも同じ文法で動く、“共通アセンブラ”みたいな位置づけ。
他の言語と比べること自体がナンセンス。 もう機能追加とかしない方がいい。
CにはOOだのGCだの必要なし。それはLLとかに任せればいい。

548 ：デフォルトの名無しさん：2008/07/24(木) 01:45:34

CはC++の例外相当の処理を効率よく実行できないので不十分。
C++からCへのトランスレータが使われなくなったのはそのせい。

549 ：デフォルトの名無しさん：2008/07/24(木) 07:18:46

>>547
同意。C99も失敗だったかもな。

550 ：デフォルトの名無しさん：2008/07/24(木) 13:44:29

185でｶﾞｲｼｭﾂ

551 ：デフォルトの名無しさん：2008/07/25(金) 07:09:39

ランタイムライブラリを統一できないから、それを必要としないCが生き残る
MSがそれを統一したような気がしないこともないが、それは言わない約束だからCが生き残る

552 ：デフォルトの名無しさん：2008/07/25(金) 10:11:24

>>551
libcって知ってる？
2行目も意味不明

553 ：デフォルトの名無しさん：2008/07/25(金) 13:18:37

libcを他のライブラリと区別する理由はない

554 ：デフォルトの名無しさん：2008/07/26(土) 20:52:32

インタプリタが生き残るよ

555 ：デフォルトの名無しさん：2008/08/13(水) 17:10:02

C99のTechnical corrigenda TC３はどんな内容ですか？

556 ：デフォルトの名無しさん：2008/08/31(日) 22:30:01

libcって、ANSIレベルに毛が生えた物、って先入観しかないんだが…

557 ：デフォルトの名無しさん：2008/09/01(月) 12:48:32

Cが駆逐されると思ってるかどうかで考え方がかなり変わるみたいだな

Windows使ってるとMSが潰れたら困るよ、みたいな感覚で関数型言語やってる人とか
なんかすごくね？

558 ：デフォルトの名無しさん：2008/09/01(月) 22:19:47

Windowsを完全に駆逐するためには
ってスレがあってもいいかもな。良くないか。

559 ：デフォルトの名無しさん：2008/09/01(月) 22:58:47

Macしかないな。

560 ：デフォルトの名無しさん：2008/09/01(月) 23:03:12

Macをプログラム言語にたとえるとlispになるのかなぁ。
とMacもlispも使ったことのない俺が言ってみる。

561 ：デフォルトの名無しさん：2008/09/02(火) 19:34:55

Objective-C涙目。しかし、たとえるならRubyかな。
触れ込みの良さ、扱いやすさと、後方互換性の欠如、筋の通らない仕様変更とか。

562 ：デフォルトの名無しさん：2008/09/02(火) 20:18:58

宗教じみてる点でも似てるな

563 ：デフォルトの名無しさん：2008/09/03(水) 06:51:40

指導者にカリスマがあるからな、仕方ない。毛はないが。

564 ：デフォルトの名無しさん：2008/09/03(水) 22:49:49

モルモン教だからだろ

565 ：デフォルトの名無しさん：2008/09/05(金) 00:46:43

神に祝福された存在であるRubyを、ちょっと小洒落てるだけがとりえのMacなんかと同列に扱わないでください＞＜

566 ：デフォルトの名無しさん：2008/09/05(金) 10:12:21

Ahura Matz 神か。

567 ：デフォルトの名無しさん：2008/09/16(火) 23:40:56

アセンブラが人手によってかかれるべきでない（コンパイラに任せたほうが良い）のと同様に、C言語もまた人手によってかかれるべきではない。

568 ：デフォルトの名無しさん：2008/09/16(火) 23:56:34

なんちゃそれ。

569 ：73.6.30.125.dy.iij4u.or.jp ：2008/09/17(水) 13:53:44

>>567
C言語を共通アセンブラと考えるとそうかもしれないね。

570 ：デフォルトの名無しさん：2008/09/18(木) 00:23:07

そこでObjective-Cですね

571 ：デフォルトの名無しさん：2008/09/18(木) 11:05:43

>>567
つまりyaccとかbisonですね

572 ：デフォルトの名無しさん：2008/09/21(日) 01:53:00

2chで語る以前に、言語開発者がｘｘｘよりは組みやすく〜とかいいつつ
アホみたいに言語増やしたけど、今だにC,C++が生き残ってるってことは
駆逐は無理。以上

573 ：デフォルトの名無しさん：2008/09/21(日) 02:58:25

>>572
それ、C,C++の部分に大抵の言語があてはまるんじゃね？
いまだにCOBOLが…、いまだにPerlが…他

574 ：デフォルトの名無しさん：2008/09/25(木) 00:06:47

CPUもコア増やすくらいしかやることないならそろそろプログラム言語に歩み寄っていいんじゃないかい？
VMがこれだけはやってんだから統一VMのモデルでも作ってネイティブでその命令実行してやれ。
そうすりゃCの呪縛も少しは薄れるだろ。

575 ：574：2008/09/25(木) 06:30:10

自分で言うのもなんだが、結構いいアイディアな気がしてきた。
VMのコードをネイティブで実行するCPUなんてのは陳腐なアイディアだが、
C言語を駆逐するためにはかなり効果あるんじゃないか？

昔はハードウェアの値段がソフトウェアの値段より遥かに高かったけど、
今じゃすっかり逆転してるわけだし、VMの技術だってかなり枯れてきているころだろう。

インテルがコア数を増やすのも限界まで来て、それでもトランジスタを増やさなければいけないとなったら、
VMの命令をネイティブでサポートなんていう道に走らないとも限らない。

C言語完全駆逐の可能性はまだ残されているっ

576 ：デフォルトの名無しさん：2008/09/25(木) 08:25:57

今のCPUがマイクロコードで実装されていることもご存じないらしい。
Intelが有数のコンパイラベンダーであることもご存じないらしい。

577 ：デフォルトの名無しさん：2008/09/25(木) 12:37:45

>>575
どっちかというと、ＣＰＵの規模より集積可能なトランジスタのほうが上回る様になってきたから、余ったトランジスタ処分用にマルチコアにしたんじゃないの？

578 ：デフォルトの名無しさん：2008/10/02(木) 01:33:27

昔の同僚に、真顔でこれを言ったアフォがおった
ツール類で何でもできるんだとよ

579 ：デフォルトの名無しさん：2008/10/02(木) 08:59:25

>>13 VCなくなったらそれこそC++なんか閑古鳥だろ

580 ：デフォルトの名無しさん：2008/10/02(木) 09:18:21

C++ってなんであんなに肥大化しちゃったの？
http://pc11.2ch.net/test/read.cgi/tech/1219902495/

581 ：デフォルトの名無しさん：2008/10/02(木) 13:26:44

ポインタ概念のないVBがこれだけ進化してるんなら逆にＣ駆逐は時間の問題かと。
昭和生まれが現役引退するころにはプログラム歴史記念館に飾られてるよ。。きっと。

582 ：デフォルトの名無しさん：2008/10/02(木) 15:31:31

>>581
組込みソフトのこともちっとは勉強しろよ坊主

583 ：デフォルトの名無しさん：2008/10/02(木) 18:27:36

小娘かもしれん

584 ：デフォルトの名無しさん：2008/10/02(木) 20:36:41

お前らはC言語無くなったら何使うん？java？

585 ：デフォルトの名無しさん：2008/10/02(木) 20:46:39

Objective-D++

586 ：デフォルトの名無しさん：2008/10/02(木) 20:56:05

はいはい
他は？

587 ：デフォルトの名無しさん：2008/10/02(木) 20:58:55

lispがはやってほしい

588 ：デフォルトの名無しさん：2008/10/02(木) 20:59:09

ポインタの概念は絶対になくならないよ
何もかも値渡しするっていうアホ言語を作るなら別だが

589 ：デフォルトの名無しさん：2008/10/02(木) 21:02:33

C並に低レベルな言語は必要
それがCである必要は無いけれども

590 ：デフォルトの名無しさん：2008/10/02(木) 21:11:44

BCPLがあまりに低レベル過ぎて使いにくすぎたから
C言語が作られたんだよな確か。

だからC言語はなくならないんじゃない？

591 ：デフォルトの名無しさん：2008/10/02(木) 21:25:23

並にって話してるのにそれより低いものを持ち出してもどうしようもないと思うぞ。

592 ：デフォルトの名無しさん：2008/10/02(木) 21:30:28

ロクな返事がねーな
代用できるものも考えずに潰すつもりだったの？君ら

593 ：デフォルトの名無しさん：2008/10/02(木) 21:42:35

C#

594 ：デフォルトの名無しさん：2008/10/02(木) 21:54:08

>>593
C#のネイティブコンパイラが出来たらな。
ngen.exeは腐っているのでもっとまともなネイティブコード
ジェネレータが必要だが。

595 ：デフォルトの名無しさん：2008/10/02(木) 22:33:43

PASCAL
PL/I

596 ：デフォルトの名無しさん：2008/10/02(木) 22:38:47

CISC アセンブラ

597 ：デフォルトの名無しさん：2008/10/02(木) 22:47:22

>>596
ARMケータイはどうするの？

598 ：デフォルトの名無しさん：2008/10/02(木) 23:02:03

要するに組み込みのハードのパワーがまだまだ貧弱なのがいかんのだろう。
あと１０年もすれば組み込みのハードもパワーが有り余ってC言語が要らなくなるんじゃない？

599 ：デフォルトの名無しさん：2008/10/02(木) 23:16:40

パワー関係ないだろ
今時のマシンだろうがbootstrapのコードはasmじゃないと書けないし
kernelのコアのコードがメモリも弄繰り回せないようでは話にならない
Cのような機能を持った言語は要るんだよ
Cである必要は無いけれども

600 ：デフォルトの名無しさん：2008/10/02(木) 23:20:20

ハードの性能とか一切関係ないよ
実用性という点においてCを超える言語が存在しないだけ
過去を考慮せず、これからのハードに的を絞っても
Cより先に処理系を用意し続けるのって不可能に近いよ
それが出来なきゃ駆逐なんて夢物語

601 ：デフォルトの名無しさん：2008/10/02(木) 23:35:34

>>584
Ｃ＋＋

602 ：デフォルトの名無しさん：2008/10/02(木) 23:36:03

Cがアセンブリを駆逐したという伝説がひとり歩きしているね
実際にはCがアセンブリと連携しやすかった所がポイントなのに

603 ：デフォルトの名無しさん：2008/10/02(木) 23:44:28

そういや、アセンブリは非常に低水準だけど、それでも大抵のハードでスタックは装備されてるんだよな。
もっといろんな概念がハードに採用されてもよさそうだけど、あんまりそうはならないね。
それだけスタックがプログラムにとって本質的ってことかな。

604 ：デフォルトの名無しさん：2008/10/02(木) 23:48:31

と思ったけど、よく考えたらハード的に特別スタックを用意してるわけじゃないんだっけ？
スタックポインタなんてなんて名前のレジスタがあるからてっきり、ハード的にスタックがあるんだと思っちゃったけど。

605 ：デフォルトの名無しさん：2008/10/02(木) 23:56:03

でもただのjumpやmoveではない、push/pop/call/retがあるあたり
命令面では特別視されている感じがする。

606 ：デフォルトの名無しさん：2008/10/03(金) 00:18:46

RISC ではそういう命令あんまりないんじゃない。

607 ：デフォルトの名無しさん：2008/10/03(金) 00:22:39

>>606
まじで？
具体的なCPUの名前教えて。

608 ：デフォルトの名無しさん：2008/10/03(金) 00:27:41

R3000なんかはそうでしたね
スタック操作も全部アセンブラでした

609 ：デフォルトの名無しさん：2008/10/03(金) 01:16:05

>>605 それマクロよ

610 ：デフォルトの名無しさん：2008/10/03(金) 07:58:45

いやマクロ違うだろ

611 ：デフォルトの名無しさん：2008/10/03(金) 12:11:43

x86 は Pentium Pro 以降ハードウェアで x86 命令をマイクロ命令に変換してる。

612 ：デフォルトの名無しさん：2008/10/03(金) 12:41:48

でもx86のIntelではPentium-Mまで、AMDに至ってはPhenomに
至るまでスタックポインタをALUで操作していたから遅かったね。
これらのCPU以降ようやくスタック操作が速くなった。

まあCALL自体は少ないとしてもPUSH/POPはレジスタの少なさ
ゆえ避けられないからな。

613 ：デフォルトの名無しさん：2008/10/07(火) 19:12:12

C言語を駆逐するのにスタックが関係あんのか？

614 ：デフォルトの名無しさん：2008/10/07(火) 19:25:37

大有りだろ

615 ：デフォルトの名無しさん：2008/10/07(火) 19:57:34

>>614
詳しく

616 ：デフォルトの名無しさん：2008/10/07(火) 20:38:17

スレの流れを見るに、Ｃはなんだかんだ言っても用途があるのでなくならない。
代替言語が仮にあったとしても、それがＣ言語を上回る訴求力が無い限り無理ぽ。
ただ、新しいハードが市場を埋め、それは既存と全く違う機械語が実装され、
そこで最初に提供された開発環境がＣ＋＋とかだったらＣは駆逐されるかもね。

617 ：デフォルトの名無しさん：2008/10/07(火) 21:19:53

スタックに次ぐ、ハードウエアに追加するほどプログラミングに必須な機能といえば…
ガベコレとか？

618 ：デフォルトの名無しさん：2008/10/07(火) 21:48:54

>616
C++がスーパーセットである以上、C++がCを駆逐することは不可能じゃないかな
その状況で例えばLispだけだったら可能性はあるかもね

619 ：デフォルトの名無しさん：2008/10/07(火) 22:02:09

>>616
拡張子.cppの中身実質Cなコードが溢れるだけ。

って、コンパイラじゃなくて開発環境か。
APIがクラスとか例外とかを平気で使っている状況かな。

620 ：デフォルトの名無しさん：2008/10/07(火) 22:15:19

ふと思ったんだが別にCを駆逐する必要なくね？
むしろ共通アセンブラとしてはベストじゃないか

621 ：デフォルトの名無しさん：2008/10/07(火) 22:21:05

共通アセンブラとしてならな。
Cで、でかいアプリ組まされるなんていう無法がまかり通るからいかんのだ。

622 ：デフォルトの名無しさん：2008/10/07(火) 22:21:54

>>621
それは言語の問題じゃないだろ

623 ：デフォルトの名無しさん：2008/10/07(火) 22:24:34

じゃあ何の問題なんだよ。

624 ：デフォルトの名無しさん：2008/10/07(火) 22:26:40

あんたの職場環境の問題

625 ：デフォルトの名無しさん：2008/10/07(火) 22:29:39

きつい一言を…（TT）

626 ：デフォルトの名無しさん：2008/10/07(火) 22:31:42

「でかい」の基準なんて分野毎に全く違う。

627 ：デフォルトの名無しさん：2008/10/12(日) 20:46:48

Linuxをスクラッチから構成すると導入したい言語はたいていCかC++のコンパイルから始まるからこりゃ駆逐なんてできないやと思った。

628 ：デフォルトの名無しさん：2008/10/12(日) 21:06:04

＞スクラッチから
……

629 ：デフォルトの名無しさん：2008/10/12(日) 21:29:51

LFSか

630 ：デフォルトの名無しさん：2008/10/23(木) 04:33:16

Hosh

631 ：デフォルトの名無しさん：2008/11/06(木) 21:20:21

self = [[Object alloc] init];

632 ：デフォルトの名無しさん：2008/11/08(土) 21:03:50

むしろランタイムがないと動かない言語が駆逐されるべき
ランタイムのバージョンやベンダーに依存して異常動作するなぞ論外
オブジェクト指向もいらね。
変数定義と関数定義はクラスで一体化するよりむしろ分けた方が
良いと思ってる。

633 ：デフォルトの名無しさん：2008/11/08(土) 21:05:20

Cもランタイム無いと動かない環境あるだろ?

634 ：デフォルトの名無しさん：2008/11/08(土) 21:25:02

あったとしても他の言語仕様が膨大な言語にくらべれば互換性は
高いはずだと思われ。

635 ：デフォルトの名無しさん：2008/11/08(土) 21:27:12

glibcみたいのはランタイムとは言わないのかな?
よく知らんけど。

636 ：デフォルトの名無しさん：2008/11/08(土) 21:29:12

POSIXのシステムコールなんて、ランタイムもいいところじゃないか。

637 ：デフォルトの名無しさん：2008/11/08(土) 21:30:53

つまりLispOSが最強ということか…

638 ：デフォルトの名無しさん：2008/11/08(土) 21:40:20

PCが機械語で動くかぎり、もっと言えばPCがメモリとCPUでできている限り、
Cが無くなることはないであろうと予言しておく。

639 ：デフォルトの名無しさん：2008/11/08(土) 21:43:43

その予言は>>28で既出

640 ：デフォルトの名無しさん：2008/11/08(土) 21:47:24

ガイシュツですたか。まあそれだけCは偉大な発明だったわけだ。

641 ：デフォルトの名無しさん：2008/11/09(日) 01:32:12

Cが、特出すべき素晴しい言語だとは思わない
突然変異的なパラダイムは何一つ無いんだから
ただ、それを記述する為に生まれたUNIXが純然たる地位を保っていることこそ
Cが現在の地位を保持しているのでは無いかと思う
Windowsですら、その呪縛からは逃れられてはいない

642 ：デフォルトの名無しさん：2008/11/09(日) 07:57:28

全然違う話で悪いんだが
UNIXは素晴らしいがCは素晴らしくないと言う人間をどう思う？

643 ：デフォルトの名無しさん：2008/11/09(日) 08:25:15

ファシスト。

644 ：デフォルトの名無しさん：2008/11/09(日) 12:33:58

Cの駄目な点は文字列の扱い。
char型の配列を操作するのはとにかく面倒なので改良型Cが欲しいところ。

645 ：デフォルトの名無しさん：2008/11/09(日) 14:06:39

Cの改良は何度も失敗してる。
全然関係ないけど、LuaみたいなのをベターCと見なせるなら、もしかするかもね。

646 ：デフォルトの名無しさん：2008/11/09(日) 20:53:07

ポインタの演算禁止とか、malloc()禁止とか、そういうコーディングルールを使ってるところは
Pascalとかでいいじゃんって思うけど、そういうレベルの人たちって、ちょっと違ってると、もう使えなくなるしな。

647 ：デフォルトの名無しさん：2008/11/09(日) 21:53:49

for文とかwhile文でbreak禁止とかストレスたまって仕方ない。

648 ：デフォルトの名無しさん：2008/11/09(日) 22:02:05

Cは覚えることが少ないから初心者向きだと思っていたが、Schemeを覚えて考えが変わった。
Cなんていらないや。

649 ：デフォルトの名無しさん：2008/11/10(月) 01:09:03

今のlisperにとってCは闇米のようなものだ

650 ：デフォルトの名無しさん：2008/11/12(水) 15:06:44

>>634
glibcのバージョン変わると起動しなくなるのが高い互換性？

651 ：デフォルトの名無しさん：2008/11/13(木) 11:46:34

動的リンクとCの言語仕様は関係無いな

652 ：デフォルトの名無しさん：2008/11/13(木) 15:17:39

>>650
それって窓で言えば
kernel32.dllやuser32.dllを別のに差し替えるようなものだぞ

653 ：デフォルトの名無しさん：2008/11/14(金) 20:47:19

Cが嫌いなら無視してればいいのに
おバカさん向けのお上品な言語が他にたくさんあるわけだし

654 ：デフォルトの名無しさん：2008/11/14(金) 21:55:54

>>653
>>4

655 ：デフォルトの名無しさん：2008/11/14(金) 22:17:59

逆にさらにアセンブラよりな「cフラット」をつくるべきだな

656 ：デフォルトの名無しさん：2008/11/14(金) 22:48:56

Cの歴史を考えるとOSを同時に作ることが必須なんじゃないか？
OSｲｲ!→ｲｲOSを作れる言語使う
CだけでなくUNIXも同時に駆逐しなければ無理だと思う

657 ：デフォルトの名無しさん：2008/11/14(金) 22:49:41

ていうかさ。

もっと強烈凶悪なプリプロセッサがCに追加されたら、Cを駆逐しようなんて意見はなくなると思うな。

658 ：デフォルトの名無しさん：2008/11/14(金) 23:06:41

テンプレートのことか？

659 ：デフォルトの名無しさん：2008/11/14(金) 23:19:13

テンプレートも欲しいし、
いくつか追加して欲しい演算子もあるな。

でも、それができたらきっとCで満足してしまいそうな俺が居る。

660 ：デフォルトの名無しさん：2008/11/15(土) 01:20:50

C++の機能を適度に導入するのは賛成
というか実際そういう方向へむかってますね

661 ：デフォルトの名無しさん：2008/11/15(土) 08:46:32

効率は重要だけどCの低レベルさは嫌いとか、そんな都合いい話あるわけないじゃん
それが理解できないやつがC駆逐とかポストC言語に期待とか幻想抱くんだろうな

662 ：デフォルトの名無しさん：2008/11/15(土) 15:32:56

Pascalとか昔の構造化BASICくらいのレベルなら、いまの最適化技術なら、Cと変わらないコードができるよ。

663 ：デフォルトの名無しさん：2008/11/15(土) 17:20:30

>>662
pascal はね、共用体が変だし、; をかく場所も理屈っぽいし、なによりも、おなじことを書くのにc の倍のタイプ量になるのもやだし。
basic? 論外。

664 ：デフォルトの名無しさん：2008/11/19(水) 21:48:41

C言語を使っている組織・人間に対し武力介入を行う

665 ：デフォルトの名無しさん：2008/11/20(木) 03:23:34

>>664
ネット潰すのより難しそうだな

666 ：デフォルトの名無しさん：2008/11/20(木) 10:48:11

暗黙の型変換などを排除したstrictCが欲しい

667 ：デフォルトの名無しさん：2008/11/22(土) 23:36:47

色んなハード向けのコンパイラ屋がいる限り、
やっぱり駆逐されることはまず無いだろうね。

言語機能を機械語に置き換える量が最小元。
・新たなハードが出ても直す所はちょこっと

しかも、冗長さが無いのでパースが楽。
・クラス構文なんか付加されるだけでも割とダルい

ランタイムライブラリが殆どない
・ハード構成に合わせGCなんかを作るのは手間

単純でいて、OSが作れるほど実用的。
・lispなどもっと単純な言語もあるがハードには不向き

これを越える言語がないとなぁ。

668 ：デフォルトの名無しさん：2008/11/25(火) 00:54:20

Cって
遅い(実行速度じゃなくて開発の早さ)
高い(スキルのある人を探すと)
低機能(高級でないという意味で)
だけど早い安い高機能に負けないのは汎用性が他の追従を許さないからでは
高機能と汎用性って相反してる気がするからCは生き残るんじゃないかな
真っ白なノートと塗り絵のノートの違いみたいな
なんて素人なりに考えてみました

669 ：デフォルトの名無しさん：2008/11/25(火) 15:23:23

Cコードを吐く特定の言語の)コンパイラがあればすべて解決だろ？
C++(cfront)が失敗だろうが他の{実装|言語}でトライすればいいだろｊｋ

670 ：デフォルトの名無しさん：2008/11/25(火) 17:40:29

>>669
　最適化の邪魔になる構文と、人間のための構文を仕様から
除去しないと難しいな。そうなると、最早Cでは無いが。
因みに、GCCの中間コードには近い物が有り、実用化されてるけどね。

671 ：デフォルトの名無しさん：2009/01/25(日) 05:39:19

移植性の問題はコンパイラじゃなくてジェネレータにすればかなり解決するんじゃないか？
というか、昔のC++しかりCのコードを吐くジェネレータは多そうだけど、実際どうなの

672 ：デフォルトの名無しさん：2009/01/25(日) 08:09:17

とりあえずガベコレ搭載したObjective-C 2.0でいいんじゃないか？

673 ：デフォルトの名無しさん：2009/01/25(日) 10:42:01

おまえらがC言語以外の言語で素晴しいソフトをどんどん作ればいいのさ

674 ：デフォルトの名無しさん：2009/01/25(日) 10:42:42

色んな思想があるから、色々と（微妙な）亜種が登場して
なんだかんだで C が生き残る

675 ：デフォルトの名無しさん：2009/01/25(日) 12:13:48

Dだろ

676 ：デフォルトの名無しさん：2009/01/25(日) 12:39:49

>>675
じゃあDで頑張って駆逐してください

677 ：デフォルトの名無しさん：2009/01/26(月) 01:47:32

Dとか最速消滅候補だろｗｗｗ

678 ：デフォルトの名無しさん：2009/01/26(月) 09:49:56

なんだかんだいってＣでつくっちゃうよな
確かにオブジェクトシステムとガベコレがないのは痛いが
あとインラインアセンブラはＤのほうがいい

679 ：デフォルトの名無しさん：2009/01/26(月) 22:13:12

しかしDよりはCのほうがいい。

680 ：デフォルトの名無しさん：2009/01/26(月) 23:18:56

Java、D、C#とかの構文よりもCの構文のほうが綺麗だと思う
もしCにGCとか無名関数があるとしたら、絶対Cを使うね

#オブジェクト指向なんて飾りです。えろい人にはそれがわからんのです

681 ：デフォルトの名無しさん：2009/01/26(月) 23:22:30

Boehm GCでも使えばいいじゃん

682 ：デフォルトの名無しさん：2009/01/27(火) 00:04:03

>>681
ｽﾏﾝ。言いたかったことがかなりずれてた
君たちはCとJava、D、（ｒｙだったら、どの構文がすきなのさ？

683 ：デフォルトの名無しさん：2009/01/27(火) 01:28:02

scheme

684 ：デフォルトの名無しさん：2009/01/27(火) 01:41:37

なんだ、ナンバーサインの人か

685 ：デフォルトの名無しさん：2009/01/27(火) 07:45:12

私じゃないよ。
# ←ここに空白を入れる人と入れない人がいる。

686 ：デフォルトの名無しさん：2009/01/28(水) 00:15:01

>>682
RPN

687 ：デフォルトの名無しさん：2009/01/28(水) 07:15:28

>>680
自分は別に構文に関しては気にならないけど、
Java とか C# でどこら辺が汚いっすか？

688 ：デフォルトの名無しさん：2009/01/28(水) 09:13:17

>>687
まぁ言語自体がどうこうと言うより、
使ってる奴の頭が汚染されてるんだよね。特にJavaはｗ

689 ：デフォルトの名無しさん：2009/01/28(水) 12:44:04

>>687
Javaの構文のうざさは異常
もうちょっと簡潔に書ければ文句ないんだが

690 ：デフォルトの名無しさん：2009/01/28(水) 16:52:10

>>1人類を駆逐すればC言語を完全に駆逐できますよ

691 ：デフォルトの名無しさん：2009/01/30(金) 01:23:27

だれかはやくネイティブ吐けるC#コンパイラつくってくだしあ

692 ：デフォルトの名無しさん：2009/01/30(金) 08:04:59

CLIのバイトコードを直接実行できるCPUがあると便利かなあ。

693 ：デフォルトの名無しさん：2009/01/30(金) 08:57:59

>>691

その発言の%s/C#/java/ してごらん

694 ：デフォルトの名無しさん：2009/01/30(金) 22:55:28

gjcがどうしたって？

695 ：デフォルトの名無しさん：2009/01/30(金) 23:05:01

Cの嫌いなところは標準ライブラリが貧相なこと
そして昔、C言語はライブラリが充実していて移植性が高いと吹聴していた
影響でC言語で書けばワンチップマイコンからスーパーコンピュータまで
どんなプログラムでも動くと勘違いするお客さんの多いこと･ﾟ･(ﾉД`)･ﾟ･

696 ：695：2009/01/30(金) 23:07:16

誤）どんなプログラムでも動くと勘違いするお客さんの多いこと
正）どんなプログラムも無修正で動くと勘違いしているお客さんの多いこと

697 ：デフォルトの名無しさん：2009/01/31(土) 02:05:33

でも実際のところ、ポータビリティでCより勝る言語って無いでしょ？

698 ：デフォルトの名無しさん：2009/01/31(土) 04:37:30

わざわざCの構文に似せた言語を作るのやめてくれ。
要らない記号だらけで読みにくいんだよ。

699 ：デフォルトの名無しさん：2009/01/31(土) 09:17:22

俺はもっと記号を増やすべきだと思うんだが。
それともlisp見たいのがいいのか？

700 ：デフォルトの名無しさん：2009/01/31(土) 09:34:01

Lispが理想なんだが、多くの人はC風のが読みやすいのかな？

701 ：デフォルトの名無しさん：2009/01/31(土) 09:55:39

慣れだろ

702 ：デフォルトの名無しさん：2009/02/01(日) 00:10:10

チューリングマシーン！！！

703 ：デフォルトの名無しさん：2009/02/01(日) 01:04:39

Cなんて組み込みでしか使われんだろ？
駆逐されたも同然じゃん

704 ：デフォルトの名無しさん：2009/02/01(日) 01:17:36

君の住んでる世界でCが使われてないだけです

705 ：デフォルトの名無しさん：2009/02/01(日) 06:54:34

>>703
それじゃ駆逐されたとは言えん
このスレの目指す先はCの完全消滅だ

706 ：デフォルトの名無しさん：2009/02/01(日) 11:48:12

そういう意味ではＣを消滅させられる可能性があるのはＤだったけど・・

707 ：デフォルトの名無しさん：2009/02/01(日) 14:25:09

>>698
つCOBOL

708 ：デフォルトの名無しさん：2009/02/02(月) 12:20:20

アルマゲドンで爆破が成功せずに地球に落ちたらCの完全消滅完了

709 ：デフォルトの名無しさん：2009/02/04(水) 22:11:35

オブジェクト指向以前の世代の言語としての完成形がCだから。
C++, C#, Java とかこの辺はみんなCの子供達であって、内部にCを持っているようなもの。
そういう意味ではCを駆逐することはできないだろう。

CのライバルはPascalとかであって、現代のひ弱な息子達ではないのだ。

710 ：デフォルトの名無しさん：2009/02/04(水) 22:36:27

Pascalこそ完全駆逐された言語だろが

711 ：デフォルトの名無しさん：2009/02/04(水) 23:06:25

Pascalの記述法（BEGINとかENDとか）は現在でもC系と勢力を二分しておる。
今でもCとPascalの代理戦争は続いてるんだ。

712 ：デフォルトの名無しさん：2009/02/04(水) 23:15:16

なつかしいな

#define BEGIN {
#define END }

713 ：デフォルトの名無しさん：2009/02/04(水) 23:27:11

C#はCの姿を借りたPascalの末裔だと思うが

714 ：デフォルトの名無しさん：2009/02/04(水) 23:30:26

PascalはDelphiの心の中で今も眠っています。

715 ：デフォルトの名無しさん：2009/02/04(水) 23:36:41

行儀良くプログラムが書けるという意味ではpythonがPascalの正当な継承者かもね

716 ：デフォルトの名無しさん：2009/02/05(木) 03:23:43

while(1)
{　　　　　　　　　
　　　　　wakeup;
　　　　　static int day;
　　　　　int time = wakeuptime();
　　　　　while(1)
　　　　　{
　　　　　　　　　　2ch;
　　　　　　　　　　if(time == Daytime())
　　　　　　　　　　{
　　　　　　　　　　　　　　lunch;
　　　　　　　　　　};
　　　　　　　　　　if(time == nighttime())
　　　　　　　　　　{
　　　　　　　　　　　　　　supper;
　　　　　　　　　　};
　　　　　　　　　　if( time == sleeptime();)
　　　　　　　　　　{
　　　　　　　　　　　　　　break;
　　　　　　　　　　}
　　　　　　　　　　time++;
　　　　　}
　　　　　 day++;
　　　　　sleep;
}

こんな毎日、無限ループって怖いよな；；

717 ：マイク ◆gZ6OoOjBU6 ：2009/02/05(木) 06:32:58

努力せずCという言語に依存し続ける無能な年寄りは無能な若者は確かにいらないと思う。
だがCはCで高級アセンブラ的側面を残している。
C++のような面倒なオブジェクト指向要素を排除してだ。
だからCは衰えはするけれども無くなることは無いだろう。
だって仕事しながら普通に家庭を持って家族を養って普通に生活する為には
いつまでも限りの無いコンピュータオタクで居続ける
コンピュータオタクとして努力しつづけることは不可能だもの。
俺のこの分析は間違いないだろう。

718 ：マイク ◆gZ6OoOjBU6 ：2009/02/05(木) 06:33:50

無能な年寄りや無能な若者。

719 ：デフォルトの名無しさん：2009/02/05(木) 08:28:55

Fortranは勝ち組だな

720 ：デフォルトの名無しさん：2009/02/05(木) 09:16:49

C+　ぐらいのを作ればいいんだよ。

721 ：デフォルトの名無しさん：2009/02/05(木) 09:19:54

久しぶりだな、糞ｺﾃ。もう来るなよ。

722 ：マイク ◆gZ6OoOjBU6 ：2009/02/05(木) 17:41:03

俺が思うに
ダンゴリオンというかコテはそれなりに優秀だと思うが
>>721お前のような口だけの名無しはたいした事無いよ。

723 ：デフォルトの名無しさん：2009/02/05(木) 18:13:35

と糞コテが申しております

724 ：デフォルトの名無しさん：2009/02/05(木) 19:36:53

口だけの糞コテ

725 ：マイク ◆gZ6OoOjBU6 ：2009/02/06(金) 07:41:07

口だけって言われても・・・
お前も口だけの糞名無しじゃん。

726 ：デフォルトの名無しさん：2009/02/06(金) 08:11:37

Cは使ってないけど駆逐する必要を感じない。

727 ：デフォルトの名無しさん：2009/02/06(金) 08:24:22

ＣがいらないとかｗｗｗＣがこんだけ普及したのはなぜだろうねえ
良く考えればわかりそうなもんだが

728 ：マイク ◆gZ6OoOjBU6 ：2009/02/06(金) 09:18:44

>>727
シンプルで使いやすい
高級アセンブラっぽくてアセンブラより便利
構造化プログラミング言語としてまあ成功してる
と言う感じじゃね

729 ：デフォルトの名無しさん：2009/02/06(金) 13:51:12

コンピューター史において普及した確実な理由なんてのはないと思うがなぁ
Cと*nixが普及した理由より、Lispマシンなどのその他が
主流であり続けられなかった理由を考えた方が興味深いかもしれん

730 ：デフォルトの名無しさん：2009/02/06(金) 13:59:48

少なくとも、多くのプロセッサが8bit (せいぜい16bit) だった時代には
処理系の作り易さ、実用性、可搬性、作られたプログラムの軽さで
C以外に主役になれる言語なんかなかったからな。

731 ：デフォルトの名無しさん：2009/02/06(金) 14:08:32

worse is better

正しさと単純さのトレードオフ

732 ：デフォルトの名無しさん：2009/02/06(金) 14:11:32

Worse is worse
http://www.kt.rim.or.jp/~hisashim/waldo/worseisworse.ja.html

733 ：デフォルトの名無しさん：2009/02/06(金) 14:20:52

ここで >>448 にもどる

734 ：デフォルトの名無しさん：2009/02/07(土) 21:16:48

１．Cより、より簡単な文法である。
２．GCはない。
３．Cよりもアセンブラ的なことができる。
４．マクロがCよりより現代的だ。
５．型推論があったりする。
６．C言語より安全だ。

コンパイラの性能としては昔に比べると、
コンパイルスピードはおいて置いて、メモリは食ってもいいのではないかと。

とかいう言語があればいいんじゃないかと。

735 ：デフォルトの名無しさん：2009/02/07(土) 21:38:18

つまりD言語からGCを取っ払えと

736 ：デフォルトの名無しさん：2009/02/07(土) 22:35:26

もうアセンブラでいいじゃん

737 ：デフォルトの名無しさん：2009/02/08(日) 06:22:53

これからの時代、C++は避けても大丈夫？
そりゃ会社で使うように指示されてるなら避けられないけど、趣味の範囲でとしたら。
Cはやっとくべきかなとは感じてるけど、C++はやだなあ。

738 ：デフォルトの名無しさん：2009/02/08(日) 10:25:35

>>737
> 趣味の範囲で
趣味なんて十人十色なので、これだけじゃ回答のしようがないな。
「何をやりたいか」をはっきり言ってくれんと。

739 ：デフォルトの名無しさん：2009/02/08(日) 12:50:59

>>737
趣味でやるならC++なんか逆に面白いのかもしれんぞ

740 ：デフォルトの名無しさん：2009/02/08(日) 12:54:01

趣味でやるなら C++0x

741 ：デフォルトの名無しさん：2009/02/08(日) 13:13:29

配列とかメモりブロックがサイズ情報さえ持ってればなあ。

742 ：デフォルトの名無しさん：2009/02/08(日) 14:14:38

>>741
コンパイル時にサイズが決まる配列は情報もってる

int main() {
　int foo[100];
printf("foo's size = %d\n", sizeof(foo) / sizeof(*foo));
　// VCだと↓でもおｋ
　// printf("foo's size = %d\n", _countof(foo));
}

出力結果
foo's size = 100

743 ：デフォルトの名無しさん：2009/02/08(日) 20:42:45

>>742
そういう話じゃないだろ
c99だと動的に長さ与えてもsizeofで長さが取れるし
int len=10;
int arr[len];


mallocしてヒープから取った場合の話だろ

744 ：デフォルトの名無しさん：2009/02/08(日) 23:02:07

それは配列とは言わんだろ

745 ：742：2009/02/08(日) 23:17:38

>>741
>>743
ヒープからメモリ確保するたびに自動でどっか変数に
確保したサイズを保存するとなるとオーバーヘッドになるから、
C言語の今の仕組みの代替にはならんのではと思う。

おとなしくstd::vectorか自前関数作るのが良いと思う。

746 ：デフォルトの名無しさん：2009/02/09(月) 11:29:32

>>745
>変数に
>確保したサイズを保存するとなると
ヒープの管理上、ほぼ例外なく持ってる筈なんで
それを取得する手段が標準化されれば済む話じゃね？

747 ：デフォルトの名無しさん：2009/02/09(月) 11:52:52

例外ありまくりです
50バイト必要なときに64バイト確保した場合
50という数字はどこにも記録されないなど

748 ：デフォルトの名無しさん：2009/02/09(月) 12:02:30

成程。
では保存するようにすればよいではないか。

749 ：デフォルトの名無しさん：2009/02/09(月) 12:07:45

共通アセンブラとしての役割なら C より LLVM IR のほうがいいんじゃない？

750 ：デフォルトの名無しさん：2009/02/09(月) 12:47:51

>>746
ヒープの管理領域から得られるサイズは要求したサイズと必ずしも一致するわけでは無いので、別にサイズを保存しなければならない。
いろんな理由で要求サイズより大きくなる場合がある。

751 ：デフォルトの名無しさん：2009/02/10(火) 03:04:40

>>748
オーバーヘッドになるから組み込みの人たちには嫌がられるだろうねー。俺も嫌だ。
でも需要があるのでサイズ保存するようにしたのがC++のvector

752 ：デフォルトの名無しさん：2009/02/10(火) 11:38:11

>>751
>オーバーヘッドになるから
速度的には malloc/free のとき以外に影響はないわけだが。
その程度が気になるほど何度も割り当てと解放を繰り返してるなら
そっちの方がよっぽど問題。

>C++のvector
違。

753 ：デフォルトの名無しさん：2009/02/10(火) 14:17:40

で、
int n[10], *p = n + 3;
とした時、pのサイズはどういうカラクリで取得すればいいんだよ。

754 ：デフォルトの名無しさん：2009/02/10(火) 14:24:11

ヒープの話してたんじゃないのか？

755 ：デフォルトの名無しさん：2009/02/10(火) 14:30:12

printsize(void *p){
　printf("%d\n", sizeof(*p));
}
でサイズとれなきゃ意味なさすぎ。
autoだろうとstaticだろうとヒープだろうと区別なくメモリの塊として
ポインタでこねくり回すのがCのコンセプトなんだからな。

ヒープのサイズ知りたいだけなら現状でもヘッダ覗けば取れるだろ。
完全に環境依存になるが。

756 ：デフォルトの名無しさん：2009/02/10(火) 14:39:05

言いたいことは、わかったから、もう一度仕様を読んできてください。

GCCのglibcなら、malloc.hのmalloc_usable_size()とかだったかなで、
malloc()で確保されたバイト数がわかるはず。

それが嫌なら、自分で構造体を利用して俺様ポインタでも作れば良い。

いい加減スレ違い以上

757 ：デフォルトの名無しさん：2009/02/10(火) 14:47:12

ヒープ使えるようなシステムならわざわざCを使ったりしない。
他の言語使う

758 ：デフォルトの名無しさん：2009/02/10(火) 16:50:11

>>734
テンプレートほど強力じゃなくてもいいから総称型とオーバーロードがあると
型推論が活躍すると思います。あとC++よりも見やすいABI。

それと、インラインアセンブラで生成したコードをchar配列に突っ込んで書き換えやすくする機能
(xbyakみたいなの)欲しい

759 ：デフォルトの名無しさん：2009/02/10(火) 17:02:04

Cに対する改善案は数あれど本当にそれがパフォーマンスを低下させることなく
生産性を引き上げるのかといわれると微妙なのばっかりなんだよな。
大半がオナニーシンタックスシュガーにとどまってるものばかり。
膨大な数のコンパイラに対してアップデートを強要する動機づけとしてはあまりにも弱い。
Cの進化がかなり保守的なのもわかる気がするよ。

760 ：デフォルトの名無しさん：2009/02/10(火) 17:30:25

>>758
>インラインアセンブラで生成したコードをchar配列に突っ込んで書き換え
ウィルス作るんですね？

761 ：デフォルトの名無しさん：2009/02/10(火) 18:06:50

いいえJITです

762 ：758：2009/02/11(水) 01:39:42

>>760
その発想はなかった.......orz

763 ：デフォルトの名無しさん：2009/02/11(水) 10:08:16

このスレももうすぐ駆逐されそうですね

764 ：デフォルトの名無しさん：2009/02/11(水) 10:15:32

C駆除厨が完全に駆除されたわけか
Cは向こう100年は安泰だな

765 ：デフォルトの名無しさん：2009/02/11(水) 10:51:44

C駆除厨の心境「ハードウェアの革新的飛躍に期待」

766 ：デフォルトの名無しさん：2009/02/11(水) 16:11:03

>>765
FPGAベースで、ほとんどの言語を駆逐するあれか!!

767 ：デフォルトの名無しさん：2009/02/12(木) 01:42:44

いや、壊れると腐ってハエがたかるあれじゃないかな

768 ：デフォルトの名無しさん：2009/02/12(木) 03:15:13

FPGAはまずクソ環境をなんとかすべき
Xilinxとかやる気をそがれる

769 ：デフォルトの名無しさん：2009/02/14(土) 20:59:24

>>757
>ヒープ使えるようなシステムならわざわざCを使ったりしない。
>他の言語使う

ハァ？テメエ、ヒープの意味すらわかってねーだろバカタレ

770 ：デフォルトの名無しさん：2009/02/14(土) 21:08:59

OS乗ってなかったらヒープもないんじゃね？

771 ：デフォルトの名無しさん：2009/02/14(土) 21:09:31

s/ないんじゃね/ないじゃん/

772 ：デフォルトの名無しさん：2009/02/14(土) 21:57:59

>>770
>OS乗ってなかったらヒープもないんじゃね？

お前もわかってない。
ヒープ以前にスタックの意味がわかってない

773 ：デフォルトの名無しさん：2009/02/14(土) 22:31:17

>>772
ん、誤解があったかな？

スタックはOS無くてもコンパイラが作ってくれるけど、
ヒープ（mallocとか）は自分で書かないと使えないじゃないすか。

774 ：デフォルトの名無しさん：2009/02/14(土) 22:39:49

cellのspeを生で使おうとしてたとき、普通にヒープなんてなかったぜ

775 ：デフォルトの名無しさん：2009/02/14(土) 22:43:10

最近まで、「プログラムしね。C言語うんこめ」なんて思っていたけど、
いろいろ調べてみたり、打ってみて、プログラミングに熱くなる人の気持ちが分かる気してきた。
Cを取り合えず頑張ってみる宣言

776 ：デフォルトの名無しさん：2009/02/14(土) 23:52:50

スレタイくらい読めよｗ

777 ：デフォルトの名無しさん：2009/02/15(日) 01:17:42

C 並みに低レベルなコードだけが書けて、かつもっと安全な言語仕様(型とか)の
言語が出てくれば、自然と移り変わっていくんじゃねーかなーと思った。

778 ：デフォルトの名無しさん：2009/02/15(日) 01:28:26

>>777
それだけ聞くとC++のようだ。

779 ：デフォルトの名無しさん：2009/02/15(日) 01:31:40

まぁ現に組み込み業界とか徐々にC++に移り変わってるけどな

780 ：デフォルトの名無しさん：2009/02/15(日) 01:58:47

詰め込みで肥大化？

781 ：デフォルトの名無しさん：2009/02/15(日) 02:16:03

templateの無いC++ほしい

782 ：デフォルトの名無しさん：2009/02/15(日) 08:49:25

それじゃ何の役にも建たない

783 ：デフォルトの名無しさん：2009/02/15(日) 11:17:51

>>778
平たく言えば、c++ からオブジェクト指向の概念やらの、より高度な仕様を抜いた感じ。

784 ：デフォルトの名無しさん：2009/02/15(日) 11:31:02

>>783
それ、 C++ に比べて何がいいの？

785 ：デフォルトの名無しさん：2009/02/15(日) 11:38:50

>>784
単純。

786 ：デフォルトの名無しさん：2009/02/15(日) 13:37:56

Ｃしかコンパイルしないコンパイラ探すほうが大変な昨今
ぶっちゃけおんなじ事をＣで書くのとＣ＋＋で書くのと
どっちがコード少なくやれるんだべ？

787 ：デフォルトの名無しさん：2009/02/15(日) 13:46:34

>>744
>とかメモりブロックがサイズ持ってたらなぁ
配列限定の話じゃないみたいだが
mallocしたメモリブロックを配列と呼ぶ人は多いし(違いを理解していても)、そこは空気読むべきだったと思う

788 ：デフォルトの名無しさん：2009/02/15(日) 22:34:20

>>786
余りにアバウトすぎてなんとも言えねぇｗｗｗｗ

789 ：デフォルトの名無しさん：2009/02/15(日) 23:24:34

C++の方が大規模になればなるほどCに比べてコード量は少なくできる部分が
多くなると思うが、指数的に比例して頭を使う量が増えると思うｗ

790 ：デフォルトの名無しさん：2009/02/16(月) 00:59:33

C++ってひとくくりに言うけど環境によって全然違うよね
CだったらC89くらいなら対応を期待できるが
C++は例外使えないとかありがち

791 ：デフォルトの名無しさん：2009/02/16(月) 01:52:39

ねーよ。

792 ：デフォルトの名無しさん：2009/02/16(月) 07:52:41

Embedded C++ と C++は別もんだろう

793 ：デフォルトの名無しさん：2009/02/16(月) 19:50:27

>>792
どうしたww
いきなりww

794 ：デフォルトの名無しさん：2009/02/17(火) 11:45:36

おまえらもよく知ってるアホみたいに売れてる携帯ゲーム機は例外使えないよ

それとプロジェクトで例外禁止はものすごくよくあるだろ

795 ：デフォルトの名無しさん：2009/02/17(火) 13:14:36

>>794
>それとプロジェクトで例外禁止はものすごくよくあるだろ
流石のウチも、そこまで間抜けはいない。

796 ：デフォルトの名無しさん：2009/02/17(火) 23:06:37

googleのC++のコーディング規約は例外禁止だったな。

797 ：デフォルトの名無しさん：2009/02/18(水) 02:39:33

任○堂もソ○ー（PS3以前）も例外禁止
mozillaも例外禁止
BREWも例外禁止
確かによくあることだなｗ

798 ：デフォルトの名無しさん：2009/02/18(水) 09:26:51

google: 既存コードが例外を考慮していないから。
ゲーム屋: 知らん。なんで？
mozilla: 実装していない処理系で利用できなくなるから。
BREW: うんこだから。
>>794: よく解らないから。

799 ：デフォルトの名無しさん：2009/02/18(水) 12:39:21

mozilla を除いて例外がモジュールの境界をまたがないルールにすれば使っても問題ないんじゃない？

800 ：デフォルトの名無しさん：2009/02/18(水) 18:43:28

そんなルールあってないようなものだから危険すぎるだろ

801 ：デフォルトの名無しさん：2009/02/18(水) 21:55:10

Googleだったら、速度重視するのに邪魔だったという理由が
付加されていても不思議に思わない。
高級さが欲しければPythonでも使っていろってことで。

802 ：デフォルトの名無しさん：2009/02/18(水) 22:24:56

たしか VC と GCC4 は try ブロックの出入りと throw したとき以外は例外による実行
コストは 0 だったような気がする。
コンパイラが悪いと例外を使っていなくても関数の出入りで負荷がかかるかもしれない。

803 ：デフォルトの名無しさん：2009/02/18(水) 23:09:59

他のスレでもそうだけど、何でC++厨って
C++スレでもないのにスレ違いな事を長々と書きこむの？

804 ：デフォルトの名無しさん：2009/02/19(木) 00:11:35

>>803
お前がいらいらする様をみたいから

805 ：デフォルトの名無しさん：2009/02/19(木) 15:07:54

他のスレでもそうだけど、何で
　　「他のスレでもそうだけど、何で××厨って
　　　△△スレでもないのにスレ違いな事を長々と書きこむの？」
みたいな事を言う奴って
スレに沿った話題も提供せず文句ばっか書き込むの？

806 ：デフォルトの名無しさん：2009/02/19(木) 16:15:33

これは自己参照レスか

807 ：デフォルトの名無しさん：2009/02/19(木) 22:34:02

BitC って言語がある。コンセプトはなかなかよさげ。
まだまだ alpha 版って感じだけど。

ttp://www.bitc-lang.org/

トップページと言語仕様の最初のほうだけをざっと
見ると、
* 型推論
* 値としての関数(型安全)
あたりを C に取りこんだって感じ？シンタックス
今んとこ、便利だからっていう理由(パースしやすい
とかそういう理由かな) で Scheme ライクなものを
選択してるみたい。

808 ：デフォルトの名無しさん：2009/02/19(木) 23:19:02

ゲームに関しては例外発生した時点で製品品質がアウトだし復帰できるような
処理でもないからだな。

処理が失敗して巻き戻るとかゲームじゃ許されねぇ。

809 ：デフォルトの名無しさん：2009/02/19(木) 23:31:29

これまでの言語に毛の生えた程度の新しい言語じゃ、
少しばかり文法や使い勝手が向上しても誰も見向きもしないよ。
誰がわざわざそんな言語覚えようとするんだい？

そして、C++, Java, C#, VB などが生き残ってるのは何故か考えてみよう。
言語の存在価値があるのは、言語類型やアーキテクチャが全く別物か、
そもそも根本的に違う言語であるかの時でしかない。

810 ：デフォルトの名無しさん：2009/02/20(金) 02:21:41

趣味で　C でニンテンドーDSの開発やってて
少し規模が大きくなると、綺麗に管理したくなってきて
クラス使ってインスタンスを操作する流れにしたくなっちゃうんだけど
自分はオブジェクト指向言語に毒されてるんかなぁ
組み込みの分野では C の言語仕様で十分なんすか？

811 ：デフォルトの名無しさん：2009/02/20(金) 09:59:20

型に執着して派生型とか汎用型とか共変とか反変とか
芋蔓式に出てくる今現在のオブジェクト指向 が 毒されている感はある

812 ：デフォルトの名無しさん：2009/02/20(金) 11:19:26

>>808
品質（笑）
雑魚ゲーム屋のエラー処理なんて
無限リトライか停止しかないだろｗ

>>810
速度やリソースとの兼ね合い。

813 ：デフォルトの名無しさん：2009/02/20(金) 11:55:51

>>808
みんながこういう認識なら例外禁止にしたほうがいいかも。

814 ：デフォルトの名無しさん：2009/02/20(金) 12:26:21

例外禁止にしても例外処理が要らないわけじゃないんだけどな。

815 ：デフォルトの名無しさん：2009/02/20(金) 13:18:10

>>808
ディスク、ネットワーク、バックアップメディアなどの処理ではエラーから復帰しないと
だめだろう。

816 ：デフォルトの名無しさん：2009/02/20(金) 16:03:46

ハングするゲームちょくちょくあるよなｗ

817 ：デフォルトの名無しさん：2009/02/22(日) 17:13:04

ゲームの世界だと例外を適切に処理しないことよりプログラムが停止することの
方がリスキーという認識なのかな。

その結果想定外の状態が発生したとしても貴重なデータが破壊されたり
人が死んだりする致命症にはならないわけだし。

818 ：デフォルトの名無しさん：2009/03/14(土) 22:22:19

ttp://www.jisc.go.jpでJISのC言語の規格の文書がタダで読めることを
C++のスレで知って読んでたら間違いを見つけました。
6.3.2.1の第２段落の最初の行の最後の「演算子」は「.演算子」の誤り。

819 ：デフォルトの名無しさん：2009/03/15(日) 01:32:51

例外、テンプレなしc++ってけっこう便利だと思うんだが。

820 ：デフォルトの名無しさん：2009/03/15(日) 02:32:42

例外、テンプレありならもっと便利だよ。

821 ：デフォルトの名無しさん：2009/03/15(日) 14:02:57

Cを駆逐するために登場したDがCより先に駆逐されたな

822 ：デフォルトの名無しさん：2009/03/15(日) 16:44:33

駆逐されたというか誰にも相手をされずにひっそり孤独死したような感じ

823 ：デフォルトの名無しさん：2009/03/15(日) 16:47:38

おまいら勝手に殺すなｗ

824 ：デフォルトの名無しさん：2009/03/15(日) 16:49:26

まったくだ。まだ生まれてもいないだろ。

825 ：デフォルトの名無しさん：2009/03/15(日) 18:34:18

流産だな

826 ：デフォルトの名無しさん：2009/03/15(日) 18:36:58

堕胎したのか

827 ：デフォルトの名無しさん：2009/03/16(月) 13:02:33

デストラクタで例外を投げるなとあれほど言ったのに…

828 ：デフォルトの名無しさん：2009/03/16(月) 13:20:22

けへへ、以前納品したアプリ、CでC++のクラスっぽい実装してたんだけど
まさしくデストラクタっぽい後処理関数で例外を投げるに等しい処理をしていたことに今頃気付いた。
まぁ、アプリ終了時しかその関数に行かないし、終了するのは外部から殺されるときだからどうでもいいと言えばどうでもいいのだけれどw

829 ：デフォルトの名無しさん：2009/03/16(月) 23:52:34

Cでクラスのまねごとしてるだけなら別に問題ない。

830 ：デフォルトの名無しさん：2009/03/17(火) 00:00:22

「Cでオブジェクト指向プログラミングするテクニック」みたいのって幾度となく見てるけど、
カプセル化とか抽象データ型くらいまでまではいいけど、継承とか多態までいくと
「それムリがあるだろ」って感じになるな。マにうけるやつがいるから、ああいうの広めるの
やめてほしい。

831 ：デフォルトの名無しさん：2009/03/17(火) 00:29:39

オブジェクト指向言語が裏でなにやってるかわかって勉強になるんじゃまいか？
実際に仕事でそうコーディングされたらたまらんが。

832 ：デフォルトの名無しさん：2009/03/17(火) 00:39:19

>>830
多態って構造体のメンバに関数ポインタでも持たせておくのかな。
自分でやろうとは思わないけど、個人的には許容範囲。

833 ：デフォルトの名無しさん：2009/03/17(火) 00:41:58

cでベクタグラフィックスベースのGUIツールキット作ったときは、
多態や継承だらけになるように設計したよ。
どのコントロールも基本的な動きはおなじで、かつ置換可能だったからね。

834 ：デフォルトの名無しさん：2009/03/17(火) 11:52:34

ふざけて課題でやった事あるけど、それこそ仕事でそんな事やるぐらいならC++使えよｗ

835 ：デフォルトの名無しさん：2009/03/17(火) 16:12:21

>>832
Xツールキットで派生クラス作るときは必須。

836 ：デフォルトの名無しさん：2009/03/18(水) 03:15:58

そうかなあ

837 ：デフォルトの名無しさん：2009/03/18(水) 21:11:14

Cを駆逐ってお前ら…
どう考えても、まずJavaを駆逐するべきだろ。

838 ：デフォルトの名無しさん：2009/03/18(水) 22:29:34

>>837
無理して駆逐しなくても、そのうち自然消滅するだろう。
携帯を見れば分かるように、あんなもんエンドユーザにとって
何のメリットも無い。

839 ：デフォルトの名無しさん：2009/03/18(水) 22:57:52

いま案件数でトップだから、完全消滅まで時間かかりそうですな

840 ：デフォルトの名無しさん：2009/03/18(水) 23:35:36

Javaの価値ってJavaVMによるポータビリティと莫大なソフトウェア資産ってところ？
ほかには何かあったっけ？

841 ：デフォルトの名無しさん：2009/03/19(木) 04:58:36

サンって身売り先探してるらしいじゃん

842 ：デフォルトの名無しさん：2009/03/19(木) 08:00:55

JavaはIBMが駆逐しそうです。（＞＜）

843 ：デフォルトの名無しさん：2009/03/20(金) 00:40:07

特急グリーン車をお望みならばこちらへ
http://www.microsoft.com/japan/msdn/vstudio/events/agileseminar.aspx

844 ：デフォルトの名無しさん：2009/03/20(金) 00:48:14

C言語は2038年に自然消滅します

845 ：デフォルトの名無しさん：2009/03/20(金) 09:22:48

>>844
もうとっくに対策済んどるわ
いつの時代の話してんだボケｗ

846 ：デフォルトの名無しさん：2009/03/20(金) 19:00:01

>>845
そーでもないぞ。
(実際Linuxとか窓とかダメだろ)

847 ：デフォルトの名無しさん：2009/03/20(金) 19:04:07

64bit化すれば自然に解決なんじゃね?

848 ：デフォルトの名無しさん：2009/03/20(金) 19:41:49

C言語があるせいでPCの進化が妨げられてるよな

849 ：デフォルトの名無しさん：2009/03/20(金) 20:55:11

>>846
とっくに済んでんじゃね？

850 ：デフォルトの名無しさん：2009/03/20(金) 21:06:11

プラットフォームAPIが64bitで返せば、後はコンパイラのtime_tの扱いを変えるだけだからな。
問題はCよりVB6.0な気がする。去年も一本書いたし、何故か現役なんだよな。

851 ：デフォルトの名無しさん：2009/03/21(土) 09:25:42

大丈夫。VBは言語じゃない。

852 ：デフォルトの名無しさん：2009/03/21(土) 16:11:41

>>850
そんなもん現役で使うことが問題なんであって。

853 ：デフォルトの名無しさん：2009/03/21(土) 16:35:19

VBもうやだ・・・

854 ：デフォルトの名無しさん：2009/03/22(日) 19:54:09

VBｲﾗﾈ

855 ：デフォルトの名無しさん：2009/03/22(日) 23:22:07

>>1
現実的な案としては、世界を核の炎で包め