トップページ⇒tech
985コメント258KB

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

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん2008/05/07(水) 20:11:42
どうすればいい？
0002デフォルトの名無しさん2008/05/07(水) 20:13:02
クソすれ立てる人間を完全に駆逐するためには

どうすればいい？
0003デフォルトの名無しさん2008/05/07(水) 20:17:12
駆逐する意図が分からん
0004デフォルトの名無しさん2008/05/07(水) 20:30:05
C言語は生産性低い。
コーディングしててイライラする。
もうC言語はうんざりだ。
しかしパフォーマンスやらなんやらの点からC言語を選ばざるを得ないこともある。

C言語より全ての面で優れた言語があればもうCをやらなくていいよね？
「〜だからC言語で開発しよう。」という理由をこの世からひとつ残らず消したい。
0005デフォルトの名無しさん2008/05/07(水) 20:42:07
そんなキミにD
0006デフォルトの名無しさん2008/05/07(水) 20:43:26
>>4
で、なぜはほんとう？
0007デフォルトの名無しさん2008/05/07(水) 21:11:28
言語厨召喚スレ
0008デフォルトの名無しさん2008/05/07(水) 21:37:00
Cのパフォーマンス、スクリプト言語並のゆるい型付け、
Smalltalkから受け継いだオブジェクト指向、
そう、つまりObjective-Cの出番だな。

自分で言っときながら、これはねーよｗ
0009デフォルトの名無しさん2008/05/07(水) 21:41:29
MISRAやら、あの系統のコーディング規約とかを目にすることがあるけど、
あそこまでガチガチにするなら、素直にPascalつかっとけよって感じだけど。
0010デフォルトの名無しさん2008/05/07(水) 21:50:45
C++はCを（完全には）駆逐することは出来なかった。
なぜ？
0011デフォルトの名無しさん2008/05/07(水) 22:09:35
慣れてるから。実績があるから。
切替えによる不具合がないといいきれないから。
教育コストがかかるから。機能的に必要ないから。
0012デフォルトの名無しさん2008/05/07(水) 22:14:30
そりゃ、ハードウェアをある程度仮想化できて、汎用性と生産性が高い
アセンブラが登場してくれば……たぶんCとほとんど同じようなものに
なるだけだな、きっと。

0013デフォルトの名無しさん2008/05/07(水) 22:20:38
>>10
MFCとシステムハンガリアンのせいだったりして
0014デフォルトの名無しさん2008/05/07(水) 22:31:59
みんなに聞きたいんだが、みんなの意見はどれに近い？

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

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


0015デフォルトの名無しさん2008/05/07(水) 22:52:37
>>14
２
古臭さを感じるけど、メジャーな代替言語が無いからなぁ
あんまり言うと言語厨が沸くから、この辺で
0016デフォルトの名無しさん2008/05/07(水) 23:02:04
>>14
2
環境制限なしでC++ or CならC++を取りたいな。
たぶん組み込みやってるから若干3よりではある。
0017デフォルトの名無しさん2008/05/08(木) 00:22:35
>>10
STLでprintfのような書き方できないから
0018デフォルトの名無しさん2008/05/08(木) 00:29:53
>>10
C++はC++で問題が多いからな
むしろC++は駆逐される側にまわってしまった感がある
0019デフォルトの名無しさん2008/05/08(木) 06:29:39
>>14
1
「ランタイムサポート(GCとか)を必要としない」「メモリに直接アクセスできる」
「アセンブリコードを埋め込める」「動的メモリ確保に依存しない」という特徴のある、
もうすこしマシな言語が欲しい
0020デフォルトの名無しさん2008/05/08(木) 11:19:14
まあ同意なんだけど、それってどれも欠点の裏返しとして槍玉に上がる利点なんだよな
なんか止揚っつーか、パラダイムシフトが欲しい所なのかもね
0021デフォルトの名無しさん2008/05/08(木) 11:51:05
他にCの代替になる優良な言語があるならともかく、
無い現状で駆逐しようとか気勢上げてもしょうがないだろう。
順番が逆。
0022デフォルトの名無しさん2008/05/08(木) 13:49:11
>>21
Javaとか言い出す奴が出そうだなｗ
0023デフォルトの名無しさん2008/05/08(木) 14:00:28
Cと全く同じことがCが動く全プラットフォームでできて
なおかつ機能が少なくとも同等でパフォーマンスが少なくとも同等な言語があれば
Cは一気に駆逐されると思うぜ

Cは使われるべくして使われている言語だ
Cの代替がない限り、Cは死なないし死ねない
0024デフォルトの名無しさん2008/05/08(木) 14:59:03
それってただのまがいもの

皮肉的につっぱしるなら「少なくともCと同等以上の歴史と運用実績を持ち」も追加してほしす
0025デフォルトの名無しさん2008/05/08(木) 18:33:49
C+CoreFoundation
C+GObject

みたいなので我慢出来ない?
0026デフォルトの名無しさん2008/05/08(木) 18:48:41
>>21
だからCの代替になる言語を作ろう(あるいは見つけてこよう)という話じゃないの？
0027デフォルトの名無しさん2008/05/08(木) 20:03:31
>>8
Apple信者の俺でもそれはねーよｗ
0028デフォルトの名無しさん2008/05/08(木) 20:41:35
ハードウェアが根本から変わったらCは駆逐される。
ハードウェアがノイマン型のうちはCは無くならんよ。
0029デフォルトの名無しさん2008/05/08(木) 21:51:45
Cには標準で動的にサイズが変わるコレクションが無いっていうのがいや。
0030デフォルトの名無しさん2008/05/08(木) 22:05:50
でも、それで充分な内容もたくさんあるってことだね。
0031デフォルトの名無しさん2008/05/08(木) 22:45:42
>>26
結局Cみたいなもんしかできあがらんだろうなってのが
大方の意見だと思われ。
0032デフォルトの名無しさん2008/05/09(金) 01:53:40
OSでUNIX(POSIX)的なものを完全に駆逐できれば可能かもね
0033デフォルトの名無しさん2008/05/09(金) 02:30:25
Inferno を思い出した
0034デフォルトの名無しさん2008/05/09(金) 03:21:42
>>29
裏で勝手にメモリ取らないというのがCのポリシーだろ。
その意味でstrdupは異端。
0035デフォルトの名無しさん2008/05/09(金) 03:52:58
>>34
>Cのポリシー

初めて知った。どこかに明文化されてる物なの？
0036デフォルトの名無しさん2008/05/09(金) 09:17:04
俺解釈だろ
0037デフォルトの名無しさん2008/05/09(金) 12:37:27
>>32
Unixと共に産まれUnixと共に滅ぶのならCも本望だろう。
どっちも死にそうに無いけど。
0038デフォルトの名無しさん2008/05/09(金) 17:20:01
ハード寄りな言語がCしか無いのってのが現状。
カーネルやデバイスドライバとかいじろうとするとCしか選択肢がないんだよ。
0039デフォルトの名無しさん2008/05/09(金) 17:31:17
tomoyo Linux最高
0040デフォルトの名無しさん2008/05/09(金) 19:19:10
Cの文法上の不満点は？
0041デフォルトの名無しさん2008/05/09(金) 19:47:02
そういうレベルじゃないだろ
0042デフォルトの名無しさん2008/05/09(金) 19:56:30
>>40
宣言の文法は、異常。
もっとスッキリできなかったのか？
0043デフォルトの名無しさん2008/05/09(金) 20:22:02
Cはタイプ量が多くなる。
他の先進的な言語と比べて１０倍くらいタイプが必要だろ。

0044デフォルトの名無しさん2008/05/09(金) 20:26:39
それはGUIみたいな無駄かつ無意味な処理を書くから。
0045デフォルトの名無しさん2008/05/09(金) 20:29:29
C++はC+程度に留めておけばCに止めを刺せたかもしれないのにな。
ちょっと欲張りすぎたね。
0046デフォルトの名無しさん2008/05/09(金) 20:39:26
Cの宣言の文法は一貫性があって良いと思うんだけど、なかなか賛同が得られない
0047デフォルトの名無しさん2008/05/09(金) 20:55:38
文法にすら不満が無いのならなんで駆逐させたいんだ
0048デフォルトの名無しさん2008/05/09(金) 21:52:40
クラスが無いのが不満。
CでOOぽくコーディングするとキモくなる。

0049デフォルトの名無しさん2008/05/09(金) 21:59:45
>>48
いやそれCの不満点として挙げる必要ないだろｗ
ま、C++使っちゃいけない場合が多すぎるのもあるけど
0050デフォルトの名無しさん2008/05/09(金) 22:01:40
関数プログラミングができないのが不満
0051デフォルトの名無しさん2008/05/09(金) 22:17:26
今時、クロージャもジェネレータもリストの内包表記もパターンマッチも型推論も
総称関数もイテレータもクラスもインターフェイスも継承も遅延評価も参照透明性も
名前空間もモジュールシステムも高階関数もガベージコレクションも例外機構も、
その他色んな物が入っていないのが不満。

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

Cが良いのは慎み深い所。21世紀になってもオブジェクト指向の追加すらされてない
だなんて何と禁欲的で信頼に値する事か。あと92年くらいは使われ続けるんじゃない
だろうか。
0052デフォルトの名無しさん2008/05/09(金) 22:23:45
GCは要らない。GCなんか入れたらC言語の利点が失なわれてしまう
代数的データ型とか、制限付きの無名関数とか、強力なマクロとか、パターンマッチとか、
そういうこまごましたものが欲しい
0053デフォルトの名無しさん2008/05/09(金) 22:28:22
オブジェクトシステムを入れるなら単一継承にして欲しいし、そうなるだろうな
0054デフォルトの名無しさん2008/05/09(金) 22:30:48
Cのリプレースを目指すわけじゃなく単純に哲学を受け継いだ正常進化系の言語ってありそうなもんだけど
結局メジャーになるようなものは出てきてないな。
0055デフォルトの名無しさん2008/05/09(金) 22:31:03
そんな難しい機能入れたって、C厨に使えるわけないだろ。
0056デフォルトの名無しさん2008/05/09(金) 22:38:40
1980〜1990年頃まではfortranとcobolは駆逐されない。とみんなが考えていた。
まあ「駆逐」という言葉の定義に依存する話だ。
この頃から現在に至るまでのコンピューティングの変化を書ききることは出来ないけれど。
まあ「同程度の変化が起これば主流言語の交代が起こるのではないか」と愚考する。
あるいは現在と同様の状態が長い間、続くのかもね。
0057デフォルトの名無しさん2008/05/09(金) 22:39:29
今の時代にCだけしか使っていない人間が生き残っているとも考えづらいし、
高級言語はそれなりに触っている事だろう。
0058デフォルトの名無しさん2008/05/09(金) 22:42:31
>>57
入社してCの部署に配属されて、Cしか触ったことないってやつとかいっぱいいそうだけど。
0059デフォルトの名無しさん2008/05/09(金) 22:47:50
ハード寄りの組み込みの人たちとかUNIX系OSのカーネル開発者系の人達とかはたとえ
先進的言語について精通していたとしても自分の仕事ではCを使う、みたいな感じで
生き残り続けるんじゃない？
0060デフォルトの名無しさん2008/05/09(金) 22:52:19
>>58
うちの会社では見た事無いな。Javaの研修がほぼ必須になってるし。
組み込み機器メーカーのソフト開発部門とかだとC専業部隊があるのかな。
0061デフォルトの名無しさん2008/05/09(金) 23:06:24
>>56
コボルはまだまだ残る
なぜか残る
0062デフォルトの名無しさん2008/05/09(金) 23:46:18
>>48
そこでObjective-Cですよ！
…ごめん俺もなんか無理>>8

しかし何でObjective-Cは微妙に思えるのかねぇ。
0063デフォルトの名無しさん2008/05/09(金) 23:58:47
C言語と一緒にCシェルも駆逐してくれ。
0064デフォルトの名無しさん2008/05/10(土) 00:02:17
むしろBシェルがイヤっす
あーいう曖昧なのを許容するなんて出来ない
あれがデフォなせいでLinuxやら使いたくない
0065デフォルトの名無しさん2008/05/10(土) 00:19:13
何か曖昧だったっけ？
0066デフォルトの名無しさん2008/05/10(土) 00:24:05
>>54
結局のところノイマン型コンピュータ言語の根本的な変革って二つしか無い。
一つは構造化で一つはオブジェクト指向。
Cが進化するとしたらオブジェクト指向を取り入れるくらいなもので、実際
そのように進化してると思うが。
0067デフォルトの名無しさん2008/05/10(土) 01:46:46
わざわざノイマン型コンピュータと明言する必要でもあるのか？
0068デフォルトの名無しさん2008/05/10(土) 06:08:06
まぁ、出世してエラくなれば、言語使ってPGなんてしなくなるから、
どうでもよくなるよ。
0069デフォルトの名無しさん2008/05/10(土) 06:55:54
仮面ライダーBLACKが一度死んでRXとして復活したように
Javaも一度死ぬべきだ
そして真の神仕様の言語として復活すべし
0070デフォルトの名無しさん2008/05/10(土) 07:10:58
逆だな、Javaはもっとカオスになってくれないと
リファクタリングしたときの効果が薄くていかん。
D言語みたいに中途半端になってしまう。
0071デフォルトの名無しさん2008/05/10(土) 08:08:13
>>1
先ずは、KernelとコンパイラをC以外で書いてみれば？
0072デフォルトの名無しさん2008/05/10(土) 08:31:08
javaとC#とあとはオブジェクト指向スクリプト言語しか使ったこと無い俺に
C++がCより劣ってる点を教えてくれ。
0073デフォルトの名無しさん2008/05/10(土) 08:56:37
カーネルはともかく、コンパイラをCでかく必要って本当にあるのか？
入力はただの文字列だし、出力だってただの文字列だろ。
直接ハードを叩くわけでも無し。
ていうかコンパイラこそ、リッチな機能をもった高級言語で書くべきなんじゃ。
でも世の中のコンパイラは大抵Cで書かれてるんだっけ？
0074デフォルトの名無しさん2008/05/10(土) 09:03:16
>>73
しょうもない質問で申し訳ない。

コンパイラの出力って文字列なの？バイナリも文字列の一種？
0075デフォルトの名無しさん2008/05/10(土) 09:04:31
>>72
斜め上の機能を使いにくい
GCはまあ使えるがcall/ccとか無理ぽ
0076デフォルトの名無しさん2008/05/10(土) 09:06:03
>>72
すぐにコンパイル・リンクにめちゃくちゃ時間がかかるようになること。
0077デフォルトの名無しさん2008/05/10(土) 09:06:31
>>74
しっ！そこ突っ込んじゃ可哀想！
0078デフォルトの名無しさん2008/05/10(土) 09:12:02
俺の理解ではコンパイラはアセンブラを吐いて
アセンブラがバイナリを吐くということになっている。
アセンブラまで含めてのコンパイラというなら
コンパイラの出力はバイナリ。
0079デフォルトの名無しさん2008/05/10(土) 09:15:44
>>66
オブジェクト指向っていうのは、構造化の延長線上じゃないの?
0080デフォルトの名無しさん2008/05/10(土) 09:19:17
>>73
そこらへんの高級言語よりは速いコードを生み出すと信じられているから。
0081デフォルトの名無しさん2008/05/10(土) 09:29:21
http://shootout.alioth.debian.org/debian/

Cは全てにおいて最速ではないが、かなりの範囲で最速になるな。
機械語に近くて、コンパイラ屋にも人気のある言語なだけに。
0082デフォルトの名無しさん2008/05/10(土) 10:33:28
>>79
C++とかJavaとかCの延長線上の言語でオブジェクト指向を見ると
そう見えるかもしれんね
0083デフォルトの名無しさん2008/05/10(土) 11:24:39
>>72
バイナリがやたらでかくなる
ネームマングリングの所為でシンボルダンプやスタックトレースが読み辛い
0084デフォルトの名無しさん2008/05/10(土) 12:26:13
>>72
技量の低い私にはコンパイラの出力がどーなっているか C は分かっても C++ はわからない。
私のような技量の低いプログラマーを駆逐する方が本来の目的に近づけるのかも。
0085デフォルトの名無しさん2008/05/10(土) 12:31:12
>>78
では、「んなもん実装次第」だということを理解しましょう。
0086デフォルトの名無しさん2008/05/10(土) 17:08:29
(1)多くのOSがC言語の関数群として表現されている
(2)他言語のコンパイラも多くはC言語で書かれている。
(3)(1,2)を他言語に換装する作業が面倒＆標準言語が未定。

個人的にはObjective-Cに興味があります。
(コイツは言語の名称で損していないだろうか？)
0087デフォルトの名無しさん2008/05/10(土) 17:22:33
Objective-CってMac専用だろ
その時点でCにとって代わるのは無理
0088デフォルトの名無しさん2008/05/10(土) 18:46:40
>>73
そりゃ自分の言語がいろんなプラットフォームで動くようにしたいからでしょ。
だから言語は C でかくか、JavaVM で動かすかのどっちか。
変態系は lisp で書いたりするけど。
0089デフォルトの名無しさん2008/05/10(土) 19:10:35
>>87
専用って訳じゃないと思う、、(^^;
ttp://wwwa.dcns.ne.jp/~nito/objective-c/answer-17.html

無理なのには同意。objcいいとは思うんだけどね、、
0090デフォルトの名無しさん2008/05/10(土) 22:28:04
そんなん過渡期にこういうのありましたよ、って紹介でしか知りません
0091デフォルトの名無しさん2008/05/10(土) 23:40:28
>>86
> (1)多くのOSがC言語の関数群として表現されている 

これは別にどうでもいい要素じゃん。
PascalとかVBからでもAPI呼び出したりできてるし。
0092デフォルトの名無しさん2008/05/10(土) 23:50:51
Objective-CってMac専用ってイメージなのか。
俺はずっとNext専用ってイメージしかなかったから、ちょっとびっくり。
0093デフォルトの名無しさん2008/05/11(日) 05:42:43
Objective-Cは取り敢えず[]で括るのがキモイ
0094デフォルトの名無しさん2008/05/11(日) 11:19:20
C++でガベージコレクション使わんのがある程度Cの代用に
なるんじゃないのか
0095デフォルトの名無しさん2008/05/11(日) 11:49:29
最近はC++の記法の方がキモく感じられるようになった。
Objective-Cはかなり良いのだけど、これ以上広がることはないだろうな、まったく残念ながら。
0096デフォルトの名無しさん2008/05/11(日) 12:05:21
ちょっと興味はあるんだが検索してもサンプルコードらしきコードが全然出てこないな
0097デフォルトの名無しさん2008/05/11(日) 12:16:54
オブジェクト指向言語の比較
http://hmdt.jp/oop/index.html

ちょっと興味深かった。
0098デフォルトの名無しさん2008/05/11(日) 12:53:49
>>86
2 は重要かな?
Lisp のコンパイラは大抵 Lisp 自身で書かれているし、
確認していないけど javac は C++ で書かれてるよね?
その他、JavaScript のコンパイラは Java, OCaml, SML,
JavaScript, C++, etc. で書かれた実装があったと思う。
0099デフォルトの名無しさん2008/05/11(日) 14:26:14
最初のC++コンパイラはCで書くしかないからな
そのコードを捨ててC++で書き直す意味が分からん
0100デフォルトの名無しさん2008/05/11(日) 14:35:38
>>99
>最初のC++コンパイラはCで書くしかないからな

cfront は C++ で書かれていたらしいが?
0101デフォルトの名無しさん2008/05/11(日) 14:53:21
それどうやってコンパイルしたんだろ
手か
俺は絶対に嫌だが
0102デフォルトの名無しさん2008/05/11(日) 14:55:07
つ　bootstrap
0103デフォルトの名無しさん2008/05/11(日) 15:00:24
我々はもう既にオブジェクト指向から拡張した新たなるパラダイムに接している。

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

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

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

皆さん、新たなるパラダイムにようこそ。
0104デフォルトの名無しさん2008/05/11(日) 15:09:09
ここだけ 1990 年代のスレですか?
0105デフォルトの名無しさん2008/05/11(日) 15:36:58
JavaChip上でJavaOSが動けばCも捨てられるんだろうけどね

でも結局、最後はマシン語の世界に降りていかないといけないだろうし
そうなったら最後は高級アセンブラであるところのCに頼らざるをえない。
0106デフォルトの名無しさん2008/05/11(日) 15:38:52
だからもっとまともな高級アセンブラが欲しいって話じゃないのか
0107デフォルトの名無しさん2008/05/11(日) 15:51:51
D言語があるじゃまいか！
0108デフォルトの名無しさん2008/05/11(日) 16:08:58
皆に黙殺されるD言語
0109デフォルトの名無しさん2008/05/11(日) 18:50:50
真のオブジェクト指向言語はLOGO
0110デフォルトの名無しさん2008/05/11(日) 21:40:39
Objective-D++が有れば最強……かも。
0111デフォルトの名無しさん2008/05/11(日) 23:01:18
>99
最初のC++の実装は、確かCへのトランスレータじゃなかったっけかな。
国内でもPC向けのC++実装はトランスレータの時代があった。MIWA C++とかさ。
0112デフォルトの名無しさん2008/05/11(日) 23:15:47
C++は生れた時から今までずっと、C with class だろ？
CとC++で、OOなコードを書こうとする時、コード量が増える以外の
違いってあるのかな？
0113デフォルトの名無しさん2008/05/12(月) 00:11:27
>>99-101
「最初のC++コンパイラはC with Classesで書かれた」が答えというオチ？

0114デフォルトの名無しさん2008/05/12(月) 12:10:39
Zortech C++ のバージョン1使ってたぞ。Cへのトランスレータだった
ちなみに作者はWalter Bright
Dの作者でもある
0115デフォルトの名無しさん2008/05/12(月) 13:35:53
Zortech C++は最初からトランスレータじゃなくてnative compilerだったと
思うけど。PC向けに国内で初めて手に入ったnative compilerってことで俺も
買って、そして余りのバギーさに枕を濡らした記憶がある。

0116デフォルトの名無しさん2008/05/12(月) 22:34:49
仮想関数があるとパフォーマンス落ちるから継承がある言語はCの代わりにはなれないな。
0117デフォルトの名無しさん2008/05/12(月) 22:45:17
パフォーマンス(笑)
0118デフォルトの名無しさん2008/05/12(月) 22:47:50
あんたの笑いのツボはよく分からんな
0119デフォルトの名無しさん2008/05/12(月) 22:50:04
エンドユーズに限りなく近いデベロッパならC++/C#/Javaで十分ですよ。
Java7はビデオデコード機能がFlashやSilverlightに追いつくらしくて期待してる。
後はゲーム系インタフェースさえ標準化されればJavaだけでいいのに。
0120デフォルトの名無しさん2008/05/12(月) 22:54:48
Java(笑)
0121デフォルトの名無しさん2008/05/12(月) 23:16:42
継承無しのクラスに価値はあるのか？
0122デフォルトの名無しさん2008/05/12(月) 23:18:04
継承はクズ。これからは委譲。
0123デフォルトの名無しさん2008/05/12(月) 23:19:55
オブジェクト指向を根本から否定かよ。

0124デフォルトの名無しさん2008/05/12(月) 23:35:13
>>120
C言語（笑）

お前のやってる手法は根拠レスでチープな行為だ。
0125デフォルトの名無しさん2008/05/12(月) 23:35:35
なぜ継承がクズかkwsk
0126デフォルトの名無しさん2008/05/12(月) 23:40:23
>>123
delegationも立派なオブジェクト指向の手法。継承だけがOOPLじゃないのよ。
>>125
オブジェクトの関係を固定してしまうから変化に弱い。
0127デフォルトの名無しさん2008/05/12(月) 23:42:18
>>126
初心者の俺でも分かるようにもっとｋｗｓｋ
0128デフォルトの名無しさん2008/05/12(月) 23:52:28
仮想関数は実行時に差し替えることができない。だから継承しまくる
デリゲートはそれができる。だから継承いらない
0129デフォルトの名無しさん2008/05/13(火) 00:19:14
処理の委譲とインタフェースの実装はまるで別な機能だろ。
ストリーム関係が継承を必要とする最もたる例だと思うが。
0130デフォルトの名無しさん2008/05/13(火) 00:22:48
CとC++/C#/Javaなんて唯の兄弟喧嘩だろ
しかも偉大な兄(C)を越えられない
Cを駆逐するなら、全く別のアプローチしか無い
0131デフォルトの名無しさん2008/05/13(火) 00:26:02
超えようと機能を追加していったのがC++で、別のアプローチのつもりが
気がついたらナナメ上だったのがJAVAだと。
0132デフォルトの名無しさん2008/05/13(火) 00:28:09
C言語なんてハードウェアよりじゃないかぎり使う方が馬鹿だと思うが。
0133デフォルトの名無しさん2008/05/13(火) 00:30:32
つまり Apache はハードウェアよりと…
0134デフォルトの名無しさん2008/05/13(火) 00:33:34
ハードウェア寄りじゃ無い場面で、Cの幻影を引き摺ってる言語を使ってる
時点でダメだよな。
0135デフォルトの名無しさん2008/05/13(火) 00:35:09
世間はそう思ってないみたいだが、どうなのよ？
0136デフォルトの名無しさん2008/05/13(火) 00:37:24
ちなみに Perl も Python も Ruby も SpiderMonkey も Tcl/Tk も C だよね
0137デフォルトの名無しさん2008/05/13(火) 00:40:26
フリーの言語処理系だけ並べられても
0138デフォルトの名無しさん2008/05/13(火) 00:40:42
>>134
Java が出なければ SML が主役になる筈だったと言ってる人が居たけど…
0139デフォルトの名無しさん2008/05/13(火) 00:43:22
>>137
ハードウェアよりじゃない所で、実装言語を確認出来る良い例だから。
0140デフォルトの名無しさん2008/05/13(火) 00:46:04
STLが無いってだけでC言語は糞だろ。
生産性の無い言語は現場から去るべき。
0141デフォルトの名無しさん2008/05/13(火) 00:47:31
マルチプラットフォームでパフォーマンスが求められるとどうしてもCになるねえ

しかし、それこそC言語のほうこそ、「FORTRANとCOBOLを完全に駆逐するためには」
とか日頃思ってるんじゃないかな。コンピュータの世界ではCはそんなに独占してる
わけじゃないから
0142デフォルトの名無しさん2008/05/13(火) 00:47:33
C++が糞じゃなかったらとっくに現場から去ってるって
0143デフォルトの名無しさん2008/05/13(火) 00:48:26
PerlとTclはちょっと違うな。
Cも含めた闇鍋風バカ言語。もちろん良い意味で。
0144デフォルトの名無しさん2008/05/13(火) 00:58:21
STLが無いと生産性の上らない>>140は現場から・・・
0145デフォルトの名無しさん2008/05/13(火) 01:00:52
>>144の苦しい言い訳とか、Cが如何に使えないかよくわかる。
0146デフォルトの名無しさん2008/05/13(火) 01:01:11
STLなめんな。
0147デフォルトの名無しさん2008/05/13(火) 01:03:09
未だにテンプレート禁止のところもあるというのに
0148デフォルトの名無しさん2008/05/13(火) 01:03:22
ちょ、子供の喧嘩は勘弁な
0149デフォルトの名無しさん2008/05/13(火) 01:13:09
>>141
今やCの守備範囲とFortran,COBOLが生き残ってるところは、ほとんど被ってないからなぁ
Fortanを駆逐するのは(可能がどうか別にして)Camlでいいと思うが、COBOLは何だろう？
0150デフォルトの名無しさん2008/05/13(火) 01:13:27
つーかこの急激なスレの伸びはなんなのよｗ
0151デフォルトの名無しさん2008/05/13(火) 01:18:03
コレクションもなく文字列操作も冗長で正規表現も標準で無いとかふざけすぎ。
エラートラップをするにしてもエラーコードびっしりで冗長極まりない。
例外を使わせろよ。C++みたいにfinallyの無いなんちゃって仕様じゃない奴。
0152デフォルトの名無しさん2008/05/13(火) 01:29:53
そこで組み込みスクリプト言語ですよ
0153デフォルトの名無しさん2008/05/13(火) 02:02:19
>>151
finallyも使いやすいとは思えないけどな。
C#のusingとかDのscopeとかみたいな仕組みくらいのほうがいい。
C++デストラクタもまああり。
0154デフォルトの名無しさん2008/05/13(火) 05:06:38
C++はネイチブ生成の宿命があるのに
その場合エラー専用処理がものすごく非効率って問題が
0155デフォルトの名無しさん2008/05/14(水) 09:01:09
>>153
んなもんケースによるだろ。
ケースによるのにfinallyがないのが糞なんだよ。
0156デフォルトの名無しさん2008/05/14(水) 09:42:43
finally相当の機能なら、C++/CLIでついたんじゃなかったっけ?
0157デフォルトの名無しさん2008/05/14(水) 10:34:32
まるでC++/CLIがC++の後継みたいな言い方だな
0158デフォルトの名無しさん2008/05/14(水) 13:30:06
C++/CLIはC++じゃない
0159デフォルトの名無しさん2008/05/14(水) 15:37:48
>>150
それだけみんなCに不満もってるってことだ。
総力を挙げて潰さないとこの業界に未来はないよ。
0160デフォルトの名無しさん2008/05/14(水) 16:04:13
形式仕様から、最終的にバイナリコード(FPGAベースのチップ向けの)を
生成する研究が実用化されれば、Cだけでなく、現状のほとんどの言語を使わなくなる。

プログラミングは、「問題領域向けのDSLを記述+DSLで動作記述」になるよ。
0161デフォルトの名無しさん2008/05/14(水) 20:24:35
問題領域向けのDSLを記述+DSLで動作記述
↑
これのコンパイラは結局Cでかかれると。
0162デフォルトの名無しさん2008/05/14(水) 20:27:14
最近は言語処理系は関数型言語か C++ で書くのが流行の様だよ
C++ がもう少しまともだったらな
0163デフォルトの名無しさん2008/05/14(水) 20:29:28
コンパイラはリッチな環境の上で動かせるから選択肢の数が全然違う
0164デフォルトの名無しさん2008/05/14(水) 20:57:24
C言語で開発しとけばなんかあったとき安心、見たいのがあるのかね？
性能をどうしてもあと１０％上げなきゃいけない、なんてときもCなら何とかなるとか。
0165デフォルトの名無しさん2008/05/14(水) 21:02:28
Cで書いた所でそれ程ハードルが高くなる訳じゃない
特に拘りがないだけじゃないの
0166デフォルトの名無しさん2008/05/14(水) 21:33:09
俺はCだとハードルかなり高くなる。
それで飛び越えられなくなるわけじゃないとしても、いちいち高めにジャンプしなきゃいけないのがむかつく。
0167デフォルトの名無しさん2008/05/14(水) 21:47:37
コンパイラをCで書くとか、嗜虐癖があるとしか思えん
0168デフォルトの名無しさん2008/05/14(水) 21:49:54
>>164
C で書いておけば色んな言語と混ぜられる。
C のルーチンを LL から呼び出すのは至極楽ちん。
0169デフォルトの名無しさん2008/05/14(水) 22:07:14
前にRubyからCのルーチン呼ぼうとしたらSWIGとかいうの使う羽目になった。
配列とか使ってたから、変換用のコーディングも若干必要になったし。
大変というほどでも無いが至極楽ちんというほど楽ちんでもないような。


0170デフォルトの名無しさん2008/05/14(水) 22:15:07
CはLLのインラインアセンブラや〜
0171デフォルトの名無しさん2008/05/14(水) 22:35:22
>>168
C#とPowerShellその他.NETなLLの親和性は異常
CというかシステムコールをOOなLLでラッピングとかもう面倒でやってらんない
0172デフォルトの名無しさん2008/05/14(水) 23:56:55
何でシステムコールが出てくる？
シスコール生で叩かせるLLなんてあるのか？
0173デフォルトの名無しさん2008/05/14(水) 23:57:26
>>171
そういえば、.NETってなんとなくスルーしてたなぁ。
趣味として使うとしたら学ぶ価値ある？
普段はRuby使ってます。
0174デフォルトの名無しさん2008/05/14(水) 23:58:22
>8
＞Cのパフォーマンス
これほんと？
0175デフォルトの名無しさん2008/05/15(木) 00:07:41
>>174
C だけ使えば C と同じ性能。
C++ でもよく使われる言い回し。
0176デフォルトの名無しさん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
0177デフォルトの名無しさん2008/05/15(木) 02:38:24
>>71
古い話で恐縮だけれども、ICOTの例のプロジェクトでは prolog の進化形で　**カーネルの大部分を** 記述していたとか。
そういう用途のシステムでは、そういう選択もあるようです。
＃同じ研究を現在のハードウェア技術で行ったらどうなるのかつくづく知りたいものですが、あと 100 年はとりあげられないでしょうか‥‥‥。
0178デフォルトの名無しさん2008/05/15(木) 02:43:57
>>88
人を変態よばわりしないでください。
R6RS準拠のコンパイラがでたんですって？
0179デフォルトの名無しさん2008/05/15(木) 08:35:10
Cに文句言うより86アセンブラをまず駆逐しろよ・・・
Intelでさえできなかったんだぞ
0180デフォルトの名無しさん2008/05/15(木) 08:37:36
今時のCPUはアセンブラ（≒機械語）を直接実行せずに
自前の命令に変換するんでしょ。
そんな内部コードを毎度毎度表にさらしてたら大混乱が起こるんじゃね。

AMDの人も命令コードなんて全然大した問題じゃないとか言ってたし。
0181デフォルトの名無しさん2008/05/15(木) 13:54:39
>173
> そういえば、.NETってなんとなくスルーしてたなぁ。
> 趣味として使うとしたら学ぶ価値ある？

プログラミングが趣味か、なんらかの成果物を完成させるのが趣味かで変わってくるんじゃ?
ﾄﾞﾄﾈﾄ系はWindowsのアプリを作るということなら、死ぬほど楽なのは確か。
特にC#とC++/CLIの楽さは異常。
01821732008/05/15(木) 18:43:57
>>181
レスさんくす。
C#でもかじってみるか。
（そういえばIronRubyはどうなったんだ？とんと話を聞かないが。）
0183デフォルトの名無しさん2008/05/16(金) 18:44:40
開発言語をアセンブラからCに変えて解放されることって

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

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


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

0186デフォルトの名無しさん2008/05/16(金) 19:30:17
namespaceとstructに関数ぶら下げるのとoverloadがあると気分的にだいぶ楽になるな。
IDEとの親和性も爆上がるし。
0187デフォルトの名無しさん2008/05/16(金) 19:42:34
>>185
ただ、cppにはもうちょっと賢くなってほしいけどなあ。

あ、でもあんまり賢すぎるとlispみたいになんでもマクロで書いちゃう
人が出てくるからダメかな。
0188デフォルトの名無しさん2008/05/17(土) 00:00:28
>>183
Cはメモリーもスタックも管理しないだろ
0189デフォルトの名無しさん2008/05/17(土) 00:07:03
自動変数の事じゃないの
01901832008/05/17(土) 00:20:31
スタックの管理は自動変数、
メモリーの管理はmalloc&free,大域変数のつもりで書いた。
0191デフォルトの名無しさん2008/05/17(土) 11:00:14
OO言語としてC++は置いといて高級アセンブラとしてCを凌駕する
ポストC的な言語がほとんど話題にならない時点で結論が出ているわけだが。
0192デフォルトの名無しさん2008/05/17(土) 12:10:51
c++を駆逐してほしいんだが
0193デフォルトの名無しさん2008/05/17(土) 12:38:39
学習コスト＜＜駆逐コスト
0194デフォルトの名無しさん2008/05/17(土) 13:08:01
>>191
高級アセンブラが使われる環境を駆逐したいんじゃない？
0195デフォルトの名無しさん2008/05/17(土) 13:17:15
入れ子が{}じゃなくて
ポインタが*じゃないC言語ください
0196デフォルトの名無しさん2008/05/17(土) 13:35:32
なぜ組み込みの世界であんなに C++ が嫌われるのか理解できない。
些細なデメリット避けるために大きなメリットを失っている。
0197デフォルトの名無しさん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++は何でも屋であるが故に駆逐されつつある。
0198デフォルトの名無しさん2008/05/17(土) 13:53:49
>>192
今田舎に別荘を建てて隠遁する準備が進んでいるよ
200x 年には完成する見込みらしい
0199デフォルトの名無しさん2008/05/17(土) 14:01:51
>>196
C++ は遅い・複雑・でかいの3重苦だから組み込みには向いていない
特にリンクやロードが遅いのは致命的

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

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

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

だからこんなことを平気で言えてしまうわけだな
0202デフォルトの名無しさん2008/05/17(土) 15:39:45
そういうのはいいから説明してくれよ
0203デフォルトの名無しさん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 の方が速いですね。
0204デフォルトの名無しさん2008/05/17(土) 19:13:25
dhrystone で測れるのはループの中の計算時間だけだからね
0205デフォルトの名無しさん2008/05/17(土) 19:27:25
ループの中で結構関数呼び出しもしてるよ。
0206デフォルトの名無しさん2008/05/17(土) 19:28:51
リンクやロードも?
0207デフォルトの名無しさん2008/05/17(土) 20:04:19
>>200
C+αなんかではなく、ポテンシャル全開でC++を使うときの
コンパイル・リンクの遅さの原因の半分は言語仕様だと思う。
残りの半分は実装の問題。
0208デフォルトの名無しさん2008/05/17(土) 21:51:56
＋αでない残りのポテンシャルの部分って具体的に何よ？
例外とか？
0209デフォルトの名無しさん2008/05/17(土) 21:54:58
テンプレートじゃね？
0210デフォルトの名無しさん2008/05/17(土) 23:04:00
>>206
リンクは C が 0.10257s で C++ が 0.10281s です。
ロードは Windows の場合だと実行と切り離せないのでうまい計測方法が分かりません。

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

VCの場合はテンプレートでオブジェクトファイルも大きくなるようです。
ただしリンク後は実行ファイルはそれほど大きくなりません。
0211デフォルトの名無しさん2008/05/18(日) 01:34:45
>>195
入れ子が begin end,
ポインタが ^ でもいい？
0212デフォルトの名無しさん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

あまり例題としては適当じゃないけど、こんなもんかね。
0213デフォルトの名無しさん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
こんなお遊びのマイクロベンチの結果を真に受けちゃ嫌よ。
0214デフォルトの名無しさん2008/05/18(日) 11:03:42
VC は優秀だな。
0215デフォルトの名無しさん2008/05/18(日) 12:21:33
いろんな分野でC++はPythonに置き換わりつつあるな
Rubyなんてのを与えられた日本人は世界から置いてけぼり
0216デフォルトの名無しさん2008/05/18(日) 12:30:09
何のスレだここは
0217デフォルトの名無しさん2008/05/18(日) 13:43:40
cソースはcppソースに変換後にコンパイルされるんだが。
0218デフォルトの名無しさん2008/05/18(日) 14:59:17
cpp ってCプリプロセッサのこと?
確かに gcc はそういう手順になっていると思います。
0219デフォルトの名無しさん2008/05/18(日) 16:06:49
>>214
C コンパイラが C++ 並みに遅いのは優秀とは言えないと思うけど…
アセンブラ出力かシンボルダンプが見てみたいね

>>218
.cpp の事でしょう
何となく何でこうなってるのかは予想がつくけど…
0220デフォルトの名無しさん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++ 並みに遅くなりました。
0221デフォルトの名無しさん2008/05/18(日) 19:32:20
>>220
ちゃんと C++ としてコンパイルしてる?
共有ライブラリのリンク情報かシンボルダンプかアセンブラ出力か、
何でも良いけど晒してみて。最適化オプション無しだとどうなる?
0222デフォルトの名無しさん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
0223デフォルトの名無しさん2008/05/19(月) 00:33:34
tccを使えば解決、と言ってみる。
ttp://alohakun.blog7.fc2.com/blog-entry-667.html


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

まあ Better C って考え方は他にも落とし穴があるから、俺は
好きじゃないな。
0225デフォルトの名無しさん2008/05/19(月) 14:40:12
>>224
OS というよりもほとんどの場合コンパイラとリンカで決まると思います。
(Windows の場合は実行時の最適化もやりかねないけど)

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

> Better C って考え方は他にも落とし穴があるから
技術的にはそれほど大きな問題もないと思っているのですが、興味深いので
よかったら教えていただけませんか?
0226デフォルトの名無しさん2008/05/19(月) 20:31:42
その駄目コンパイラ…
気になる…
0227デフォルトの名無しさん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

星の数が胡散臭く感じるかもしれませんが読む価値はあると思います。
0228デフォルトの名無しさん2008/05/20(火) 18:25:10
あーその本、もってるけど全然読んでないな。
ちゃんと読んでみるかな。
0229デフォルトの名無しさん2008/05/20(火) 18:59:36
>>227
C++は遅いし、コンパイラの事を知らない人間が作った言語だよ。
0230デフォルトの名無しさん2008/05/20(火) 19:08:21
AT&T に居たんだから Aho なりに相談すれば良かったのにな
0231デフォルトの名無しさん2008/05/20(火) 19:08:45
暴言ｷﾀ━━＞▽＜━━━
0232デフォルトの名無しさん2008/05/20(火) 19:15:22
いやだってやたらと信じやすい人が居たから…
C++ をマンセーするのも良いけど程々にね
0233デフォルトの名無しさん2008/05/20(火) 19:37:24
あ、いちいち最後に改行を付け加えてる人の事な。
ストラウストラップが GLS の 1/10 でも言語設計の知識があったら
あんなコンパイルが糞遅くなる事も無かっただろうさ。
0234デフォルトの名無しさん2008/05/20(火) 20:21:11
あ、いちいち最後に改行を付け加えてる人の事な。
ストラウストラップが GLS の 1/10 でも言語設計の知識があったら
あんなコンパイルが糞遅くなる事も無かっただろうさ。
0235デフォルトの名無しさん2008/05/20(火) 20:23:45
>>234
下2行は禿上がる程同意。その言い訳も>>227の本に書いてあるかな？
0236デフォルトの名無しさん2008/05/20(火) 21:42:19
GLS がストラウストラップ 1/10 でも現実を見ていれば
あんなアプリケーションの起動が糞遅くなる事も無かっただろうさ。
0237デフォルトの名無しさん2008/05/20(火) 22:08:58
C のどこが起動が遅いって?
0238デフォルトの名無しさん2008/05/20(火) 22:15:11
なんでCが出てくるんだ
0239デフォルトの名無しさん2008/05/20(火) 22:20:34
>>238
GLS 知らんのか?
0240デフォルトの名無しさん2008/05/20(火) 22:27:31
ぐぐったら、
予備校とサーバとガラステレビ台が出て来た語学センターとガールズラブサーチってのが出て来た

とりあえずガールズラブサーチ見てる
0241デフォルトの名無しさん2008/05/20(火) 22:32:21
起動は?
0242デフォルトの名無しさん2008/05/20(火) 22:50:13
>>225
>OS というよりもほとんどの場合コンパイラとリンカで決まると思います。

だから環境って書いただろ…
ナチュラルに斜め下の指摘をするのは止めてくれ
0243デフォルトの名無しさん2008/05/20(火) 23:29:12
>>239
Guy L Steel Jr.の事だと思って読んだけど違うの？
0244デフォルトの名無しさん2008/05/20(火) 23:36:44
なら、そんな疑問は浮かばないだろ
0245デフォルトの名無しさん2008/05/20(火) 23:39:59
Guy L Steel Jr.とC言語の関係が分からん
0246デフォルトの名無しさん2008/05/20(火) 23:40:27
ガイ・スティールと聞いてJavaを最初に思い出したとか？＞起動が糞遅く
まあ言語仕様の著者ではあるが無理感じるな
0247デフォルトの名無しさん2008/05/20(火) 23:41:17
>>245
ANSI標準化
0248デフォルトの名無しさん2008/05/20(火) 23:41:51
なぜSchemeが出ない
0249デフォルトの名無しさん2008/05/20(火) 23:42:17
つか、何で知らないなら調べようとしないかね…
0250デフォルトの名無しさん2008/05/20(火) 23:44:46
>>247
すまん、もうちょい詳しく
0251デフォルトの名無しさん2008/05/20(火) 23:47:14
ググっても出てこないのはSteelじゃなくてSteeleだからだ
0252デフォルトの名無しさん2008/05/20(火) 23:56:40
>>235
書いていないな。

そもそもあの本が書かれたのは95年頃で、
テンプレートによるコンパイル速度の低下は
まだ問題になっていなかったのではないかと思う。
俺はテンプレートさえなければ、Cと比べて気になるほどなるとは思えない。
0253デフォルトの名無しさん2008/05/21(水) 00:02:40
テンプレートこそC++の特徴であり価値の一つだと思うんだけど
02542522008/05/21(水) 00:09:26
>>253
そりゃそうだ。テンプレートなしでC++使うなんて気にはなれないし、
実際、そんな機会は全然ないから
「Cと比べて気になるほどなるとは思えない」というのは自分の想像でしかない。
すれ違いすまん。
0255デフォルトの名無しさん2008/05/21(水) 00:20:09
C++ に無理矢理似非クロージャを入れて喜んでるくせに GLS も知らないんだよな…
0256デフォルトの名無しさん2008/05/21(水) 01:45:37
そもそもGLSって略称一般的かなあ
0257デフォルトの名無しさん2008/05/21(水) 01:56:54
スティールが設計に深く関わった高性能な言語は Fortress ぐらいしかないんじゃない?
0258デフォルトの名無しさん2008/05/21(水) 02:13:36
>>235
D&E 15.10 あたりで問題は認識しいるようですよ。
最近のコンパイラはプリコンパイルヘッダーや簡易ビルドの技術が発達しているので
ずいぶん良くなったと思います。
モジュール分けしてそれぞれの依存度を少なく設計すればそれほどストレスを感じません。
0259デフォルトの名無しさん2008/05/21(水) 07:38:05
>>258
他の言語だってモジュール分けすればもっと速いよ
C++ と違って小細工しなくても常識的な速さだけど
0260デフォルトの名無しさん2008/05/21(水) 08:31:09
まあビルドの速い言語ほどその後の処理負担が大きいけどな。ユーザーが多いほどコストが増大。
0261デフォルトの名無しさん2008/05/21(水) 08:57:38
C++が遅いのは文法の問題だから一般的なまともな言語と比較しても意味無い。
0262デフォルトの名無しさん2008/05/21(水) 09:10:21
>>261 詳しく。
>>259 モジュール分割や依存度下げは小細工かよ。まあ前方宣言はそうかもしれないが。
0263デフォルトの名無しさん2008/05/21(水) 09:20:06
C/C++は糞。
Cは必要悪だがC++は必要ですらない。
0264デフォルトの名無しさん2008/05/21(水) 14:58:16
ベターCとしてのC++は悪くない

ただたまに勘違いしたやつがいらんところで、継承とかテンプレートを
使いまくる。
0265デフォルトの名無しさん2008/05/21(水) 16:41:10
プロファイルを定義して違反したらコンパイル時にエラーか警告出すような
機能を付けてくれないかな。
0266デフォルトの名無しさん2008/05/21(水) 17:59:57
ほほう、それでC++が晴れてベターCになれると。
0267デフォルトの名無しさん2008/05/21(水) 19:36:41
>>266 問題点を指摘して、もっといい方法を教えてください。
0268デフォルトの名無しさん2008/05/21(水) 20:26:33
>>262
>>>261 詳しく。

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

C++ 使いって基本的に自分で調べたり勉強したりしないよな…
まあだからこそ未だに C++ をマンセー出来るんだろうけど
0269デフォルトの名無しさん2008/05/22(木) 03:03:43
全体のビルド時間に占める構文解析の時間はそんなに大きいものかね？
第一 C++ の構文解析を複雑にしているのはほとんど C の文法を引き
ずっている部分だよ。D&E を読めば構文解析に配慮していることが分
かるよ。
0270デフォルトの名無しさん2008/05/22(木) 03:10:14
配慮はしてるけど何もしてないってことだろ。俺も自分がニートなのに配慮してる
けど特に就職活動とかしてない
0271デフォルトの名無しさん2008/05/22(木) 03:10:59
>C++ の構文解析を複雑にしているのはほとんど C の文法を
>引きずっている部分だよ
Cからすれば勝手に引き摺って勝手に泥沼に走り去った後ろ姿しか見えない訳で。

ようも色々余計な物引き摺って、そんな泥沼に邁進してるなと。
0272デフォルトの名無しさん2008/05/22(木) 14:36:52
言語屋からの賛成を得てC文法の良くないところを直そうとしたがユーザーから
猛反発食らってあきらめた。現実ばかりを見て理想を追いかけない駄目な設計者。
0273デフォルトの名無しさん2008/05/22(木) 14:54:56
デファクトスタンダードと言う言葉を送ろう。
最近の悪例　Windows　　別に利用者がダメとは思わない。
0274デフォルトの名無しさん2008/05/22(木) 18:38:08
さらに彼の欠点はコンパイラの実装者よりも言語ユーザーを重視した設計をすることだ。
EC++ の設計を見習うべきです。
0275デフォルトの名無しさん2008/05/24(土) 21:04:40
つまりCをつかってりゃよかったって話なのか？
0276デフォルトの名無しさん2008/05/26(月) 00:11:25
その通り。
ためしにCを知らない新人にいきなりC++を勉強させてみるとよい。
C++のプログラムを作らせるとCを知らないはずがCスタイルになる。
つまりCは人間の直感に合っているのだ。
0277デフォルトの名無しさん2008/05/26(月) 00:29:03
言いたいことは分かる気がする。

俺1人でプログラムを書くと、核となる処理は結局、手続き型。
ただ、OOP言語だと、その部分をうまく書くために、
いろんなクラスを書くという感じになる。
0278デフォルトの名無しさん2008/05/26(月) 07:31:34
赤ん坊を無人島に放置して勝手に育ってｾｯｸﾙのやり方もわからない状態を
人間の直感にあってるとか言われてもねぇ
0279デフォルトの名無しさん2008/05/26(月) 10:32:00
>>276
「数学を学ばないと未知数を x と書かずに○と書く」みたいな話だな。
「抽象的なものは勉強すべき」ということは欠点でもなんでもないんじゃないの？
0280デフォルトの名無しさん2008/05/26(月) 17:37:34
>>276
そんなに直感にあった言語だったら今頃大学生は皆Cが書けるように
なってるはずだが。

それどころか現実は日本の技術者激減で国家滅亡の危機なわけだが
0281デフォルトの名無しさん2008/05/26(月) 18:20:57
古い言い伝えを思い出すな。

紀元前七世紀、エジプト王プサメティコス一世は臣下に命じ、生まれたばかりの赤ん坊を一切のプログラミング言語とは無縁に育てさせた。
そして赤ん坊がある程度大きくなった時、ある質問をした。
「"Hello world"はどう記述する？」
答えて曰く「# include <stdio.h>
int main(void) {printf("Hello, world!\n"); return 0;}」
王はC言語が最古のプログラミング言語だと確信したという……。
0282デフォルトの名無しさん2008/05/26(月) 18:35:03
AとBはどこ行った?w
0283デフォルトの名無しさん2008/05/26(月) 19:40:52
勝手に確信する分には別に構わんが、言い伝えるのは勘弁してほしいな
0284デフォルトの名無しさん2008/05/26(月) 22:53:10
駆逐できそうにないですね
0285デフォルトの名無しさん2008/05/26(月) 23:09:44
>281
俺が3丁目の角のタバコ屋の長老から聞いた話だと、その王様がCで
バベルの塔問題を解かせようとプログラミングをしていたら、OOPの神様が
お怒りになり、kill -9の雷を降らせ、以降言語がC++やらObjective Cやら
JAVAやらC#やら諸々へと分裂していったと。
そして、崩れ落ちるcoredumpの中で最後に残っていたのがCshだったそうな。
0286デフォルトの名無しさん2008/05/26(月) 23:23:47
>>276
素人の直感は専門家の正しい知見から180度ずれるという宇宙的な法則があってだな･･･
たとえば、システムヘッダの中で、アンダーバーで始まる名前が
多用されているのを見て、そのまま真似したりする。
30度でも90度でもなく180度だ。これは物理的な必然だ。･･･いや、忘れてくれ･･･
0287デフォルトの名無しさん2008/05/27(火) 09:00:15
そして、C++のOOPを覚えたと思ったら、また180度ずれて、トータル360度ずれて元に戻る。
まさに真理の哲学ですね。
0288デフォルトの名無しさん2008/05/27(火) 20:27:43
CプログラマがC++を使わない理由を探す理由を知りたい。
0289デフォルトの名無しさん2008/05/27(火) 20:47:04
その前に>>288がなぜそんなことを聞くのか理由を知りたい
0290デフォルトの名無しさん2008/05/27(火) 20:50:18
>>288組み込み系では、Cが最適開発環境であることは多い。
0291デフォルトの名無しさん2008/05/27(火) 21:49:33
CプログラマってCだけしか使ってない人？そんなひといるのかな。
少なくともLLの一つや二つは使ってるでしょ。C++は要らないけど。
0292デフォルトの名無しさん2008/05/27(火) 22:07:11
C言語と日本語と英語が使えます。
0293デフォルトの名無しさん2008/05/27(火) 23:42:22
その昔、asahi.comでの求人でプログラマ職若干名ってのがあってね、そのときの
条件ってのが「言語: C言語(日常会話レベル)」だったってのが冗談じゃなくてあった。

職場で同僚とためしに「 printf("hello, world!\n");」「break;」とやってみたが、
ゴメン、俺には無理だわと応募をあきらめた。
0294デフォルトの名無しさん2008/05/27(火) 23:58:49
うちの場合は
「CよりC++のほうがいいのは分かったよ、でも使いません」
のような感じでいつも終わってしまう。
0295デフォルトの名無しさん2008/05/28(水) 00:17:12
考えるのがめんどくさい
息をするのもめんどくさい
0296デフォルトの名無しさん2008/05/28(水) 00:20:34
ゆうちゃんとめんどくさいさい
0297デフォルトの名無しさん2008/05/29(木) 20:16:05
組み込みで使うとかいわれても幅が広くてわかりにくいんだが
携帯ゲーム機用ソフトとかもCで組んでたりすんの？
0298デフォルトの名無しさん2008/05/29(木) 20:44:31
GBAのときはCの方がC++より多かったと思う。今は分からない。
0299デフォルトの名無しさん2008/05/29(木) 21:27:12
なるほど、GBA⇒DSだと性能差は十倍にもなってない感じだし
まだCが多かったりするんだろか。PS3が組み込み系に分類されてたり
携帯電話を組み込み系と言ったら笑われたり、俺にはよくわからん
0300デフォルトの名無しさん2008/05/29(木) 22:48:42
>>299
>携帯電話を組み込み系と言ったら笑われたり

そうなの？　カーナビと携帯は組み込みの2大巨頭だと思ってたよ。
0301デフォルトの名無しさん2008/05/29(木) 23:55:42
「JavaVM乗るような潤沢な環境を組み込みと言うかｗｗ」
っていう考えの人も居るっていうだけの話だが、
実際組み込みって言葉はピンキリで随分曖昧な気がする
0302デフォルトの名無しさん2008/05/30(金) 00:39:26
>組み込みで使うとかいわれても幅が広くてわかりにくいんだが

幅が広いからCでないと厳しい環境もあるっていうんじゃダメかね？
オレが今取りかかってるシステムはRAMが32Kしかないんだが
Cとアセンブラ以外使おうとは思わないよ。とにかくリソースがぎりぎり。
処理時間、セクションやスタックの使用量とかも仕様で出さなきゃならんしな。
必ずしもプロファイラがあるわけでもないし。
0303デフォルトの名無しさん2008/05/30(金) 01:27:45
>301
大量に生産するため、リソースを贅沢にすることは即コストに直結する。
開発コストよりも製造コストが重視される。それが量販製品における
組み込み系の特徴の一つ。携帯電話はこれが極端に当てはまる。
JVMが乗っかるのは潤沢な環境なのではなく、それがために他にくるしわ寄せを
吸収しなければならない分、余計につらいってことだね。

正直、いくら携帯電話の機能が大きくなったといっても、本当にリソースが
豊富に使えるなら、基本が機能追加でコードの流用が効く携帯で、毎度毎度
あそこまでデスマにはならない。
0304デフォルトの名無しさん2008/05/30(金) 01:42:25
アセンブラで組むのが一番だと思うが、極端に可読性が落ちる。
C++だと余計なことをしてくれて自分が望むアセンブラに展開してくれない。
だからC。
0305デフォルトの名無しさん2008/05/30(金) 18:08:50
C++ が C と比較してコンパイル結果を予想しにくくしているものは以下のよう
なものがあると思う。逆にこれらを使わなければほぼ予想通りのコンパイル結果
になるはずだ。

- 非 static メンバー関数の暗黙の this の存在
- コンストラクタからの基本クラスとメンバ変数のコンストラクタ自動呼び出し
- デストラクタからの基本クラスとメンバ変数のデストラクタ自動呼び出し
- 静的変数のコンストラクタとデストラクタの呼び出しとそのタイミング
- コンストラクタを持つ静的局所変数の暗黙の初期化チェック
- 自動変数のデストラクタの呼び出し
- 暗黙の型変換の呼び出し
- 一時オブジェクトのデストラクタの呼び出し
- 仮想関数の呼び出しオーバーヘッド
- 実行時型情報の時間コストと空間コスト
- 多重継承と仮想基本クラスによるオーバーヘッド
- メンバーポインタ操作の時間コスト
- 例外処理の時間コスト (特にデストラクタを持つ自動変数が存在するとき)
- inline 関数の出力コード (ただし大域最適化したときはCでも同じ)
- 複雑なテンプレートの出力コード
- 実体を持たない const 変数がある (ただし大域最適化したときはCでも同じ)
0306デフォルトの名無しさん2008/05/30(金) 18:09:21
C++ に慣れてくれば上のような機能を使っても C 並にコンパイル結果を予想
できるようになってくる。ただし複雑なテンプレートの出力コードの予想はか
なり難易度が高い。
C でもがんばれば上のような機能を実現できるが、結局 C++ の速度と変わら
なくなってしまうはずだ。そのようなソースコードのメンテナンスはよほどの
天才でないとできないと思う。

自分が考える C++ の欠点は
- 複雑なテンプレート使用時のコンパイル時間
- テンプレートと名前空間により中間ファイルのサイズが膨張
- コンパイラのバージョン間で ABI が変わりやすい
- 仕様が大きいので学習が大変
0307デフォルトの名無しさん2008/05/30(金) 21:23:52
さらに C++ の欠点の追加
- 標準準拠度の高いコンパイラが少ない (特にテンプレート)
- テンプレート関連のエラー表示が分かりにくい
0308デフォルトの名無しさん2008/05/30(金) 21:38:24
C++の一番の欠点は、そうやっていちいち他の言語に対する「自分が有利と思う点」を
開陳してまわらないと気がすまない、鬱陶しい奴が多いことだろう。
0309デフォルトの名無しさん2008/05/30(金) 21:53:45
ピアソンやオライリーの本に書いてあることを垂れ流してるだけじゃね？
スレの流れのリソースが厳しい環境での答えにもなってなければ
スレの主題への評価にもなっていない。
0310デフォルトの名無しさん2008/05/30(金) 21:56:59
>>308
どのレスの話？
0311デフォルトの名無しさん2008/05/30(金) 22:19:31
>>308 それは言語の欠点ではなく俺の欠点だ。

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

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

C++がCの代わりになるかもしれないことを主張しているのだからそれほどスレの
主題から離れていないだろ。
0312デフォルトの名無しさん2008/05/30(金) 22:30:05
>>305
>逆にこれらを使わなければ

C でオケ
0313デフォルトの名無しさん2008/05/30(金) 23:15:52
>>312
だな。>>305をコーディング規約にでも書いた日には
「Cでいいじゃねえか!!」と言われそう。
0314デフォルトの名無しさん2008/05/30(金) 23:57:34
Cがこれだけ普及したのは、あまり抽象化しなかったから。
このCに抽象化の手術を施したのが、C++でありJavaでありC#等々。
基本的に無理筋なんだ。
0315デフォルトの名無しさん2008/05/31(土) 01:04:39
抽象化＝クラスと信じて疑わないのがきもい
0316デフォルトの名無しさん2008/05/31(土) 01:25:34
>>312, >>313

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

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

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

最後の項は基本的にうれしいことなので、あえて使いたくないときは
extern を使うなり、アドレスを取得するなりすればよい。
0318デフォルトの名無しさん2008/05/31(土) 03:05:12
>>316
>Cより遥かに安全で保守が容易なプログラムを作れるようになるのだ。

ﾜﾗﾀw
0319デフォルトの名無しさん2008/05/31(土) 04:46:23
・安全で
・保守が用意
共にどこまで把握したことを活用できるか、という問題じゃん？
煽り地味た笑いは早計かと思ふ。

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

>>316
ﾜﾗ太
0320デフォルトの名無しさん2008/05/31(土) 05:15:39
C++否定側の皮肉なジョークだろ？>>305,>>316
0321デフォルトの名無しさん2008/05/31(土) 14:01:59
すこし見ていないうちに話のレベルが少し上がっているな（笑）。まあ、
「新規の言語はすべて旧来の言語のアンチテーゼ」
ある時点で一気に主流になった言語を駆逐するのもそう簡単ではないだろ。
新たな概念も良いけど「誰でも理解できる」という条件を満たさないと意味がない。
「誰でも理解できる」「簡潔に書ける」「効率」等の条件を満たさないと・・・
考えているうちに「自分が生きている内に駆逐されるなら、是非それを経験したい」と思ったよ。
0322デフォルトの名無しさん2008/05/31(土) 19:51:13
>>321
駆逐されたと言う基準はなんだ?
COBOLやFORTRANは駆逐されたのか?
君の生まれる遥か前に生まれたと思うぞ、FORTRANは51歳で未だに現役だ。
0323デフォルトの名無しさん2008/05/31(土) 20:09:07
>>320 決してジョークではない

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

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

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

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

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

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

これらの機能は全くオーバヘッドがないか、Cと同じぐらい処理が自明だ。
そしてプログラムを安全にし保守を容易にする。
0324デフォルトの名無しさん2008/05/31(土) 20:21:23
>>323
>決してジョークではない

ジョークじゃないなら、そろそろ終わりにしなよ
見ていて辛いわ
0325デフォルトの名無しさん2008/05/31(土) 20:26:55
なら見るのを止めるのがおすすめ
0326デフォルトの名無しさん2008/05/31(土) 20:30:07
やっぱりネタかよw
0327デフォルトの名無しさん2008/05/31(土) 20:34:48
C++を知らないから使っていないんだという前提が痛過ぎる
0328デフォルトの名無しさん2008/05/31(土) 20:40:41
>>323
所で、VC++の最適化にはすばらしいものを感じているが。
今のC言語にあそこまでに最適化があるのか？
無ければ、VC++でCらしく書いたほうが優秀と思われ。
VCのはいたASM見たこと有る?
0329デフォルトの名無しさん2008/05/31(土) 20:46:37
ここはC++を無理矢理Cとして使うスレだっけ?
0330デフォルトの名無しさん2008/05/31(土) 21:28:23
いくらなんでも、非静的メンバ関数の使用はありだろ。
暗黙の引数thisが予想できないというのが理解できない。

普通の関数で引数1つ増えるのと比べて何もオーバーヘッドは変わらない。
むしろ呼出規約によってはthisだけレジスタ渡しになって、素の状態ではやや有利な場合すらあり得る。
0331デフォルトの名無しさん2008/05/31(土) 21:36:05
時折Objective-Cを思い出しては、絶望するスレ。
0332デフォルトの名無しさん2008/05/31(土) 22:17:11
ObjC はとっても C 的で良いんだけど、C を置き換える為の物ではないよね
0333デフォルトの名無しさん2008/05/31(土) 22:18:00
字面がｷﾓすぎ
0334デフォルトの名無しさん2008/05/31(土) 22:25:31
事実上Apple版DLRになってるObj-Cランタイムに価値がある訳で
CからObj-Cランタイムを扱うための言語拡張に過ぎないとも言える

C++やC#とは狙いが違う感じ
0335デフォルトの名無しさん2008/05/31(土) 22:26:07
ここのC++厨はPC上で動くアプリしか作ったことないんだろ。
秋月のキットでも買って出直してこいよ。
0336デフォルトの名無しさん2008/05/31(土) 22:28:02
どんな言語でも見た目が気になるのは初学者のうちだけだよ
文法がまずいとそうもいかないけど
0337デフォルトの名無しさん2008/05/31(土) 22:30:24
>>335
恐らくウィンドウズ以外の経験が全く無いんだろうさ
0338デフォルトの名無しさん2008/05/31(土) 22:44:40
C を駆逐出来るのは C だけだな。C++ は失敗作。
誰か C 1x の仕様策定プロセスを始めてくれないかな。
0339デフォルトの名無しさん2008/05/31(土) 23:03:54
Cから発生した言語は、みんなそのルートを通る。
いまさら新しいCを作ってどうする?
0340デフォルトの名無しさん2008/05/31(土) 23:05:18
どのルート？
0341デフォルトの名無しさん2008/05/31(土) 23:09:53
Cを継承する、拡張する、駆逐する、いわゆる後継のために。
C++も最初はCにクラスが付いただけの言語だった。
0342デフォルトの名無しさん2008/05/31(土) 23:12:46
C++ はもう良いだろ。C を駆逐するのに失敗した言語はスレ違い。
0343デフォルトの名無しさん2008/06/01(日) 00:06:27
CはC99で失敗したからもう発展しない。
VCはC99未対応、gccは -std=c99 が必要
0344デフォルトの名無しさん2008/06/01(日) 00:08:52
VCは要らん
0345デフォルトの名無しさん2008/06/01(日) 00:42:17
>>328
さすがにCとC++の最適化ルーチンは共通化しているでしょう。
疑いもしていないので調べたことはないけど。
03463212008/06/01(日) 11:47:24
>>322
曖昧な言葉「駆逐」の定義をまた始めるのか？自分はそれに参加する気はないね。
ここはスレタイに曖昧な言葉を使った雑談スレだと思っていたぞ。
レス内容に対してレスせずに発言者に対してレスする、このようなレスがレベルを下げるのを理解して欲しいね。
#答えよう。自分はFORTRANより年上だ。
0347デフォルトの名無しさん2008/06/01(日) 12:01:43
間違いなくここは雑談スレだけど、それを表立って表明してはいけない約束だぜ。
つか、この板のほとんどのスレが雑談スレだ。初学者には雑談以上の話かもしれんけど。
0348デフォルトの名無しさん2008/06/01(日) 13:00:25
C++がCを駆逐できなかったのはJavaのような誇大広告を怠ったからだよ。
「C++は2年以内にCを完全に殺す」のような宣伝をしていればCにダメージを与えていたのに。
あの会社の立場上難しいだろうけど。
0349デフォルトの名無しさん2008/06/01(日) 14:36:50
Why I No Longer Like or Use C++
ttp://www.hyuki.com/yukiwiki/wiki.cgi?WhyINoLongerLikeOrUseCPlusPlus
0350デフォルトの名無しさん2008/06/01(日) 14:55:59
>>349
C++ではなくCを使う理由にはなっていないんだよ。
環境によっては Java, C#, Python, Ruby などを使う理由にはなるが。
0351デフォルトの名無しさん2008/06/01(日) 15:00:47
>>350
言語が単純で、枯れていて、速くて、資産が沢山あって、
スクリプト言語との連携が良いからだよ。Cでなければ
いけない理由は無いが、C以外にそんな言語は無いからな。
0352デフォルトの名無しさん2008/06/01(日) 15:03:35
原文のほう見ると
http://prophipsi.blogspot.com/2008/03/why-i-no-longer-like-or-use-c.html
このスレで先ほどまで力説してた誰かのようなコメントがいきなりついてますな。
0353デフォルトの名無しさん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.
0354デフォルトの名無しさん2008/06/01(日) 15:50:27
>>351

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

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

>C以外にそんな言語は無いからな。
さらに>>323の機能を使えば安全で便利だぞ。
C++もそういう言語として使えるんじゃないか?
0355デフォルトの名無しさん2008/06/01(日) 16:11:02
「残った部分」とかんな抽象的な。

言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。
毎回チェックするのも大変だし。
>>317で禁止されてる項目はC++がCに比べておいしい所そのものなわけで
これ禁止なら素直にCを使ったほうが早い。
0356デフォルトの名無しさん2008/06/01(日) 16:23:52
>>354
>>>317で残った部分は十分に単純で枯れているぞ。

もう 317 は忘れろ。二度と俺にその話を振るな。
誰も賛同しない物を何でここまで引っ張るかね。
0357デフォルトの名無しさん2008/06/01(日) 16:27:45
もうC++のことは忘れろ。C++はJavaに負けたんだよ。
MSでさえC++は捨ててJavaのパクリを推奨してる。
0358デフォルトの名無しさん2008/06/01(日) 16:32:12
>>355
同意だな
>>317ルールは論外だろ
ちっとも美味しくもなんとも無い"better C"とやらを使うことによって、
少なくともC++のグダグダのABIと、それによるコンパイラ間
非互換性といったおマケはついてくる

それならCのほうがずっといい
無論C99ではなくC89な
0359デフォルトの名無しさん2008/06/01(日) 16:40:41
10 年前ならいざ知らず、今時 C++ をこれだけマンセーするなんて
どれだけ時代が読めないんだろうねえ。しかも中途半端な俺ルールを
ゴリ押ししようだなんて驚くわ。C++ は仕方が無く細々と使うもんだぜ。
0360デフォルトの名無しさん2008/06/01(日) 18:44:34
>>355
>言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。

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

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

個人的な経験から>>323の機能があればCと比較して十分開発がやりやすくなると思っている。
本当はデストラクタを使えれば最高だが、見えにくいオーバーヘッドは避けられないので
敬遠されるだろう。
0361デフォルトの名無しさん2008/06/01(日) 18:45:01
>>358
>C++のグダグダのABIと、それによるコンパイラ間非互換性といったおマケはついてくる

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

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

C++のABIの問題は決して小さくは無いだろ。
何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。
0363デフォルトの名無しさん2008/06/01(日) 23:48:27
>>362

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

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

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

COM的なものをC++のABI問題の解決のために利用しているのは少数派でしょ。
個人的にその手のものをC++で使ったのはDirectナントカぐらいしかないよ。
多分COMの人気がなくなったのは.NETの影響じゃないか? .NETじゃCの代わりに
なるとは思えないが。
0364デフォルトの名無しさん2008/06/02(月) 19:50:18
>>363
>チームメンバの問題はそれほど深刻ではないと思っている。

君のチームがどんなプロジェクトで何を作っていて、
どんな人員構成かも分からんのに参考にはならんよ。
ここの人間がどう思っているかは既に分かってるだろ。
君のローカルルールを採用したい人間は誰も居ない。
検討するだけの価値がある様にも思えない。
0365デフォルトの名無しさん2008/06/02(月) 22:13:53
結局Ｃは現役続行てことでおｋ？
0366デフォルトの名無しさん2008/06/02(月) 22:38:52
今Cが使われてるのって、ファーム、ドライバ、OSのカーネルとかか？
それらを駆逐すればいいんじゃね？
0367デフォルトの名無しさん2008/06/02(月) 23:03:35
なんか抽象化の方策でもあるのか？
0368デフォルトの名無しさん2008/06/03(火) 01:41:34
>>364
>君のローカルルールを採用したい人間は誰も居ない。
>検討するだけの価値がある様にも思えない。

何も俺のルールである必要はないんだぞ。あくまでも1つの例として出しただけだから。
強制しているように見えたなら悪かったよ。
Cで生産性上げるためのもっといいアイデアあったら教えて。
0369デフォルトの名無しさん2008/06/03(火) 01:44:25
クソコードをチェックしてくれるデバッガーを大量に雇う
0370デフォルトの名無しさん2008/06/03(火) 01:55:16
そーいえばEC++(embedded C++)ってどーなってるんだ？
あれってリソース要求がシビアな環境向けのC++なんじゃなかったっけ
0371デフォルトの名無しさん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++ のサブセットなんてダメだってさ。
0372デフォルトの名無しさん2008/06/03(火) 12:37:11
>>370
名前空間がないのが信じられない。実行のオーバーヘッドは全くないのに。
しかもそのせいでサブセットですらなくなった。
0373デフォルトの名無しさん2008/06/03(火) 18:00:11
embeddedだからってサブセットにする必要性がない。
ランタイムライブらっりを小さくし、必要に応じたライブラリを使えばいいだけだし。ちょっとテンプレートの使い方を工夫すれば小さくなるもん
0374デフォルトの名無しさん2008/06/03(火) 21:17:58
小さいの概念がデスクトップとは違うんだろう。
例外機構も入れたくないくらい小さくしたいみたいだから。
0375デフォルトの名無しさん2008/06/03(火) 22:33:22
EC++はC++を小さくするというコンセプトはいいのに
小さくするやり方がまったくおかしいので使い物にならん
仕様考えた奴はC++をよくわかってないアホとしか思えん
0376デフォルトの名無しさん2008/06/04(水) 00:53:36
確かEC++は日本人が中心になって考えたんだよ。
電機メーカーはコンパイラ作りになれていないからコンパイラの実装が楽な
仕様を選んだんじゃないか。
0377デフォルトの名無しさん2008/06/04(水) 03:30:33
某h立で集まった人員の中でパーサ経験ある奴が俺しかいなかったな
コンビネーションパーシングの考え方／作り方の講習係で終わった
その後どうなったのやら話も聞かんけど、C++のサブセット作りたがってたのだけは記憶しとる
0378デフォルトの名無しさん2008/06/04(水) 09:21:02
>>376
コンパイラの実装が楽なはずの機能まで外れているし
何考えてるんだか俺には全くわからない
0379デフォルトの名無しさん2008/06/04(水) 20:07:08
>>378
バイナリのサイズを小さくする
コンパイラの実装を平易にする

これら以外の目的で削られた機能って具体的にどれの事を言ってるの？
0380デフォルトの名無しさん2008/06/05(木) 01:26:39
378じゃないけど namespace
削った目的は分からない。

リンクが済んだらバイナリのサイズは変わらない。
実装は2週間以内が目安(D&Eより)、もちろん実装者によって違うが。
0381デフォルトの名無しさん2008/06/05(木) 02:13:47
namespaceを無くすると名前マングリングが単純化できて、C互換のobjが吐けるとか？
0382デフォルトの名無しさん2008/06/05(木) 03:17:22
>>381
名前マングリングはtype-safeリンケージのために名前空間なんぞを
導入するずっと前から行ってることだろ
オーバーロードのようなものがある限り、type-safeリンケージは必須だ
0383デフォルトの名無しさん2008/06/05(木) 20:30:38
必要ならextern "C"を使えば済むとは思う。
どうでもいいかもしれないけど、
extern "C"が名前空間内でも使用可なのには最初驚いた。
0384デフォルトの名無しさん2008/06/06(金) 22:50:16
const_cast, reinterpret_cast, static_cast, mutable も性能に影響を
与えないし実装は比較的簡単だと思う。
dynamic_cast だけ外すと分かりにくい仕様になるかもしれないが。
0385デフォルトの名無しさん2008/06/07(土) 00:21:26
組み込み向けで小さいコードしか書かないから、きっと要らないのだろう。
0386デフォルトの名無しさん2008/06/07(土) 09:42:06
コンパイラを実装する人の都合で削ったように見えるな。
C++からCへ変換するプリプロセッサで実現できそうな機能しか残ってない。
0387デフォルトの名無しさん2008/06/07(土) 14:12:32
>>386
>コンパイラを実装する人の都合

これは実際非常に重要なのだけれど、C++ ではツールを含めた言語環境を
作る人間と、それを使う人間が完全に分離してしまっているのが不思議。
0388デフォルトの名無しさん2008/06/07(土) 14:33:41
C++談義でもりあがってるところ悪いけど、そんなことより
FORTRAN 77をさっさと完全駆逐してほしい。算術IFとかなんだよあれ。
大文字コードはSQLだけで充分だ。
0389デフォルトの名無しさん2008/06/07(土) 14:40:43
>>388
FORTRAN は多分大型コンピュータと共に死滅するんじゃないかな？
0390デフォルトの名無しさん2008/06/07(土) 14:46:31
いやいや、Fortran 90以降は好きだし使ってるけどな。2kからは
オブジェクト指向になるらしいし。Fortran 77がクソ過ぎて困る。
0391デフォルトの名無しさん2008/06/07(土) 18:17:24
高速な数値計算が必要なところは FORTRAN で作って extern "FORTRAN" で
C++ から呼べばいいんじゃないか?
0392デフォルトの名無しさん2008/06/07(土) 18:20:30
それを更に C で wrap して Fortran から呼び出したらいいんじゃない？
0393デフォルトの名無しさん2008/06/08(日) 00:59:14
>388
算術IF文と論理IF文までしかなかったのはFORTRAN 66。
FORTRAN 77ならブロックIF文が使えるはずだが。

算術IFが廃止されたのはFORTRAN 95からだが、過去の資産の使いまわしに困る
ようなFORTRANに存在価値ってあるのかな。
0394デフォルトの名無しさん2008/06/08(日) 01:10:18
>>393
>、過去の資産の使いまわしに困るようなFORTRAN
FORTRANってベクトルマシンと趣味ユース以外で使われてんの？
0395デフォルトの名無しさん2008/06/08(日) 01:42:38
微妙な計算ライブラリとか結構使われている。
自分が関わった某産業分野の制御でも使ってた。
0396デフォルトの名無しさん2008/06/08(日) 02:15:24
そうなのか。
……未だに何故Fortranなのかが判らん分野なんだよなー。
Haskellやmlなんかの関数型も数学向いてるって聞くけど
取って代わられる可能性あんのかな
0397デフォルトの名無しさん2008/06/08(日) 03:58:14
秘伝のソースを一子相伝で守り続けている世界だよ
魔法が息づいているうちは、早々簡単に取って代わられない
0398デフォルトの名無しさん2008/06/08(日) 18:23:42
楽にプログラミングしたい訳では無くて、楽に計算させたいだけだからね。
学術計算用途ではFortranが長いこと使われててライブラリが豊富にあった。
Fortranから他への移行なんて、ここ10年くらいの話じゃないかな？
それもCとかC++だから、数値計算を専門でやってる人以外は、Fortranの
ほうが楽でいいじゃんとか思う人も多いわけよ。別に困ってた訳じゃないから。
0399デフォルトの名無しさん2008/06/08(日) 18:29:53
Cは蓄積だけでなく、実際実際ベクトル／行列計算の分野では
性能的にFortranに勝てんのでしょ

C++は式テンプレートのような遅延評価での高速化テクニックが最近
出てきてるようだけど、どうなんだろう
0400デフォルトの名無しさん2008/06/08(日) 18:52:01
ベクトル／行列計算の性能を追求するなら、Linuxでクラスタ組んで
Cのライブラリを使うのが主流。
スパコンTOP500とかに並んでるのは、ほとんどそういう用途だわな。
0401デフォルトの名無しさん2008/06/08(日) 18:57:26
Cには多次元配列がない、C99まで標準にはrestrictポインタがない、
複素数がないとかいろいろあるからなあ。科学技術計算にC++とかは
お笑いなんで無視していいけど。
0402デフォルトの名無しさん2008/06/08(日) 19:27:12
>>401
>科学技術計算にC++とかは
>お笑いなんで
そうなんか。識者とお見受け
後学のために詳しく聞きたいです。その用途でC++の難点って例えばどんなあたりですか？
0403デフォルトの名無しさん2008/06/08(日) 19:37:58
PGI とか C++ にも対応してるけど、科学技術計算でダメなんか?
まあ C++ なんかどうでも良いけど。
0404デフォルトの名無しさん2008/06/09(月) 22:52:58
スパコン使う分野はともかく現在の数値計算の最前線(新米二等兵とも言う)では
圧倒的にC++が使われているよ。
Fortranの時代と比べてどちらがマシかは判断しかねる。
0405デフォルトの名無しさん2008/06/11(水) 18:53:28
CもC++も、<適度に・中途半端に>なんでもやれる言語だからね、良くも悪くも。
0406デフォルトの名無しさん2008/06/11(水) 19:06:05
C よりも C++ を先に駆逐して欲しいな
既に朽ち始めているから気に病む必要も無いかもしれんが
0407デフォルトの名無しさん2008/06/11(水) 20:31:32
逆に Java や C# に限界を感じて C++ は再評価され始めているんじゃないか?
0408デフォルトの名無しさん2008/06/11(水) 20:41:02
JavaやC#の限界ってなんのこと？
0409デフォルトの名無しさん2008/06/11(水) 21:09:19
VMの外の人と話せないこととか
0410デフォルトの名無しさん2008/06/11(水) 21:49:55
つ JNI
0411デフォルトの名無しさん2008/06/11(水) 21:57:42
むしろＣ＋＋が再評価ってなんのこと？？？
0412デフォルトの名無しさん2008/06/12(木) 09:27:16
C++/CLIのことだろう
0413デフォルトの名無しさん2008/06/12(木) 11:00:04
>>412
あれ便利っつーか楽っつーか、確かにいいんだけど
言語仕様としては究極の汚さだよなあ。
0414デフォルトの名無しさん2008/06/13(金) 18:10:15
Javaのようにオブジェクト指向を強制する言語には限界がある。
C++のように、低水準プログラミング、構造化プログラミング、OOプログラミング、
テンプレートメタプログラミングを混ぜて使えるほうが現場で役立つ。
0415デフォルトの名無しさん2008/06/13(金) 19:05:32
1 行目と 2 行目以降は全く関係無いね
0416デフォルトの名無しさん2008/06/13(金) 21:16:58
役立たないとはっきり書いてほしかったのかな?
0417デフォルトの名無しさん2008/06/13(金) 21:18:29
自己紹介には及ばん
0418デフォルトの名無しさん2008/06/14(土) 17:00:28
アセンブラから見てCってどうなの？
0419デフォルトの名無しさん2008/06/14(土) 17:08:30
ブロックの先頭でしか局所変数を宣言できない C90 の仕様は勘弁してほしい。
あと inline 関数が標準化されていないのも困る。
組込み環境ではそれだけの理由でも C++ の方を使いたいよ。
無理やり C を使わせられたら発狂しそうだ。
0420デフォルトの名無しさん2008/06/14(土) 17:10:57
C99 か GCC でオケ
0421デフォルトの名無しさん2008/06/14(土) 17:14:18
#define INLINE _inline
0422デフォルトの名無しさん2008/06/14(土) 17:26:15
#pragma inline 使うコンパイラがあるので #define だけではすまない。
0423デフォルトの名無しさん2008/06/15(日) 00:49:57
そこで_Pragma演算子よ、って結局C99というオチ。
0424デフォルトの名無しさん2008/06/15(日) 00:55:33
C++
0425デフォルトの名無しさん2008/06/15(日) 13:00:19
C以外の中級言語つくろうって動きはないのかね
0426デフォルトの名無しさん2008/06/15(日) 13:44:05
Dは無視ですか、そうですか
0427デフォルトの名無しさん2008/06/15(日) 15:36:22
C90 はポータビリティを考えたら外部識別子が 6 文字までしか使えないから使いにくい。
C++ は 1024 文字まで保障されている。
0428デフォルトの名無しさん2008/06/15(日) 15:43:45
そういやそんなのあったな・・・全く守ってねーや
0429デフォルトの名無しさん2008/06/15(日) 16:49:15
>>427
もっともC++処理系自体にはポータビリティがないがなw
0430デフォルトの名無しさん2008/06/15(日) 17:03:02
きっと処理系のできは時間が解決してくれるよ。
0431デフォルトの名無しさん2008/06/15(日) 17:05:51
もう時代の審判が下るくらいの時間は経ってると思うが、
今後これ以上何かあるかなあ…
0432デフォルトの名無しさん2008/06/15(日) 18:24:16
今の C++ コンパイラってそんなに標準準拠度が悪いの?
組み込みなら C のように標準ライブラリの一部が削られているかもしれないけど。
VC9 と GCC4.x は問題ない範囲だと思うけど、準拠度の低いのってどんなのある?
0433デフォルトの名無しさん2008/06/18(水) 15:20:55
>>431
B言語でもやってろ
0434デフォルトの名無しさん2008/06/18(水) 15:55:05
C 言語のように構造体メンバのアクセス制限のない言語を使って複数人で開発するのは難しく
ないですか? 以下の開発方法しか思いつかないのですが。

- 構造体オブジェクトへのアクセスは必ずその構造体用の関数を経由するように周知徹底する
- 構造体定義を利用者から隠してメンバへのアクセスを不可能し、ヒープからオブジェクトを
　生成する関数を用意する
- 構造体の文書を整備し、定義に変更があったらその構造体を使っている場所を点検し直す

インライン関数があれば最初の方法が現実的かな。
0435デフォルトの名無しさん2008/06/18(水) 16:40:50
- 一度定めた構造体の定義に対して互換性がなくなるような変更をしない
0436デフォルトの名無しさん2008/06/18(水) 18:13:08
>>435
それはpointみたいに非常に単純なものでない限りは
現実問題としては無理なので、
opaqueな型にしてしかもメンバにmagic number仕込むとかやったほうがいいな
0437デフォルトの名無しさん2008/06/18(水) 19:18:44
何か無理やりOOをやりたいのか？C++じゃないんだが。
0438デフォルトの名無しさん2008/06/18(水) 20:03:38
>>434
拡張子をだなcppに変えて（ｒｙ
0439デフォルトの名無しさん2008/06/18(水) 20:44:55
>>437
OO まではいかないけど抽象データ型を使うとプログラムの変更に強くなるし楽だと思う。
C の標準ライブラリでは FILE ぐらいしか思いつかないけど、Windows ではよくハンドルを
使っているようです。C の場合整数のハンドルより構造体のポインタを使ったほうが型安全
でいいかもしれませんね。
コンテナのようにある程度複雑の構造だと抽象データ型じゃないとつらいんじゃないかな。
0440デフォルトの名無しさん2008/06/18(水) 23:57:02
>>434
むしろOO的には、一番目と二番目を徹底すべきじゃないのか？
C++であっても。
0441デフォルトの名無しさん2008/06/19(木) 00:38:02
>>439
いや、構造体をクラスに見立ててOOしたいんだろ？
じゃなきゃ、>>434の1行目のようなアクセス制限が云々なんて前提が出てくるとは思えない。
Cのパラダイムを無視して、突然こんな前提で設計しろと言われたらオレは難色示すね。
というわけでお前の考え方では、複数人での開発は難しくなるだろう。
これまで培われたコンセンサスに乗っ取った構造体の使い方をすればいい。
無理してオレ流OOルールを持ち出せば、上で叩かれているC++のローカルルールと同じ問題になると思うがね。
お前はCのパラダイムを無理やりOOに当てはめて解釈しようとしてるんじゃないのか？

ああ、それと今オレがCで書いているシステムは、ヒープ割り当てができないようになってて、
スタックは1Kしか使えないんだがどうするんだい？
オレ流OOルールをもうひとつ追加するのか？RAMも16Kに減らされそうなんだが。
0442デフォルトの名無しさん2008/06/19(木) 00:45:25
RAMが16Kbyteもあるなんて贅沢だw
0443デフォルトの名無しさん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++ から便利機能を
削除するのは別次元の話だと思うよ。
0444デフォルトの名無しさん2008/06/19(木) 02:07:30
C++はいらないけど、C++コンパイラは必要。

CのソースをC++でコンパイルすると型チェックが厳密なんで
バグ出しにたすかる。プロトタイプ宣言の型が省略可能とか
mallocが暗黙的に型変換されるとかありえない。あとNULLも0で
統一してくれ。
0445デフォルトの名無しさん2008/06/19(木) 02:11:53
>>443
COOL 見たけどかなり面倒くさそう。
書くときの面倒くささよりコンパイラの安全性チェックができなくて
変更を間違ったときに気づかなくてバグになりそう。
これなら20年ぐらい前のC++仕様でも楽に安全に作れると思う。
0446デフォルトの名無しさん2008/06/19(木) 02:22:14
CでOOPLならObjective-Cがあるじゃん。あれもあれで変な言語だけど。
0447デフォルトの名無しさん2008/06/19(木) 02:28:21
Objective-C は C Compiler でコンパイル出来ないから、、、
と思ったけど POC を忘れてたわ。

http://users.pandora.be/stes/compiler.html

C++ より Objective-C の方が C の発想に近いよね。
0448デフォルトの名無しさん2008/06/19(木) 02:35:35
http://grape.mtk.nao.ac.jp/~makino/articles/worse-is-better-ja.html

ここに書かれている通り C は「悪い方がよい」原則。ObjC も同じ。
C++ はどちらかというと CL の辿った道に近い気がする。
つまり「正しい」アプローチで作られた「複雑巨大システム」。
0449デフォルトの名無しさん2008/06/19(木) 02:42:51
「悪い方がよい」原則って、意味のある言葉じゃないだろ。
いいものが定着するとなにも言わずに、悪いものが定着すると
「悪い方がよい」って言えばいいんだから。
0450デフォルトの名無しさん2008/06/19(木) 02:46:57
>>441
抽象データ型なんて昔から C で普通にやっていることだよ。
C++ の前の C with Classes でもこれをやりやすくするためにアクセス保護を導入したし。

構造体の定義が可視ならヒープにとる必要もないしスタックにもオブジェクトを置けるよ。
定義が可視ならもちろんアクセス保護があったほうが安心だけど。
0451デフォルトの名無しさん2008/06/19(木) 02:52:50
>>449
リンク先を読めば意図は分かると思うけど、気になるなら
「New Jersey アプローチ」と読み替えても良いよ。
0452デフォルトの名無しさん2008/06/19(木) 02:59:11
Java も「悪い方がよい」原則のような気がする。
0453デフォルトの名無しさん2008/06/19(木) 03:23:24
>>451
>>449をよく読めば意図が分かると思うけど、気になるなら
「悪いものが定着したときは「New Jersey アプローチ」って言えばいいんだから」
と読み替えても伊井よ
0454デフォルトの名無しさん2008/06/19(木) 03:30:42
それ元ネタが凝った角度でモノ書こうとして失敗してる例に感じるな
タイトル先行で書き下されたかのような。

完璧を求めると複雑巨大になり弊害がある
単純さを求めると完全ではなくなり弊害がある

一長一短って話だろ　なんでworse is betterやねん
0455デフォルトの名無しさん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
0456デフォルトの名無しさん2008/06/19(木) 17:50:52
あ、なるほど。その文書読んでから読み直すと少し納得
少なくともタイトル先行な面白書きではない訳ですな

で、改めて読み直してみたけど、やっぱり俺には誤解が残る
Lispの造型が足りないせいか、頭が足りないせいかな
0457デフォルトの名無しさん2008/06/19(木) 20:59:37
LISPの造型が足りないというのは、カッコの数が少なすぎるということかな？
0458デフォルトの名無しさん2008/06/19(木) 21:19:58
>>455
だから、Lisperじゃない普通の人にとってはWorse is Betterには意味がない
ってことじゃないの。
こんなの何でも適当できるよ。

Linux使い「Windowsが普及してるのはWorse is Betterだから」
元共産主義者「資本主義が普及しているのはWorse is Betterだから」
チャーチル「民主主義が普及してるのはWorse is Betterだから」
0459デフォルトの名無しさん2008/06/19(木) 21:40:30
>>457
あ、造詣か鬱氏　どうやら後者のようだ
0460デフォルトの名無しさん2008/06/19(木) 21:43:13
>>458
よく読みな

つ http://grape.mtk.nao.ac.jp/~makino/articles/worse-is-better-ja.html
0461デフォルトの名無しさん2008/06/19(木) 21:49:08
つうか、現実の「複雑巨大システム」であるMulticsとPL/Iの失敗への
反省・アンチテーゼとしてUnix/Cが生まれたわけで、そのことさえ抑えておけば十分。

なぜかその論文？ではその有名な事実に触れてもいないけどね。
Unixの「New Jerseyアプローチ」は、理由もなく／何も無いところから
産まれ出てきたものでは無い。

データも何も無い、分析とは言いがたい内容で、単に「Worse is Better」とか
題目だけ唱えてもそれは題目でしかなく、何の意味も無いと思う。
まあ、一種のネタ文書なんだろうな。
0462デフォルトの名無しさん2008/06/19(木) 21:49:30
自分で考える前に質問してしまう人がいるのは何でなんだぜ？
0463デフォルトの名無しさん2008/06/19(木) 21:50:55
>>460
ほら、自分の言葉で説明できないだろ。Worse is Betterってのは
単なるお題目なんだよ。
0464デフォルトの名無しさん2008/06/19(木) 21:55:19
>>461
>なぜかその論文？ではその有名な事実に触れてもいない

それはそういう文脈じゃないからだよ。
当然 MIT の連中が Multics を知らない訳はないでしょ。この文脈では
彼らにとっては Multics より ITS の方が現実的な意味を持っているだけ。
そこら辺の歴史は自分で勉強してチョ。
0465デフォルトの名無しさん2008/06/19(木) 22:01:19
>>463
文章を読んで理解出来なかった奴に説明するのは無理だよ。
それは俺の能力ではどうしようもない。諦めてくれ。
0466デフォルトの名無しさん2008/06/19(木) 22:01:30
つまりわかりやすく言えばLisperの僻みだろ。

「こんなに素晴らしく美しい言語であるLispが天下を取れないのはなぜか？！
　それは普及するものがWorse is Betterだからだ！Lispは悪くない！」

っていう発想の転換、悪く言えば現実逃避をしてるだけ。一般人には
共感が得られない。
0467デフォルトの名無しさん2008/06/19(木) 22:03:37
>>466
君読んでないのがバレバレだよ。
0468デフォルトの名無しさん2008/06/19(木) 22:07:03
つか Worse って言葉に引き摺られて論旨が見えてないでしょ。
別に UNIX/C を馬鹿にしてる文章じゃないんだぜ。とほほ…
0469デフォルトの名無しさん2008/06/19(木) 22:08:13
>>465
そういう言い方がカルトくさいんだよ

「文章を読んで大作先生の素晴らしさを理解出来なかった奴に
説明するのは無理だよ。それは俺の能力ではどうしようもない。諦めてくれ。 」
とか、
「君、大白蓮華読んでないのがバレバレだよ。」
って言ってるのと変わらん。そんなの知るかボケ、と言わせてもらおう。
0470デフォルトの名無しさん2008/06/19(木) 22:10:20
さて、自転車置き場の議論が始まりそうだから退散するとしますか…
0471デフォルトの名無しさん2008/06/19(木) 23:08:12
>>448
俺はC++も「悪い」に属すると思う。
そうでなければここまで広まらなかったに違いない。
0472デフォルトの名無しさん2008/06/20(金) 12:38:14
広まったのは単にMSのせいかも
0473デフォルトの名無しさん2008/06/20(金) 13:55:19
SunはMSを潰すためにJavaを出した。MSはJavaとの共倒れを狙ってC#を出した。
0474デフォルトの名無しさん2008/06/20(金) 14:07:48
実装が単純ならば移植しやすく広まりやすい。
正しいものを広めるより広まったものを改善するほうが簡単。
完全に正しいものを作ろうとすると最後の20%に努力の80%が費やされる。

つまり「悪い」の定義は単純な実装と最低限の品質で最大限の評価を得ること。
0475デフォルトの名無しさん2008/06/20(金) 14:23:55
それなんてエロゲ？
0476デフォルトの名無しさん2008/06/20(金) 19:08:09
>>472
MFCのせいでC++が浸透しないのかも
0477デフォルトの名無しさん2008/06/20(金) 19:13:46
MFC以外のもっと使いやすいC++用RADがあったら
普及したかもなぁ・・・ってBCBは？！
0478デフォルトの名無しさん2008/06/20(金) 19:24:27
>>477
VC++にVCLが標準装備だったらなあ
0479デフォルトの名無しさん2008/06/20(金) 21:57:16
VCLそのものがC++で書かれていないのが痛い
0480デフォルトの名無しさん2008/06/21(土) 10:21:37
くだすれ、落ちてねえ?
0481デフォルトの名無しさん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
0482デフォルトの名無しさん2008/06/23(月) 08:18:04
Jim Waldo の "Worse is worse" も翻訳があった。助かるな。
http://www.kt.rim.or.jp/~hisashim/waldo/worseisworse.ja.html
0483デフォルトの名無しさん2008/06/23(月) 09:09:28
>>481-482
どっちも既に読んでるよ。ご苦労。
0484デフォルトの名無しさん2008/06/23(月) 20:56:16
しかも前者に至っては既出
0485デフォルトの名無しさん2008/06/24(火) 00:00:14
そんなことよりWordsworth読もうぜ！
ttp://www.bartleby.com/145/ww260.html
0486デフォルトの名無しさん2008/06/24(火) 00:25:54
Yeats >> Blake >>> (越えられない壁) >> Wordsworthだろ
常識的に考えて・・・

まあ、英国詩人全部合わせてもRimbaud一人に勝てないけどな
0487デフォルトの名無しさん2008/06/24(火) 00:27:15
ランボーってベトナム帰りのあいつか？
0488デフォルトの名無しさん2008/06/24(火) 00:29:07
元ネタだから、yesと言っても間違いじゃない。
0489デフォルトの名無しさん2008/06/24(火) 00:38:16
Close To The Edgeは名盤だよな
0490デフォルトの名無しさん2008/06/24(火) 20:53:56
俺はHeart Of The Sunriseの方が好き。
0491デフォルトの名無しさん2008/06/25(水) 01:01:07
C言語のプログラマは、自分たちを一番優等だと思ってるところが問題だ。
0492デフォルトの名無しさん2008/06/25(水) 01:54:54
つまりプログラマの殆どはそんなこと思っているのか。
0493デフォルトの名無しさん2008/06/25(水) 08:28:14
言語の違いなんてバイオリンとピアノの違いでしかない。
道具が違うからって音楽家は人を馬鹿にしたりしないだろ。
それと同じこと。


ただし、ヴィオリストは馬鹿だけど。
0494デフォルトの名無しさん2008/06/25(水) 08:40:33
ベーシストをDISる厨バンドマンならいくらでも
0495デフォルトの名無しさん2008/06/25(水) 11:04:51
>>493
>道具が違うからって音楽家は人を馬鹿にしたりしないだろ。
譬えの誤謬だ。
カズー奏者はどう頑張ってもバカにされる対象。
0496デフォルトの名無しさん2008/06/25(水) 21:50:27
>>493
>ただし、ヴィオリストは馬鹿だけど。

(^^;;;;;

なぜ Va は自虐的なんでしょうね、てスレ違いですけど。
0497デフォルトの名無しさん2008/06/25(水) 22:21:01
他の言語を貶す言語廚は、自分の推す言語使いこなせななくて自信がないから他の言語を貶すんだろうね。

自分の目的に合致している言語を使いこなしているのなら、他の言語なんて眼中にないだろう普通
0498デフォルトの名無しさん2008/06/25(水) 22:27:33
>>497
誰しもそこから出発するわけでして、許してあげましょうよ。
0499デフォルトの名無しさん2008/06/25(水) 22:30:02
このスレの主旨はそういう言語戦争とは違うと思うけど？
そろそろCに変わる言語が欲しいね、という前向きな話だよ。
0500デフォルトの名無しさん2008/06/26(木) 02:44:29
BCPLとK&Rの頃から愛してる

C99になってもっと恋しくなった

BSDとEmacsも愛してる

Cを知ったその日から
僕のプログラミング地獄に音楽は絶えない
0501デフォルトの名無しさん2008/06/26(木) 11:02:04
K&Rからなら信じるけど。
BCPLからなんて誰が信じるか。
0502デフォルトの名無しさん2008/06/26(木) 23:12:49
そこマジレスするところじゃなくね？w
0503デフォルトの名無しさん2008/06/26(木) 23:15:28
1億と2千年たってもＣ言語は健在だお。
0504デフォルトの名無しさん2008/06/26(木) 23:46:41
そんなに人類生きてんのかな
0505デフォルトの名無しさん2008/06/27(金) 00:08:34
マジレス乙ｗ
0506デフォルトの名無しさん2008/06/27(金) 06:25:07
そのころには人類は量子コンピュータ上でシュミレーティッド
された世界に住んでるんだろな。動作言語はもちろんC-100002000

0507デフォルトの名無しさん2008/06/27(金) 07:07:17
シュミレーティッド
0508デフォルトの名無しさん2008/06/27(金) 23:47:05
C++の何がまずいかは語りつくされたようだから、
次はＤのなにがまずいかについて聞かせてくれまいか。
0509デフォルトの名無しさん2008/06/27(金) 23:49:19
D言語は良く知らない
0510デフォルトの名無しさん2008/06/28(土) 00:02:19
DこそＣを駆逐してやるという目的で生まれた言語だよね？
0511デフォルトの名無しさん2008/06/28(土) 02:01:19
でもDコンパイラってCと100%互換なんじゃなかった？
むしろ共存したいんじゃないの？
0512デフォルトの名無しさん2008/06/30(月) 16:30:47
互換性は罠だな。
共存すると見せかけてＣプログラマをＤに取り込んでおいて、
Ｃに戻れないほど脳みそを蝕んでおいてからはしごをはずすんだろう。
0513デフォルトの名無しさん2008/07/02(水) 12:14:30
なんか方向性が逆じゃないか？
スタック変数の自動管理と、一般的な制御構文の使える高級アセンブラがあればいい。
0514デフォルトの名無しさん2008/07/02(水) 13:17:54
そんなやつはもはや少数派なんだよ
0515デフォルトの名無しさん2008/07/02(水) 18:36:13
>>513
マクロアセンブラで遊んでてください。
0516デフォルトの名無しさん2008/07/02(水) 23:57:30
Java とか.netのVMのアセンブラを使えば、幸せになれるんじゃないか？
05175132008/07/03(木) 02:13:15
>>516
JVMとか.netのCLRとかは、それこそJavaやC#使えばいいだろ。
Cの本領発揮は、もはや絶対アドレスやIOポート参照が必要なところか、
CPUレベルの最適化が必要なところだけなんだから、だったらそこだけ
高級アセンブラで書いて、残りは本当の高級言語で書けばいい。
0518デフォルトの名無しさん2008/07/03(木) 15:18:31
>>513 >>517
>高級アセンブラ
それがCじゃないのか？
0519デフォルトの名無しさん2008/07/03(木) 18:18:37
Cはポータビリティのために、効率が悪い点が多いんだよ。
低級言語は、機種依存な部分だけに使えばいい。
0520デフォルトの名無しさん2008/07/04(金) 18:31:29
>>519
ここで低級言語といってるのはCのこと？アセンブラのこと？
0521デフォルトの名無しさん2008/07/06(日) 15:47:30
>>511
惜しい。コンパイラは互換性無いよ。
互換性があるのはリンカ。
0522デフォルトの名無しさん2008/07/06(日) 16:18:21
>>520
低級はローレベル。すなわちステムに近いことを示す。システム記述言語であるアセンブラやC/C++などじゃないか。
0523デフォルトの名無しさん2008/07/07(月) 13:42:35
ttp://ja.wikipedia.org/wiki/%E4%BD%8E%E7%B4%9A%E8%A8%80%E8%AA%9E
0524デフォルトの名無しさん2008/07/12(土) 23:15:15
>>522
Cと他言語(Java等)を比べて低級な方って意味で言ってるのか、
それともCとアセンブラを比べて低(ry
ってことだろじょしこー
0525デフォルトの名無しさん2008/07/14(月) 11:01:59
いや俺はJKよりJCのほうｇ
0526デフォルトの名無しさん2008/07/14(月) 12:03:02
もっとも低級言語に近い高級言語Ｃ。この独特のポジションにいる限りCobolやVBが滅びても
Ｃが滅びることはないように思う。
0527デフォルトの名無しさん2008/07/14(月) 15:32:42
>>526
当然だな
0528デフォルトの名無しさん2008/07/14(月) 23:47:27
そもそも、現在生き残っている OS で C を使わないものが、どれだけ存在するのか？
それ等の OS が全て駆逐されないかぎり、C は駆逐されないのは自明
0529デフォルトの名無しさん2008/07/15(火) 00:42:27
まったくだ。リア工の俺にはCの無かった時代というのが想像できない。
0530デフォルトの名無しさん2008/07/15(火) 01:08:16
LISPマシンが市場抑えていたらどうなったんだろう、って想像くらいか
マシン語が括弧だらけになるんだろうな
サンもJavaマシンとか考えてたな　あれは夢想に終わったんだっけか

後者はマシン語がJavaVMのバイトコードに置き換わるだけだな
実現していたところで、結局その上にCコンパイラとか出て来て意味不明な事になってたんだろうな
0531デフォルトの名無しさん2008/07/15(火) 05:16:55
>>530
ICOT のアレは？
0532デフォルトの名無しさん2008/07/15(火) 19:58:25
34bitアーキテクチャが流行っただろうな
0533デフォルトの名無しさん2008/07/15(火) 21:13:20
将来、
GPUにDSP系のプロセッサを乗せて
そいつにコードを転送する必要が生じたとき、
そのコードはC言語をはじめ、手続き型言語では記述できない

組み込み系も視野に入れるなら、C言語の立ち入ることのできない領域は今でもあるよ。
FPGAとかあるし。
0534デフォルトの名無しさん2008/07/15(火) 21:24:01
>手続き型言語では記述できない

すまん。
俺にはそんなものがあるとはちょっと想像が付かない。
どういうこと？
0535デフォルトの名無しさん2008/07/15(火) 22:16:17
>>534
FPGAとかゲートアレイっていう、電子回路をプログラミングできるチップがあって、
そいつをプログラミングするにはSystem-CとかHDLとかいう言語を使うんだ。
基本的には
「○番ポートと○番ポートの入力を足したり割ったりして、○番ポートに出力せよ」
という宣言の羅列になる。

本物のハードよりは遅いけれど、ソフトウェアよりは速い。
ソフトウェアより融通が聞かないけれど、ハードウェアよりは融通がきく。
という建前だった。

今は知らないけど。
0536デフォルトの名無しさん2008/07/16(水) 01:48:03
それって手続き型言語で記述できないのか？
0537デフォルトの名無しさん2008/07/16(水) 01:55:14
できるでしょ
0538デフォルトの名無しさん2008/07/16(水) 02:34:18
手続き型言語を procedural language の訳語とするなら無理だろう
逐次実行であることが第一義だから対極にある
ただ、C言語を駆逐する方向という意味では、全く逆に取り込まれていく方向にあると思う
これは、言語・ソフト的にという意味では無くて、ハード的にという意味だが
0539デフォルトの名無しさん2008/07/16(水) 06:06:11
SystemCはC++で書けるんだが
0540デフォルトの名無しさん2008/07/16(水) 07:06:43
>>534
大雑把に書くと
手続き型言語は演算子を順番に評価実行する。
HDLなどの記述言語は、すべての演算子が同時に評価され常に評価結果が反映される。

HDLに適した処理を手続き型言語で書き直すと処理時間が遅くなりすぎる。
手続き型言語に適した処理をHDLで書くと回路規模が大きくなりすぎる。まあこれは、HDLでCPUを書いてしまえば解決できるというのがノイマン型コンピュータというか手続き型言語の原点かな。



0541デフォルトの名無しさん2008/07/16(水) 07:17:51
記述できるじゃないか。
0542デフォルトの名無しさん2008/07/16(水) 08:12:41
まぁ、手頃なスクリプト言語で書くほうが無難ってことだな。
0543デフォルトの名無しさん2008/07/16(水) 08:36:05
haskellでHDL書きたい
0544デフォルトの名無しさん2008/07/16(水) 09:04:28
>>543
atomでいいんじゃないか？
http://funhdl.org/wiki/doku.php/atom
0545デフォルトの名無しさん2008/07/16(水) 12:15:23
>>541
記述できてもパフォーマンスを満たせない
0546デフォルトの名無しさん2008/07/16(水) 15:31:49
できないじゃなくて現実的じゃないってことか、把握
0547デフォルトの名無しさん2008/07/23(水) 08:10:10
CはどんなCPUでも同じ文法で動く、“共通アセンブラ”みたいな位置づけ。
他の言語と比べること自体がナンセンス。 もう機能追加とかしない方がいい。
CにはOOだのGCだの必要なし。それはLLとかに任せればいい。

0548デフォルトの名無しさん2008/07/24(木) 01:45:34
CはC++の例外相当の処理を効率よく実行できないので不十分。
C++からCへのトランスレータが使われなくなったのはそのせい。
0549デフォルトの名無しさん2008/07/24(木) 07:18:46
>>547
同意。C99も失敗だったかもな。
0550デフォルトの名無しさん2008/07/24(木) 13:44:29
185でｶﾞｲｼｭﾂ
0551デフォルトの名無しさん2008/07/25(金) 07:09:39
ランタイムライブラリを統一できないから、それを必要としないCが生き残る
MSがそれを統一したような気がしないこともないが、それは言わない約束だからCが生き残る
0552デフォルトの名無しさん2008/07/25(金) 10:11:24
>>551
libcって知ってる？
2行目も意味不明
0553デフォルトの名無しさん2008/07/25(金) 13:18:37
libcを他のライブラリと区別する理由はない
0554デフォルトの名無しさん2008/07/26(土) 20:52:32
インタプリタが生き残るよ
0555デフォルトの名無しさん2008/08/13(水) 17:10:02
C99のTechnical corrigenda TC３はどんな内容ですか？
0556デフォルトの名無しさん2008/08/31(日) 22:30:01
libcって、ANSIレベルに毛が生えた物、って先入観しかないんだが…
0557デフォルトの名無しさん2008/09/01(月) 12:48:32
Cが駆逐されると思ってるかどうかで考え方がかなり変わるみたいだな

Windows使ってるとMSが潰れたら困るよ、みたいな感覚で関数型言語やってる人とか
なんかすごくね？
0558デフォルトの名無しさん2008/09/01(月) 22:19:47
Windowsを完全に駆逐するためには
ってスレがあってもいいかもな。良くないか。
0559デフォルトの名無しさん2008/09/01(月) 22:58:47
Macしかないな。
0560デフォルトの名無しさん2008/09/01(月) 23:03:12
Macをプログラム言語にたとえるとlispになるのかなぁ。
とMacもlispも使ったことのない俺が言ってみる。


0561デフォルトの名無しさん2008/09/02(火) 19:34:55
Objective-C涙目。しかし、たとえるならRubyかな。
触れ込みの良さ、扱いやすさと、後方互換性の欠如、筋の通らない仕様変更とか。
0562デフォルトの名無しさん2008/09/02(火) 20:18:58
宗教じみてる点でも似てるな
0563デフォルトの名無しさん2008/09/03(水) 06:51:40
指導者にカリスマがあるからな、仕方ない。毛はないが。
0564デフォルトの名無しさん2008/09/03(水) 22:49:49
モルモン教だからだろ
0565デフォルトの名無しさん2008/09/05(金) 00:46:43
神に祝福された存在であるRubyを、ちょっと小洒落てるだけがとりえのMacなんかと同列に扱わないでください＞＜
0566デフォルトの名無しさん2008/09/05(金) 10:12:21
Ahura Matz 神か。
0567デフォルトの名無しさん2008/09/16(火) 23:40:56
アセンブラが人手によってかかれるべきでない（コンパイラに任せたほうが良い）のと同様に、C言語もまた人手によってかかれるべきではない。
0568デフォルトの名無しさん2008/09/16(火) 23:56:34
なんちゃそれ。
056973.6.30.125.dy.iij4u.or.jp 2008/09/17(水) 13:53:44
>>567
C言語を共通アセンブラと考えるとそうかもしれないね。
0570デフォルトの名無しさん2008/09/18(木) 00:23:07
そこでObjective-Cですね
0571デフォルトの名無しさん2008/09/18(木) 11:05:43
>>567
つまりyaccとかbisonですね
0572デフォルトの名無しさん2008/09/21(日) 01:53:00
2chで語る以前に、言語開発者がｘｘｘよりは組みやすく〜とかいいつつ
アホみたいに言語増やしたけど、今だにC,C++が生き残ってるってことは
駆逐は無理。以上
0573デフォルトの名無しさん2008/09/21(日) 02:58:25
>>572
それ、C,C++の部分に大抵の言語があてはまるんじゃね？
いまだにCOBOLが…、いまだにPerlが…他
0574デフォルトの名無しさん2008/09/25(木) 00:06:47
CPUもコア増やすくらいしかやることないならそろそろプログラム言語に歩み寄っていいんじゃないかい？
VMがこれだけはやってんだから統一VMのモデルでも作ってネイティブでその命令実行してやれ。
そうすりゃCの呪縛も少しは薄れるだろ。
05755742008/09/25(木) 06:30:10
自分で言うのもなんだが、結構いいアイディアな気がしてきた。
VMのコードをネイティブで実行するCPUなんてのは陳腐なアイディアだが、
C言語を駆逐するためにはかなり効果あるんじゃないか？

昔はハードウェアの値段がソフトウェアの値段より遥かに高かったけど、
今じゃすっかり逆転してるわけだし、VMの技術だってかなり枯れてきているころだろう。

インテルがコア数を増やすのも限界まで来て、それでもトランジスタを増やさなければいけないとなったら、
VMの命令をネイティブでサポートなんていう道に走らないとも限らない。

C言語完全駆逐の可能性はまだ残されているっ
0576デフォルトの名無しさん2008/09/25(木) 08:25:57
今のCPUがマイクロコードで実装されていることもご存じないらしい。
Intelが有数のコンパイラベンダーであることもご存じないらしい。
0577デフォルトの名無しさん2008/09/25(木) 12:37:45
>>575
どっちかというと、ＣＰＵの規模より集積可能なトランジスタのほうが上回る様になってきたから、余ったトランジスタ処分用にマルチコアにしたんじゃないの？
0578デフォルトの名無しさん2008/10/02(木) 01:33:27
昔の同僚に、真顔でこれを言ったアフォがおった
ツール類で何でもできるんだとよ
0579デフォルトの名無しさん2008/10/02(木) 08:59:25
>>13 VCなくなったらそれこそC++なんか閑古鳥だろ
0580デフォルトの名無しさん2008/10/02(木) 09:18:21
C++ってなんであんなに肥大化しちゃったの？
http://pc11.2ch.net/test/read.cgi/tech/1219902495/
0581デフォルトの名無しさん2008/10/02(木) 13:26:44
ポインタ概念のないVBがこれだけ進化してるんなら逆にＣ駆逐は時間の問題かと。
昭和生まれが現役引退するころにはプログラム歴史記念館に飾られてるよ。。きっと。
0582デフォルトの名無しさん2008/10/02(木) 15:31:31
>>581
組込みソフトのこともちっとは勉強しろよ坊主
0583デフォルトの名無しさん2008/10/02(木) 18:27:36
小娘かもしれん
0584デフォルトの名無しさん2008/10/02(木) 20:36:41
お前らはC言語無くなったら何使うん？java？
0585デフォルトの名無しさん2008/10/02(木) 20:46:39
Objective-D++
0586デフォルトの名無しさん2008/10/02(木) 20:56:05
はいはい
他は？
0587デフォルトの名無しさん2008/10/02(木) 20:58:55
lispがはやってほしい
0588デフォルトの名無しさん2008/10/02(木) 20:59:09
ポインタの概念は絶対になくならないよ
何もかも値渡しするっていうアホ言語を作るなら別だが
0589デフォルトの名無しさん2008/10/02(木) 21:02:33
C並に低レベルな言語は必要
それがCである必要は無いけれども
0590デフォルトの名無しさん2008/10/02(木) 21:11:44
BCPLがあまりに低レベル過ぎて使いにくすぎたから
C言語が作られたんだよな確か。

だからC言語はなくならないんじゃない？
0591デフォルトの名無しさん2008/10/02(木) 21:25:23
並にって話してるのにそれより低いものを持ち出してもどうしようもないと思うぞ。
0592デフォルトの名無しさん2008/10/02(木) 21:30:28
ロクな返事がねーな
代用できるものも考えずに潰すつもりだったの？君ら
0593デフォルトの名無しさん2008/10/02(木) 21:42:35
C#
0594デフォルトの名無しさん2008/10/02(木) 21:54:08
>>593
C#のネイティブコンパイラが出来たらな。
ngen.exeは腐っているのでもっとまともなネイティブコード
ジェネレータが必要だが。
0595デフォルトの名無しさん2008/10/02(木) 22:33:43
PASCAL
PL/I
0596デフォルトの名無しさん2008/10/02(木) 22:38:47
CISC アセンブラ
0597デフォルトの名無しさん2008/10/02(木) 22:47:22
>>596
ARMケータイはどうするの？
0598デフォルトの名無しさん2008/10/02(木) 23:02:03
要するに組み込みのハードのパワーがまだまだ貧弱なのがいかんのだろう。
あと１０年もすれば組み込みのハードもパワーが有り余ってC言語が要らなくなるんじゃない？
0599デフォルトの名無しさん2008/10/02(木) 23:16:40
パワー関係ないだろ
今時のマシンだろうがbootstrapのコードはasmじゃないと書けないし
kernelのコアのコードがメモリも弄繰り回せないようでは話にならない
Cのような機能を持った言語は要るんだよ
Cである必要は無いけれども
0600デフォルトの名無しさん2008/10/02(木) 23:20:20
ハードの性能とか一切関係ないよ
実用性という点においてCを超える言語が存在しないだけ
過去を考慮せず、これからのハードに的を絞っても
Cより先に処理系を用意し続けるのって不可能に近いよ
それが出来なきゃ駆逐なんて夢物語
0601デフォルトの名無しさん2008/10/02(木) 23:35:34
>>584
Ｃ＋＋
0602デフォルトの名無しさん2008/10/02(木) 23:36:03
Cがアセンブリを駆逐したという伝説がひとり歩きしているね
実際にはCがアセンブリと連携しやすかった所がポイントなのに
0603デフォルトの名無しさん2008/10/02(木) 23:44:28
そういや、アセンブリは非常に低水準だけど、それでも大抵のハードでスタックは装備されてるんだよな。
もっといろんな概念がハードに採用されてもよさそうだけど、あんまりそうはならないね。
それだけスタックがプログラムにとって本質的ってことかな。
0604デフォルトの名無しさん2008/10/02(木) 23:48:31
と思ったけど、よく考えたらハード的に特別スタックを用意してるわけじゃないんだっけ？
スタックポインタなんてなんて名前のレジスタがあるからてっきり、ハード的にスタックがあるんだと思っちゃったけど。

0605デフォルトの名無しさん2008/10/02(木) 23:56:03
でもただのjumpやmoveではない、push/pop/call/retがあるあたり
命令面では特別視されている感じがする。
0606デフォルトの名無しさん2008/10/03(金) 00:18:46
RISC ではそういう命令あんまりないんじゃない。
0607デフォルトの名無しさん2008/10/03(金) 00:22:39
>>606
まじで？
具体的なCPUの名前教えて。

0608デフォルトの名無しさん2008/10/03(金) 00:27:41
R3000なんかはそうでしたね
スタック操作も全部アセンブラでした
0609デフォルトの名無しさん2008/10/03(金) 01:16:05
>>605 それマクロよ
0610デフォルトの名無しさん2008/10/03(金) 07:58:45
いやマクロ違うだろ
0611デフォルトの名無しさん2008/10/03(金) 12:11:43
x86 は Pentium Pro 以降ハードウェアで x86 命令をマイクロ命令に変換してる。
0612デフォルトの名無しさん2008/10/03(金) 12:41:48
でもx86のIntelではPentium-Mまで、AMDに至ってはPhenomに
至るまでスタックポインタをALUで操作していたから遅かったね。
これらのCPU以降ようやくスタック操作が速くなった。

まあCALL自体は少ないとしてもPUSH/POPはレジスタの少なさ
ゆえ避けられないからな。
0613デフォルトの名無しさん2008/10/07(火) 19:12:12
C言語を駆逐するのにスタックが関係あんのか？
0614デフォルトの名無しさん2008/10/07(火) 19:25:37
大有りだろ
0615デフォルトの名無しさん2008/10/07(火) 19:57:34
>>614
詳しく
0616デフォルトの名無しさん2008/10/07(火) 20:38:17
スレの流れを見るに、Ｃはなんだかんだ言っても用途があるのでなくならない。
代替言語が仮にあったとしても、それがＣ言語を上回る訴求力が無い限り無理ぽ。
ただ、新しいハードが市場を埋め、それは既存と全く違う機械語が実装され、
そこで最初に提供された開発環境がＣ＋＋とかだったらＣは駆逐されるかもね。
0617デフォルトの名無しさん2008/10/07(火) 21:19:53
スタックに次ぐ、ハードウエアに追加するほどプログラミングに必須な機能といえば…
ガベコレとか？

0618デフォルトの名無しさん2008/10/07(火) 21:48:54
>616
C++がスーパーセットである以上、C++がCを駆逐することは不可能じゃないかな
その状況で例えばLispだけだったら可能性はあるかもね
0619デフォルトの名無しさん2008/10/07(火) 22:02:09
>>616
拡張子.cppの中身実質Cなコードが溢れるだけ。

って、コンパイラじゃなくて開発環境か。
APIがクラスとか例外とかを平気で使っている状況かな。
0620デフォルトの名無しさん2008/10/07(火) 22:15:19
ふと思ったんだが別にCを駆逐する必要なくね？
むしろ共通アセンブラとしてはベストじゃないか
0621デフォルトの名無しさん2008/10/07(火) 22:21:05
共通アセンブラとしてならな。
Cで、でかいアプリ組まされるなんていう無法がまかり通るからいかんのだ。
0622デフォルトの名無しさん2008/10/07(火) 22:21:54
>>621
それは言語の問題じゃないだろ
0623デフォルトの名無しさん2008/10/07(火) 22:24:34
じゃあ何の問題なんだよ。
0624デフォルトの名無しさん2008/10/07(火) 22:26:40
あんたの職場環境の問題
0625デフォルトの名無しさん2008/10/07(火) 22:29:39
きつい一言を…（TT）
0626デフォルトの名無しさん2008/10/07(火) 22:31:42
「でかい」の基準なんて分野毎に全く違う。
0627デフォルトの名無しさん2008/10/12(日) 20:46:48
Linuxをスクラッチから構成すると導入したい言語はたいていCかC++のコンパイルから始まるからこりゃ駆逐なんてできないやと思った。
0628デフォルトの名無しさん2008/10/12(日) 21:06:04
＞スクラッチから
……
0629デフォルトの名無しさん2008/10/12(日) 21:29:51
LFSか
0630デフォルトの名無しさん2008/10/23(木) 04:33:16
Hosh
0631デフォルトの名無しさん2008/11/06(木) 21:20:21
self = [[Object alloc] init];
0632デフォルトの名無しさん2008/11/08(土) 21:03:50
むしろランタイムがないと動かない言語が駆逐されるべき
ランタイムのバージョンやベンダーに依存して異常動作するなぞ論外
オブジェクト指向もいらね。
変数定義と関数定義はクラスで一体化するよりむしろ分けた方が
良いと思ってる。
0633デフォルトの名無しさん2008/11/08(土) 21:05:20
Cもランタイム無いと動かない環境あるだろ?
0634デフォルトの名無しさん2008/11/08(土) 21:25:02
あったとしても他の言語仕様が膨大な言語にくらべれば互換性は
高いはずだと思われ。

0635デフォルトの名無しさん2008/11/08(土) 21:27:12
glibcみたいのはランタイムとは言わないのかな?
よく知らんけど。
0636デフォルトの名無しさん2008/11/08(土) 21:29:12
POSIXのシステムコールなんて、ランタイムもいいところじゃないか。
0637デフォルトの名無しさん2008/11/08(土) 21:30:53
つまりLispOSが最強ということか…
0638デフォルトの名無しさん2008/11/08(土) 21:40:20
PCが機械語で動くかぎり、もっと言えばPCがメモリとCPUでできている限り、
Cが無くなることはないであろうと予言しておく。
0639デフォルトの名無しさん2008/11/08(土) 21:43:43
その予言は>>28で既出
0640デフォルトの名無しさん2008/11/08(土) 21:47:24
ガイシュツですたか。まあそれだけCは偉大な発明だったわけだ。
0641デフォルトの名無しさん2008/11/09(日) 01:32:12
Cが、特出すべき素晴しい言語だとは思わない
突然変異的なパラダイムは何一つ無いんだから
ただ、それを記述する為に生まれたUNIXが純然たる地位を保っていることこそ
Cが現在の地位を保持しているのでは無いかと思う
Windowsですら、その呪縛からは逃れられてはいない
0642デフォルトの名無しさん2008/11/09(日) 07:57:28
全然違う話で悪いんだが
UNIXは素晴らしいがCは素晴らしくないと言う人間をどう思う？
0643デフォルトの名無しさん2008/11/09(日) 08:25:15
ファシスト。
0644デフォルトの名無しさん2008/11/09(日) 12:33:58
Cの駄目な点は文字列の扱い。
char型の配列を操作するのはとにかく面倒なので改良型Cが欲しいところ。
0645デフォルトの名無しさん2008/11/09(日) 14:06:39
Cの改良は何度も失敗してる。
全然関係ないけど、LuaみたいなのをベターCと見なせるなら、もしかするかもね。
0646デフォルトの名無しさん2008/11/09(日) 20:53:07
ポインタの演算禁止とか、malloc()禁止とか、そういうコーディングルールを使ってるところは
Pascalとかでいいじゃんって思うけど、そういうレベルの人たちって、ちょっと違ってると、もう使えなくなるしな。
0647デフォルトの名無しさん2008/11/09(日) 21:53:49
for文とかwhile文でbreak禁止とかストレスたまって仕方ない。
0648デフォルトの名無しさん2008/11/09(日) 22:02:05
Cは覚えることが少ないから初心者向きだと思っていたが、Schemeを覚えて考えが変わった。
Cなんていらないや。
0649デフォルトの名無しさん2008/11/10(月) 01:09:03
今のlisperにとってCは闇米のようなものだ
0650デフォルトの名無しさん2008/11/12(水) 15:06:44
>>634
glibcのバージョン変わると起動しなくなるのが高い互換性？
0651デフォルトの名無しさん2008/11/13(木) 11:46:34
動的リンクとCの言語仕様は関係無いな
0652デフォルトの名無しさん2008/11/13(木) 15:17:39
>>650
それって窓で言えば
kernel32.dllやuser32.dllを別のに差し替えるようなものだぞ
0653デフォルトの名無しさん2008/11/14(金) 20:47:19
Cが嫌いなら無視してればいいのに
おバカさん向けのお上品な言語が他にたくさんあるわけだし
0654デフォルトの名無しさん2008/11/14(金) 21:55:54
>>653
>>4
0655デフォルトの名無しさん2008/11/14(金) 22:17:59
逆にさらにアセンブラよりな「cフラット」をつくるべきだな
0656デフォルトの名無しさん2008/11/14(金) 22:48:56
Cの歴史を考えるとOSを同時に作ることが必須なんじゃないか？
OSｲｲ!→ｲｲOSを作れる言語使う
CだけでなくUNIXも同時に駆逐しなければ無理だと思う
0657デフォルトの名無しさん2008/11/14(金) 22:49:41
ていうかさ。

もっと強烈凶悪なプリプロセッサがCに追加されたら、Cを駆逐しようなんて意見はなくなると思うな。
0658デフォルトの名無しさん2008/11/14(金) 23:06:41
テンプレートのことか？


0659デフォルトの名無しさん2008/11/14(金) 23:19:13
テンプレートも欲しいし、
いくつか追加して欲しい演算子もあるな。

でも、それができたらきっとCで満足してしまいそうな俺が居る。
0660デフォルトの名無しさん2008/11/15(土) 01:20:50
C++の機能を適度に導入するのは賛成
というか実際そういう方向へむかってますね
0661デフォルトの名無しさん2008/11/15(土) 08:46:32
効率は重要だけどCの低レベルさは嫌いとか、そんな都合いい話あるわけないじゃん
それが理解できないやつがC駆逐とかポストC言語に期待とか幻想抱くんだろうな
0662デフォルトの名無しさん2008/11/15(土) 15:32:56
Pascalとか昔の構造化BASICくらいのレベルなら、いまの最適化技術なら、Cと変わらないコードができるよ。
0663デフォルトの名無しさん2008/11/15(土) 17:20:30
>>662
pascal はね、共用体が変だし、; をかく場所も理屈っぽいし、なによりも、おなじことを書くのにc の倍のタイプ量になるのもやだし。
basic? 論外。
0664デフォルトの名無しさん2008/11/19(水) 21:48:41
C言語を使っている組織・人間に対し武力介入を行う
0665デフォルトの名無しさん2008/11/20(木) 03:23:34
>>664
ネット潰すのより難しそうだな
0666デフォルトの名無しさん2008/11/20(木) 10:48:11
暗黙の型変換などを排除したstrictCが欲しい
0667デフォルトの名無しさん2008/11/22(土) 23:36:47
色んなハード向けのコンパイラ屋がいる限り、
やっぱり駆逐されることはまず無いだろうね。

言語機能を機械語に置き換える量が最小元。
・新たなハードが出ても直す所はちょこっと

しかも、冗長さが無いのでパースが楽。
・クラス構文なんか付加されるだけでも割とダルい

ランタイムライブラリが殆どない
・ハード構成に合わせGCなんかを作るのは手間

単純でいて、OSが作れるほど実用的。
・lispなどもっと単純な言語もあるがハードには不向き

これを越える言語がないとなぁ。
0668デフォルトの名無しさん2008/11/25(火) 00:54:20
Cって
遅い(実行速度じゃなくて開発の早さ)
高い(スキルのある人を探すと)
低機能(高級でないという意味で)
だけど早い安い高機能に負けないのは汎用性が他の追従を許さないからでは
高機能と汎用性って相反してる気がするからCは生き残るんじゃないかな
真っ白なノートと塗り絵のノートの違いみたいな
なんて素人なりに考えてみました
0669デフォルトの名無しさん2008/11/25(火) 15:23:23
Cコードを吐く特定の言語の)コンパイラがあればすべて解決だろ？
C++(cfront)が失敗だろうが他の{実装|言語}でトライすればいいだろｊｋ
0670デフォルトの名無しさん2008/11/25(火) 17:40:29
>>669
　最適化の邪魔になる構文と、人間のための構文を仕様から
除去しないと難しいな。そうなると、最早Cでは無いが。
因みに、GCCの中間コードには近い物が有り、実用化されてるけどね。
0671デフォルトの名無しさん2009/01/25(日) 05:39:19
移植性の問題はコンパイラじゃなくてジェネレータにすればかなり解決するんじゃないか？
というか、昔のC++しかりCのコードを吐くジェネレータは多そうだけど、実際どうなの
0672デフォルトの名無しさん2009/01/25(日) 08:09:17
とりあえずガベコレ搭載したObjective-C 2.0でいいんじゃないか？
0673デフォルトの名無しさん2009/01/25(日) 10:42:01
おまえらがC言語以外の言語で素晴しいソフトをどんどん作ればいいのさ
0674デフォルトの名無しさん2009/01/25(日) 10:42:42
色んな思想があるから、色々と（微妙な）亜種が登場して
なんだかんだで C が生き残る
0675デフォルトの名無しさん2009/01/25(日) 12:13:48
Dだろ
0676デフォルトの名無しさん2009/01/25(日) 12:39:49
>>675
じゃあDで頑張って駆逐してください
0677デフォルトの名無しさん2009/01/26(月) 01:47:32
Dとか最速消滅候補だろｗｗｗ
0678デフォルトの名無しさん2009/01/26(月) 09:49:56
なんだかんだいってＣでつくっちゃうよな
確かにオブジェクトシステムとガベコレがないのは痛いが
あとインラインアセンブラはＤのほうがいい
0679デフォルトの名無しさん2009/01/26(月) 22:13:12
しかしDよりはCのほうがいい。
0680デフォルトの名無しさん2009/01/26(月) 23:18:56
Java、D、C#とかの構文よりもCの構文のほうが綺麗だと思う
もしCにGCとか無名関数があるとしたら、絶対Cを使うね

#オブジェクト指向なんて飾りです。えろい人にはそれがわからんのです
0681デフォルトの名無しさん2009/01/26(月) 23:22:30
Boehm GCでも使えばいいじゃん
0682デフォルトの名無しさん2009/01/27(火) 00:04:03
>>681
ｽﾏﾝ。言いたかったことがかなりずれてた
君たちはCとJava、D、（ｒｙだったら、どの構文がすきなのさ？
0683デフォルトの名無しさん2009/01/27(火) 01:28:02
scheme
0684デフォルトの名無しさん2009/01/27(火) 01:41:37
なんだ、ナンバーサインの人か
0685デフォルトの名無しさん2009/01/27(火) 07:45:12
私じゃないよ。
# ←ここに空白を入れる人と入れない人がいる。
0686デフォルトの名無しさん2009/01/28(水) 00:15:01
>>682
RPN
0687デフォルトの名無しさん2009/01/28(水) 07:15:28
>>680
自分は別に構文に関しては気にならないけど、
Java とか C# でどこら辺が汚いっすか？
0688デフォルトの名無しさん2009/01/28(水) 09:13:17
>>687
まぁ言語自体がどうこうと言うより、
使ってる奴の頭が汚染されてるんだよね。特にJavaはｗ
0689デフォルトの名無しさん2009/01/28(水) 12:44:04
>>687
Javaの構文のうざさは異常
もうちょっと簡潔に書ければ文句ないんだが
0690デフォルトの名無しさん2009/01/28(水) 16:52:10
>>1人類を駆逐すればC言語を完全に駆逐できますよ
0691デフォルトの名無しさん2009/01/30(金) 01:23:27
だれかはやくネイティブ吐けるC#コンパイラつくってくだしあ
0692デフォルトの名無しさん2009/01/30(金) 08:04:59
CLIのバイトコードを直接実行できるCPUがあると便利かなあ。
0693デフォルトの名無しさん2009/01/30(金) 08:57:59
>>691

その発言の%s/C#/java/ してごらん
0694デフォルトの名無しさん2009/01/30(金) 22:55:28
gjcがどうしたって？
0695デフォルトの名無しさん2009/01/30(金) 23:05:01
Cの嫌いなところは標準ライブラリが貧相なこと
そして昔、C言語はライブラリが充実していて移植性が高いと吹聴していた
影響でC言語で書けばワンチップマイコンからスーパーコンピュータまで
どんなプログラムでも動くと勘違いするお客さんの多いこと･ﾟ･(ﾉД`)･ﾟ･
06966952009/01/30(金) 23:07:16
誤）どんなプログラムでも動くと勘違いするお客さんの多いこと
正）どんなプログラムも無修正で動くと勘違いしているお客さんの多いこと
0697デフォルトの名無しさん2009/01/31(土) 02:05:33
でも実際のところ、ポータビリティでCより勝る言語って無いでしょ？
0698デフォルトの名無しさん2009/01/31(土) 04:37:30
わざわざCの構文に似せた言語を作るのやめてくれ。
要らない記号だらけで読みにくいんだよ。
0699デフォルトの名無しさん2009/01/31(土) 09:17:22
俺はもっと記号を増やすべきだと思うんだが。
それともlisp見たいのがいいのか？

0700デフォルトの名無しさん2009/01/31(土) 09:34:01
Lispが理想なんだが、多くの人はC風のが読みやすいのかな？
0701デフォルトの名無しさん2009/01/31(土) 09:55:39
慣れだろ
0702デフォルトの名無しさん2009/02/01(日) 00:10:10
チューリングマシーン！！！
0703デフォルトの名無しさん2009/02/01(日) 01:04:39
Cなんて組み込みでしか使われんだろ？
駆逐されたも同然じゃん
0704デフォルトの名無しさん2009/02/01(日) 01:17:36
君の住んでる世界でCが使われてないだけです
0705デフォルトの名無しさん2009/02/01(日) 06:54:34
>>703
それじゃ駆逐されたとは言えん
このスレの目指す先はCの完全消滅だ
0706デフォルトの名無しさん2009/02/01(日) 11:48:12
そういう意味ではＣを消滅させられる可能性があるのはＤだったけど・・
0707デフォルトの名無しさん2009/02/01(日) 14:25:09
>>698
つCOBOL
0708デフォルトの名無しさん2009/02/02(月) 12:20:20
アルマゲドンで爆破が成功せずに地球に落ちたらCの完全消滅完了
0709デフォルトの名無しさん2009/02/04(水) 22:11:35
オブジェクト指向以前の世代の言語としての完成形がCだから。
C++, C#, Java とかこの辺はみんなCの子供達であって、内部にCを持っているようなもの。
そういう意味ではCを駆逐することはできないだろう。

CのライバルはPascalとかであって、現代のひ弱な息子達ではないのだ。
0710デフォルトの名無しさん2009/02/04(水) 22:36:27
Pascalこそ完全駆逐された言語だろが
0711デフォルトの名無しさん2009/02/04(水) 23:06:25
Pascalの記述法（BEGINとかENDとか）は現在でもC系と勢力を二分しておる。
今でもCとPascalの代理戦争は続いてるんだ。
0712デフォルトの名無しさん2009/02/04(水) 23:15:16
なつかしいな

#define BEGIN {
#define END }
0713デフォルトの名無しさん2009/02/04(水) 23:27:11
C#はCの姿を借りたPascalの末裔だと思うが
0714デフォルトの名無しさん2009/02/04(水) 23:30:26
PascalはDelphiの心の中で今も眠っています。
0715デフォルトの名無しさん2009/02/04(水) 23:36:41
行儀良くプログラムが書けるという意味ではpythonがPascalの正当な継承者かもね
0716デフォルトの名無しさん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;
}

こんな毎日、無限ループって怖いよな；；


0717マイク ◆gZ6OoOjBU6 2009/02/05(木) 06:32:58
努力せずCという言語に依存し続ける無能な年寄りは無能な若者は確かにいらないと思う。
だがCはCで高級アセンブラ的側面を残している。
C++のような面倒なオブジェクト指向要素を排除してだ。
だからCは衰えはするけれども無くなることは無いだろう。
だって仕事しながら普通に家庭を持って家族を養って普通に生活する為には
いつまでも限りの無いコンピュータオタクで居続ける
コンピュータオタクとして努力しつづけることは不可能だもの。
俺のこの分析は間違いないだろう。
0718マイク ◆gZ6OoOjBU6 2009/02/05(木) 06:33:50
無能な年寄りや無能な若者。
0719デフォルトの名無しさん2009/02/05(木) 08:28:55
Fortranは勝ち組だな
0720デフォルトの名無しさん2009/02/05(木) 09:16:49
C+　ぐらいのを作ればいいんだよ。
0721デフォルトの名無しさん2009/02/05(木) 09:19:54
久しぶりだな、糞ｺﾃ。もう来るなよ。
0722マイク ◆gZ6OoOjBU6 2009/02/05(木) 17:41:03
俺が思うに
ダンゴリオンというかコテはそれなりに優秀だと思うが
>>721お前のような口だけの名無しはたいした事無いよ。
0723デフォルトの名無しさん2009/02/05(木) 18:13:35
と糞コテが申しております
0724デフォルトの名無しさん2009/02/05(木) 19:36:53
口だけの糞コテ
0725マイク ◆gZ6OoOjBU6 2009/02/06(金) 07:41:07
口だけって言われても・・・
お前も口だけの糞名無しじゃん。
0726デフォルトの名無しさん2009/02/06(金) 08:11:37
Cは使ってないけど駆逐する必要を感じない。
0727デフォルトの名無しさん2009/02/06(金) 08:24:22
ＣがいらないとかｗｗｗＣがこんだけ普及したのはなぜだろうねえ
良く考えればわかりそうなもんだが
0728マイク ◆gZ6OoOjBU6 2009/02/06(金) 09:18:44
>>727
シンプルで使いやすい
高級アセンブラっぽくてアセンブラより便利
構造化プログラミング言語としてまあ成功してる
と言う感じじゃね
0729デフォルトの名無しさん2009/02/06(金) 13:51:12
コンピューター史において普及した確実な理由なんてのはないと思うがなぁ
Cと*nixが普及した理由より、Lispマシンなどのその他が
主流であり続けられなかった理由を考えた方が興味深いかもしれん
0730デフォルトの名無しさん2009/02/06(金) 13:59:48
少なくとも、多くのプロセッサが8bit (せいぜい16bit) だった時代には
処理系の作り易さ、実用性、可搬性、作られたプログラムの軽さで
C以外に主役になれる言語なんかなかったからな。
0731デフォルトの名無しさん2009/02/06(金) 14:08:32
worse is better

正しさと単純さのトレードオフ
0732デフォルトの名無しさん2009/02/06(金) 14:11:32
Worse is worse
http://www.kt.rim.or.jp/~hisashim/waldo/worseisworse.ja.html
0733デフォルトの名無しさん2009/02/06(金) 14:20:52
ここで >>448 にもどる
0734デフォルトの名無しさん2009/02/07(土) 21:16:48
１．Cより、より簡単な文法である。
２．GCはない。
３．Cよりもアセンブラ的なことができる。
４．マクロがCよりより現代的だ。
５．型推論があったりする。
６．C言語より安全だ。

コンパイラの性能としては昔に比べると、
コンパイルスピードはおいて置いて、メモリは食ってもいいのではないかと。

とかいう言語があればいいんじゃないかと。
0735デフォルトの名無しさん2009/02/07(土) 21:38:18
つまりD言語からGCを取っ払えと
0736デフォルトの名無しさん2009/02/07(土) 22:35:26
もうアセンブラでいいじゃん
0737デフォルトの名無しさん2009/02/08(日) 06:22:53
これからの時代、C++は避けても大丈夫？
そりゃ会社で使うように指示されてるなら避けられないけど、趣味の範囲でとしたら。
Cはやっとくべきかなとは感じてるけど、C++はやだなあ。
0738デフォルトの名無しさん2009/02/08(日) 10:25:35
>>737
> 趣味の範囲で
趣味なんて十人十色なので、これだけじゃ回答のしようがないな。
「何をやりたいか」をはっきり言ってくれんと。
0739デフォルトの名無しさん2009/02/08(日) 12:50:59
>>737
趣味でやるならC++なんか逆に面白いのかもしれんぞ
0740デフォルトの名無しさん2009/02/08(日) 12:54:01
趣味でやるなら C++0x
0741デフォルトの名無しさん2009/02/08(日) 13:13:29
配列とかメモりブロックがサイズ情報さえ持ってればなあ。
0742デフォルトの名無しさん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
0743デフォルトの名無しさん2009/02/08(日) 20:42:45
>>742
そういう話じゃないだろ
c99だと動的に長さ与えてもsizeofで長さが取れるし
int len=10;
int arr[len];


mallocしてヒープから取った場合の話だろ
0744デフォルトの名無しさん2009/02/08(日) 23:02:07
それは配列とは言わんだろ
07457422009/02/08(日) 23:17:38
>>741
>>743
ヒープからメモリ確保するたびに自動でどっか変数に
確保したサイズを保存するとなるとオーバーヘッドになるから、
C言語の今の仕組みの代替にはならんのではと思う。

おとなしくstd::vectorか自前関数作るのが良いと思う。
0746デフォルトの名無しさん2009/02/09(月) 11:29:32
>>745
>変数に
>確保したサイズを保存するとなると
ヒープの管理上、ほぼ例外なく持ってる筈なんで
それを取得する手段が標準化されれば済む話じゃね？
0747デフォルトの名無しさん2009/02/09(月) 11:52:52
例外ありまくりです
50バイト必要なときに64バイト確保した場合
50という数字はどこにも記録されないなど
0748デフォルトの名無しさん2009/02/09(月) 12:02:30
成程。
では保存するようにすればよいではないか。
0749デフォルトの名無しさん2009/02/09(月) 12:07:45
共通アセンブラとしての役割なら C より LLVM IR のほうがいいんじゃない？
0750デフォルトの名無しさん2009/02/09(月) 12:47:51
>>746
ヒープの管理領域から得られるサイズは要求したサイズと必ずしも一致するわけでは無いので、別にサイズを保存しなければならない。
いろんな理由で要求サイズより大きくなる場合がある。
0751デフォルトの名無しさん2009/02/10(火) 03:04:40
>>748
オーバーヘッドになるから組み込みの人たちには嫌がられるだろうねー。俺も嫌だ。
でも需要があるのでサイズ保存するようにしたのがC++のvector
0752デフォルトの名無しさん2009/02/10(火) 11:38:11
>>751
>オーバーヘッドになるから
速度的には malloc/free のとき以外に影響はないわけだが。
その程度が気になるほど何度も割り当てと解放を繰り返してるなら
そっちの方がよっぽど問題。

>C++のvector
違。
0753デフォルトの名無しさん2009/02/10(火) 14:17:40
で、
int n[10], *p = n + 3;
とした時、pのサイズはどういうカラクリで取得すればいいんだよ。
0754デフォルトの名無しさん2009/02/10(火) 14:24:11
ヒープの話してたんじゃないのか？
0755デフォルトの名無しさん2009/02/10(火) 14:30:12
printsize(void *p){
　printf("%d\n", sizeof(*p));
}
でサイズとれなきゃ意味なさすぎ。
autoだろうとstaticだろうとヒープだろうと区別なくメモリの塊として
ポインタでこねくり回すのがCのコンセプトなんだからな。

ヒープのサイズ知りたいだけなら現状でもヘッダ覗けば取れるだろ。
完全に環境依存になるが。
0756デフォルトの名無しさん2009/02/10(火) 14:39:05
言いたいことは、わかったから、もう一度仕様を読んできてください。

GCCのglibcなら、malloc.hのmalloc_usable_size()とかだったかなで、
malloc()で確保されたバイト数がわかるはず。

それが嫌なら、自分で構造体を利用して俺様ポインタでも作れば良い。

いい加減スレ違い以上
0757デフォルトの名無しさん2009/02/10(火) 14:47:12
ヒープ使えるようなシステムならわざわざCを使ったりしない。
他の言語使う
0758デフォルトの名無しさん2009/02/10(火) 16:50:11
>>734
テンプレートほど強力じゃなくてもいいから総称型とオーバーロードがあると
型推論が活躍すると思います。あとC++よりも見やすいABI。

それと、インラインアセンブラで生成したコードをchar配列に突っ込んで書き換えやすくする機能
(xbyakみたいなの)欲しい
0759デフォルトの名無しさん2009/02/10(火) 17:02:04
Cに対する改善案は数あれど本当にそれがパフォーマンスを低下させることなく
生産性を引き上げるのかといわれると微妙なのばっかりなんだよな。
大半がオナニーシンタックスシュガーにとどまってるものばかり。
膨大な数のコンパイラに対してアップデートを強要する動機づけとしてはあまりにも弱い。
Cの進化がかなり保守的なのもわかる気がするよ。
0760デフォルトの名無しさん2009/02/10(火) 17:30:25
>>758
>インラインアセンブラで生成したコードをchar配列に突っ込んで書き換え
ウィルス作るんですね？
0761デフォルトの名無しさん2009/02/10(火) 18:06:50
いいえJITです
07627582009/02/11(水) 01:39:42
>>760
その発想はなかった.......orz
0763デフォルトの名無しさん2009/02/11(水) 10:08:16
このスレももうすぐ駆逐されそうですね
0764デフォルトの名無しさん2009/02/11(水) 10:15:32
C駆除厨が完全に駆除されたわけか
Cは向こう100年は安泰だな
0765デフォルトの名無しさん2009/02/11(水) 10:51:44
C駆除厨の心境「ハードウェアの革新的飛躍に期待」
0766デフォルトの名無しさん2009/02/11(水) 16:11:03
>>765
FPGAベースで、ほとんどの言語を駆逐するあれか!!
0767デフォルトの名無しさん2009/02/12(木) 01:42:44
いや、壊れると腐ってハエがたかるあれじゃないかな
0768デフォルトの名無しさん2009/02/12(木) 03:15:13
FPGAはまずクソ環境をなんとかすべき
Xilinxとかやる気をそがれる
0769デフォルトの名無しさん2009/02/14(土) 20:59:24
>>757
>ヒープ使えるようなシステムならわざわざCを使ったりしない。
>他の言語使う

ハァ？テメエ、ヒープの意味すらわかってねーだろバカタレ
0770デフォルトの名無しさん2009/02/14(土) 21:08:59
OS乗ってなかったらヒープもないんじゃね？
0771デフォルトの名無しさん2009/02/14(土) 21:09:31
s/ないんじゃね/ないじゃん/
0772デフォルトの名無しさん2009/02/14(土) 21:57:59
>>770
>OS乗ってなかったらヒープもないんじゃね？

お前もわかってない。
ヒープ以前にスタックの意味がわかってない
0773デフォルトの名無しさん2009/02/14(土) 22:31:17
>>772
ん、誤解があったかな？

スタックはOS無くてもコンパイラが作ってくれるけど、
ヒープ（mallocとか）は自分で書かないと使えないじゃないすか。
0774デフォルトの名無しさん2009/02/14(土) 22:39:49
cellのspeを生で使おうとしてたとき、普通にヒープなんてなかったぜ
0775デフォルトの名無しさん2009/02/14(土) 22:43:10
最近まで、「プログラムしね。C言語うんこめ」なんて思っていたけど、
いろいろ調べてみたり、打ってみて、プログラミングに熱くなる人の気持ちが分かる気してきた。
Cを取り合えず頑張ってみる宣言
0776デフォルトの名無しさん2009/02/14(土) 23:52:50
スレタイくらい読めよｗ
0777デフォルトの名無しさん2009/02/15(日) 01:17:42
C 並みに低レベルなコードだけが書けて、かつもっと安全な言語仕様(型とか)の
言語が出てくれば、自然と移り変わっていくんじゃねーかなーと思った。
0778デフォルトの名無しさん2009/02/15(日) 01:28:26
>>777
それだけ聞くとC++のようだ。
0779デフォルトの名無しさん2009/02/15(日) 01:31:40
まぁ現に組み込み業界とか徐々にC++に移り変わってるけどな
0780デフォルトの名無しさん2009/02/15(日) 01:58:47
詰め込みで肥大化？
0781デフォルトの名無しさん2009/02/15(日) 02:16:03
templateの無いC++ほしい
0782デフォルトの名無しさん2009/02/15(日) 08:49:25
それじゃ何の役にも建たない
0783デフォルトの名無しさん2009/02/15(日) 11:17:51
>>778
平たく言えば、c++ からオブジェクト指向の概念やらの、より高度な仕様を抜いた感じ。
0784デフォルトの名無しさん2009/02/15(日) 11:31:02
>>783
それ、 C++ に比べて何がいいの？
0785デフォルトの名無しさん2009/02/15(日) 11:38:50
>>784
単純。
0786デフォルトの名無しさん2009/02/15(日) 13:37:56
Ｃしかコンパイルしないコンパイラ探すほうが大変な昨今
ぶっちゃけおんなじ事をＣで書くのとＣ＋＋で書くのと
どっちがコード少なくやれるんだべ？
0787デフォルトの名無しさん2009/02/15(日) 13:46:34
>>744
>とかメモりブロックがサイズ持ってたらなぁ
配列限定の話じゃないみたいだが
mallocしたメモリブロックを配列と呼ぶ人は多いし(違いを理解していても)、そこは空気読むべきだったと思う
0788デフォルトの名無しさん2009/02/15(日) 22:34:20
>>786
余りにアバウトすぎてなんとも言えねぇｗｗｗｗ
0789デフォルトの名無しさん2009/02/15(日) 23:24:34
C++の方が大規模になればなるほどCに比べてコード量は少なくできる部分が
多くなると思うが、指数的に比例して頭を使う量が増えると思うｗ
0790デフォルトの名無しさん2009/02/16(月) 00:59:33
C++ってひとくくりに言うけど環境によって全然違うよね
CだったらC89くらいなら対応を期待できるが
C++は例外使えないとかありがち
0791デフォルトの名無しさん2009/02/16(月) 01:52:39
ねーよ。
0792デフォルトの名無しさん2009/02/16(月) 07:52:41
Embedded C++ と C++は別もんだろう
0793デフォルトの名無しさん2009/02/16(月) 19:50:27
>>792
どうしたww
いきなりww
0794デフォルトの名無しさん2009/02/17(火) 11:45:36
おまえらもよく知ってるアホみたいに売れてる携帯ゲーム機は例外使えないよ

それとプロジェクトで例外禁止はものすごくよくあるだろ
0795デフォルトの名無しさん2009/02/17(火) 13:14:36
>>794
>それとプロジェクトで例外禁止はものすごくよくあるだろ
流石のウチも、そこまで間抜けはいない。
0796デフォルトの名無しさん2009/02/17(火) 23:06:37
googleのC++のコーディング規約は例外禁止だったな。
0797デフォルトの名無しさん2009/02/18(水) 02:39:33
任○堂もソ○ー（PS3以前）も例外禁止
mozillaも例外禁止
BREWも例外禁止
確かによくあることだなｗ
0798デフォルトの名無しさん2009/02/18(水) 09:26:51
google: 既存コードが例外を考慮していないから。
ゲーム屋: 知らん。なんで？
mozilla: 実装していない処理系で利用できなくなるから。
BREW: うんこだから。
>>794: よく解らないから。
0799デフォルトの名無しさん2009/02/18(水) 12:39:21
mozilla を除いて例外がモジュールの境界をまたがないルールにすれば使っても問題ないんじゃない？
0800デフォルトの名無しさん2009/02/18(水) 18:43:28
そんなルールあってないようなものだから危険すぎるだろ
0801デフォルトの名無しさん2009/02/18(水) 21:55:10
Googleだったら、速度重視するのに邪魔だったという理由が
付加されていても不思議に思わない。
高級さが欲しければPythonでも使っていろってことで。
0802デフォルトの名無しさん2009/02/18(水) 22:24:56
たしか VC と GCC4 は try ブロックの出入りと throw したとき以外は例外による実行
コストは 0 だったような気がする。
コンパイラが悪いと例外を使っていなくても関数の出入りで負荷がかかるかもしれない。
0803デフォルトの名無しさん2009/02/18(水) 23:09:59
他のスレでもそうだけど、何でC++厨って
C++スレでもないのにスレ違いな事を長々と書きこむの？
0804デフォルトの名無しさん2009/02/19(木) 00:11:35
>>803
お前がいらいらする様をみたいから
0805デフォルトの名無しさん2009/02/19(木) 15:07:54
他のスレでもそうだけど、何で
　　「他のスレでもそうだけど、何で××厨って
　　　△△スレでもないのにスレ違いな事を長々と書きこむの？」
みたいな事を言う奴って
スレに沿った話題も提供せず文句ばっか書き込むの？
0806デフォルトの名無しさん2009/02/19(木) 16:15:33
これは自己参照レスか
0807デフォルトの名無しさん2009/02/19(木) 22:34:02
BitC って言語がある。コンセプトはなかなかよさげ。
まだまだ alpha 版って感じだけど。

ttp://www.bitc-lang.org/

トップページと言語仕様の最初のほうだけをざっと
見ると、
* 型推論
* 値としての関数(型安全)
あたりを C に取りこんだって感じ？シンタックス
今んとこ、便利だからっていう理由(パースしやすい
とかそういう理由かな) で Scheme ライクなものを
選択してるみたい。
0808デフォルトの名無しさん2009/02/19(木) 23:19:02
ゲームに関しては例外発生した時点で製品品質がアウトだし復帰できるような
処理でもないからだな。

処理が失敗して巻き戻るとかゲームじゃ許されねぇ。
0809デフォルトの名無しさん2009/02/19(木) 23:31:29
これまでの言語に毛の生えた程度の新しい言語じゃ、
少しばかり文法や使い勝手が向上しても誰も見向きもしないよ。
誰がわざわざそんな言語覚えようとするんだい？

そして、C++, Java, C#, VB などが生き残ってるのは何故か考えてみよう。
言語の存在価値があるのは、言語類型やアーキテクチャが全く別物か、
そもそも根本的に違う言語であるかの時でしかない。
0810デフォルトの名無しさん2009/02/20(金) 02:21:41
趣味で　C でニンテンドーDSの開発やってて
少し規模が大きくなると、綺麗に管理したくなってきて
クラス使ってインスタンスを操作する流れにしたくなっちゃうんだけど
自分はオブジェクト指向言語に毒されてるんかなぁ
組み込みの分野では C の言語仕様で十分なんすか？
0811デフォルトの名無しさん2009/02/20(金) 09:59:20
型に執着して派生型とか汎用型とか共変とか反変とか
芋蔓式に出てくる今現在のオブジェクト指向 が 毒されている感はある
0812デフォルトの名無しさん2009/02/20(金) 11:19:26
>>808
品質（笑）
雑魚ゲーム屋のエラー処理なんて
無限リトライか停止しかないだろｗ

>>810
速度やリソースとの兼ね合い。
0813デフォルトの名無しさん2009/02/20(金) 11:55:51
>>808
みんながこういう認識なら例外禁止にしたほうがいいかも。
0814デフォルトの名無しさん2009/02/20(金) 12:26:21
例外禁止にしても例外処理が要らないわけじゃないんだけどな。
0815デフォルトの名無しさん2009/02/20(金) 13:18:10
>>808
ディスク、ネットワーク、バックアップメディアなどの処理ではエラーから復帰しないと
だめだろう。
0816デフォルトの名無しさん2009/02/20(金) 16:03:46
ハングするゲームちょくちょくあるよなｗ
0817デフォルトの名無しさん2009/02/22(日) 17:13:04
ゲームの世界だと例外を適切に処理しないことよりプログラムが停止することの
方がリスキーという認識なのかな。

その結果想定外の状態が発生したとしても貴重なデータが破壊されたり
人が死んだりする致命症にはならないわけだし。
0818デフォルトの名無しさん2009/03/14(土) 22:22:19
ttp://www.jisc.go.jpでJISのC言語の規格の文書がタダで読めることを
C++のスレで知って読んでたら間違いを見つけました。
6.3.2.1の第２段落の最初の行の最後の「演算子」は「.演算子」の誤り。
0819デフォルトの名無しさん2009/03/15(日) 01:32:51
例外、テンプレなしc++ってけっこう便利だと思うんだが。
0820デフォルトの名無しさん2009/03/15(日) 02:32:42
例外、テンプレありならもっと便利だよ。
0821デフォルトの名無しさん2009/03/15(日) 14:02:57
Cを駆逐するために登場したDがCより先に駆逐されたな
0822デフォルトの名無しさん2009/03/15(日) 16:44:33
駆逐されたというか誰にも相手をされずにひっそり孤独死したような感じ
0823デフォルトの名無しさん2009/03/15(日) 16:47:38
おまいら勝手に殺すなｗ
0824デフォルトの名無しさん2009/03/15(日) 16:49:26
まったくだ。まだ生まれてもいないだろ。
0825デフォルトの名無しさん2009/03/15(日) 18:34:18
流産だな
0826デフォルトの名無しさん2009/03/15(日) 18:36:58
堕胎したのか
0827デフォルトの名無しさん2009/03/16(月) 13:02:33
デストラクタで例外を投げるなとあれほど言ったのに…
0828デフォルトの名無しさん2009/03/16(月) 13:20:22
けへへ、以前納品したアプリ、CでC++のクラスっぽい実装してたんだけど
まさしくデストラクタっぽい後処理関数で例外を投げるに等しい処理をしていたことに今頃気付いた。
まぁ、アプリ終了時しかその関数に行かないし、終了するのは外部から殺されるときだからどうでもいいと言えばどうでもいいのだけれどw
0829デフォルトの名無しさん2009/03/16(月) 23:52:34
Cでクラスのまねごとしてるだけなら別に問題ない。
0830デフォルトの名無しさん2009/03/17(火) 00:00:22
「Cでオブジェクト指向プログラミングするテクニック」みたいのって幾度となく見てるけど、
カプセル化とか抽象データ型くらいまでまではいいけど、継承とか多態までいくと
「それムリがあるだろ」って感じになるな。マにうけるやつがいるから、ああいうの広めるの
やめてほしい。
0831デフォルトの名無しさん2009/03/17(火) 00:29:39
オブジェクト指向言語が裏でなにやってるかわかって勉強になるんじゃまいか？
実際に仕事でそうコーディングされたらたまらんが。
0832デフォルトの名無しさん2009/03/17(火) 00:39:19
>>830
多態って構造体のメンバに関数ポインタでも持たせておくのかな。
自分でやろうとは思わないけど、個人的には許容範囲。
0833デフォルトの名無しさん2009/03/17(火) 00:41:58
cでベクタグラフィックスベースのGUIツールキット作ったときは、
多態や継承だらけになるように設計したよ。
どのコントロールも基本的な動きはおなじで、かつ置換可能だったからね。
0834デフォルトの名無しさん2009/03/17(火) 11:52:34
ふざけて課題でやった事あるけど、それこそ仕事でそんな事やるぐらいならC++使えよｗ
0835デフォルトの名無しさん2009/03/17(火) 16:12:21
>>832
Xツールキットで派生クラス作るときは必須。
0836デフォルトの名無しさん2009/03/18(水) 03:15:58
そうかなあ
0837デフォルトの名無しさん2009/03/18(水) 21:11:14
Cを駆逐ってお前ら…
どう考えても、まずJavaを駆逐するべきだろ。
0838デフォルトの名無しさん2009/03/18(水) 22:29:34
>>837
無理して駆逐しなくても、そのうち自然消滅するだろう。
携帯を見れば分かるように、あんなもんエンドユーザにとって
何のメリットも無い。
0839デフォルトの名無しさん2009/03/18(水) 22:57:52
いま案件数でトップだから、完全消滅まで時間かかりそうですな
0840デフォルトの名無しさん2009/03/18(水) 23:35:36
Javaの価値ってJavaVMによるポータビリティと莫大なソフトウェア資産ってところ？
ほかには何かあったっけ？


0841デフォルトの名無しさん2009/03/19(木) 04:58:36
サンって身売り先探してるらしいじゃん
0842デフォルトの名無しさん2009/03/19(木) 08:00:55
JavaはIBMが駆逐しそうです。（＞＜）
0843デフォルトの名無しさん2009/03/20(金) 00:40:07
特急グリーン車をお望みならばこちらへ
http://www.microsoft.com/japan/msdn/vstudio/events/agileseminar.aspx
0844デフォルトの名無しさん2009/03/20(金) 00:48:14
C言語は2038年に自然消滅します
0845デフォルトの名無しさん2009/03/20(金) 09:22:48
>>844
もうとっくに対策済んどるわ
いつの時代の話してんだボケｗ
0846デフォルトの名無しさん2009/03/20(金) 19:00:01
>>845
そーでもないぞ。
(実際Linuxとか窓とかダメだろ)
0847デフォルトの名無しさん2009/03/20(金) 19:04:07
64bit化すれば自然に解決なんじゃね?
0848デフォルトの名無しさん2009/03/20(金) 19:41:49
C言語があるせいでPCの進化が妨げられてるよな
0849デフォルトの名無しさん2009/03/20(金) 20:55:11
>>846
とっくに済んでんじゃね？
0850デフォルトの名無しさん2009/03/20(金) 21:06:11
プラットフォームAPIが64bitで返せば、後はコンパイラのtime_tの扱いを変えるだけだからな。
問題はCよりVB6.0な気がする。去年も一本書いたし、何故か現役なんだよな。
0851デフォルトの名無しさん2009/03/21(土) 09:25:42
大丈夫。VBは言語じゃない。
0852デフォルトの名無しさん2009/03/21(土) 16:11:41
>>850
そんなもん現役で使うことが問題なんであって。
0853デフォルトの名無しさん2009/03/21(土) 16:35:19
VBもうやだ・・・
0854デフォルトの名無しさん2009/03/22(日) 19:54:09
VBｲﾗﾈ
0855デフォルトの名無しさん2009/03/22(日) 23:22:07
>>1
現実的な案としては、世界を核の炎で包め
0856デフォルトの名無しさん2009/03/25(水) 23:31:55
なにその末期患者を安楽死させるみたいな案は。
この世からC言語という病理だけ取り除けば全人類が幸せになれるだろ。

0857デフォルトの名無しさん2009/03/25(水) 23:33:47
てか、病理って何だ俺。
0858デフォルトの名無しさん2009/03/26(木) 14:39:24
Cの後に何を使うかってのをまず決めてもらわないと
0859デフォルトの名無しさん2009/03/27(金) 20:16:52
C++に決まってる。
C++こそ至高。
0860デフォルトの名無しさん2009/03/28(土) 03:10:20
禿同。C++の向かっている方向は素晴らしい。
これからも更なる高みを目指して羽ばたいて欲しい。
変態言語の王道楽土を築けるのはC++だけ。
0861デフォルトの名無しさん2009/03/28(土) 03:24:24
なに？C++が変態言語だと？
0862デフォルトの名無しさん2009/03/30(月) 12:01:52
おれ、テンプレートでノイローゼになって自殺するのが夢なんだ…
0863デフォルトの名無しさん2009/04/02(木) 17:25:16
Boost.MPLをはじめて知ったとき、余りにも理解できなくてノイローゼになりそうだった
0864デフォルトの名無しさん2009/04/16(木) 01:55:12
知らなくても使えるという理想郷でパンドラの箱をあけるんじゃない。
0865デフォルトの名無しさん2009/04/26(日) 21:50:40
箱開けないとコンパイルエラーとかデバッグの時に困るんだよ
0866デフォルトの名無しさん2009/04/27(月) 00:53:46
自前実装よりはノイローゼのがマシ
0867デフォルトの名無しさん2009/06/09(火) 16:50:19
ゴンドアの谷の歌にあるもの
土に根をおろし　風とともに生きよう
種とともに冬をこえ　鳥とともに春を歌おう
どんなに恐ろしい武器を持っても
沢山のかわいそうなロボットを操っても
土から離れては生きられないのよ！

↑を適宜改変して「C言語から離れては生きられないのよ！」にしてちょ
0868デフォルトの名無しさん2009/06/09(火) 18:53:52
AT&Tの谷の歌にあるもの
CPUに根をおろし　マシン語とともに生きよう
Eレジスタとともにメモリの壁をこえ　バイナリデバッガとともにインストラクションを歌おう
どんなに恐ろしいJITを持っても
沢山のかわいそうなVMを操っても
CPUから離れては生きられないのよ！
0869デフォルトの名無しさん2009/07/03(金) 21:02:20
C++0xを完全に流産させるためには

どうしたらいい？

0870デフォルトの名無しさん2009/07/03(金) 21:06:46
Dを布教
0871デフォルトの名無しさん2009/07/03(金) 21:12:51
アボートしますた
double free or corruptionだっておー
人の書いたソースをデバッグするのは大変だなぁ
0872デフォルトの名無しさん2009/07/03(金) 22:30:58
完全に C の代替となり得る言語が存在しないのが現状だから
C と仲良く付き合うことを考えたほうが生産的じゃね？
0873デフォルトの名無しさん2009/07/03(金) 22:37:15
>>872
つか、これだけルーズな言語はないんだが
当初の設計思想が、高級アセンブラだよな
0874デフォルトの名無しさん2009/07/04(土) 05:51:48
DOS時代にマクロアセンブラ使い始めて思ったのが、「もっと高度なマクロを
使いたい」だったからなぁ。高級アセンブラの需要は高かったと思う。
0875デフォルトの名無しさん2009/07/04(土) 10:09:43
Cを深く理解している人が作った
Cのコンセプトを100%受け継ぎつつ
互換性はない言語って誰か作ってないかな。
言語仕様眺めてみたい。
0876デフォルトの名無しさん2009/07/04(土) 13:34:36
>>875
100％受け継いでて互換性がないって、矛盾してるだろｗ
0877デフォルトの名無しさん2009/07/04(土) 14:58:38
矛盾していないと思うよ。
「Cのコンセプトを100%受け継ぎつつ」だから、
言語仕様はシンプルにするとか、プログラマは全知全能とか。
0878デフォルトの名無しさん2009/07/04(土) 17:17:59
Cのコンセプトに沿った物でCではない物の需要やいかに
C使えよ、で終わるんじゃないかなあw
0879デフォルトの名無しさん2009/07/04(土) 18:22:14
確かにCは駆逐したほうがいいな。
まあハードの進化によって早晩あんな糞言語は消え去るだろう。
0880デフォルトの名無しさん2009/07/04(土) 18:32:29
言語としてのC以外に、環境としてのC世界が広いのが悩ましいな
いろんなシステムがC由来の世界に依存してるからね
*nix以外だとOSXはCore Foundationでラップした世界にしてる感じなのかな
MSならそのうち根幹からCLIとかにしちゃうのかもしらんけど
0881デフォルトの名無しさん2009/07/04(土) 19:44:52
環境としての広さならPerlだって負けてないぞ
Unixには標準でインストールされてるし、Windowsでもフリーでダウンロード可能。
道具の扱いやすいさにおいてはPerlがぴかいちだと思ってる。
C言語はやることが細かすぎて途中で放り出したくなる
0882デフォルトの名無しさん2009/07/04(土) 20:07:54
perlがもう駆逐されてるのに。
0883デフォルトの名無しさん2009/07/04(土) 22:51:21
>>879
モノに出来ずよっぽど悔しかったんだろうが、お前はそもそもプログラマに向いてない。
0884デフォルトの名無しさん2009/07/05(日) 01:18:03
perlはCGI記述用として注目されたのが唯一の最盛期だったな
0885デフォルトの名無しさん2009/07/05(日) 10:37:38
それ以前に、sed, awk, perl あたりの言語やツールが盛り上がったことがあったんだよ。
0886デフォルトの名無しさん2009/07/05(日) 10:47:27
sec+awkが遅いから、代わりにperlが流行った。
ところで、Cは組み込みの文字列型と、new/deleteを採用してほしい。
0887デフォルトの名無しさん2009/07/05(日) 16:21:49
>>886
> ところで、Cは組み込みの文字列型と、new/deleteを採用してほしい。
そんな物を「今さら」「Cに」採用すべき必然性は皆無。
0888デフォルトの名無しさん2009/07/05(日) 16:38:04
どんな言語にも何も必然性なんてないよ。
0889デフォルトの名無しさん2009/07/05(日) 16:53:54
「よく分からんけど取りあえず反論してみたい」らしいなｗ
0890デフォルトの名無しさん2009/07/05(日) 20:39:06
Cを駆逐したいなら、「今さら」という発想が出てくるだろうが、
Cを今後も使い続けていくなら、「今さら」ということはない。
C++とCはずいぶん違う言語になった。
C++を丸ごと使いたくない人たちに向けてのCの改良があっていい。

ただし、言語の文法は究極的には好みの問題で、
必然性なんて議論する話ではない。
必然性があるかないかなんて話をしはじめたら、
一般的な必然性のあるものなんてない。
0891デフォルトの名無しさん2009/07/05(日) 20:51:00
C言語儲の僕は、前から名前空間とテンプレートが欲しいと思っていた
まぁ、C89でもがんばれば似たようなことはできるしC99なら似たようなことができるから、そこまで強く言ってこなかったが

>886
無ければ自分で作ればいいだけのことよ
僕は、文字列型を作ったし、C言語で抽象データ型とオブジェクト指向風に書くためにnew/deleteのようなマクロも作った
0892デフォルトの名無しさん2009/07/05(日) 21:32:40
>>891
みんなが勝手に俺様仕様を作ってもしかたがない。
0893デフォルトの名無しさん2009/07/06(月) 14:12:36
gccを使ってフロントエンドのみ変えるだけなら誰でもできる。
0894デフォルトの名無しさん2009/07/06(月) 15:08:54
>>891
趣味と実務は違うのだよｗ
プロの世界は、技術だけではやって行けない。
その意味が分からないなら、まだ下っ端。
0895デフォルトの名無しさん2009/07/06(月) 23:36:56
技術だけではやっていけないかも知れないが、技術が無い奴はこの世界から去って欲しい。

とはいいつつも、技術が無い奴の尻拭いで飯食ってるので、やっぱ居て欲しい。
0896デフォルトの名無しさん2009/07/07(火) 23:45:23
需要がある以上は駆逐されんと思うけど、
駆逐するには、という質問に対して代替言語を提示する以外に
何かいい回答ってあるんすか？
0897デフォルトの名無しさん2009/07/08(水) 03:22:13
Cで書くのが無理なくらいハードウェアが複雑化したりとか
0898デフォルトの名無しさん2009/07/08(水) 10:33:05
何かの間違いで Java プロセッサが台頭してきたりとか
もっと間違えて .NET プロセッサが出来たりとか
0899デフォルトの名無しさん2009/07/08(水) 11:12:23
順番が逆だろう
Javaが完全勝利した後でJavaプロセッサが台頭するならわからんでもない
0900デフォルトの名無しさん2009/07/08(水) 13:11:50
javaが台頭なんてありえるのかよ。
2-3世代前のマシン使ってるような遅さなのに。
特にLinux上。
0901デフォルトの名無しさん2009/07/08(水) 21:17:32
ecj、gcjあるよねー
0902デフォルトの名無しさん2009/07/17(金) 00:17:27
const みたいに実行速度に影響ないようなものなら
c にとりいれられる。
0903デフォルトの名無しさん2009/07/17(金) 21:38:01
ネームスペースは？
0904デフォルトの名無しさん2009/07/29(水) 05:07:58
まあバグばっかり作ってる実務より稼動する趣味の方がましってマーケットは考えるけどな
0905デフォルトの名無しさん2009/07/29(水) 12:53:21
Head Fastシリーズとかに代表される
「初心者向けの」オブジェクト指向本やデザインパターン本が
言語基盤としてJavaを取り上げるケースが増えてるので
なんとなくJavaがはびこりはじめているような気がする…。
0906デフォルトの名無しさん2009/07/29(水) 17:03:13
携帯電話というプラットホームは一応「Ｃ言語を駆逐」した例になるのかな？
0907デフォルトの名無しさん2009/07/29(水) 17:26:08
なぜ？
0908デフォルトの名無しさん2009/07/29(水) 18:30:38
>>906
ブロードバンドプロセッサ側はおもいっきりCだけど
0909デフォルトの名無しさん2009/07/29(水) 18:31:24
普通にCで書かれたアプリもあるだろ
0910デフォルトの名無しさん2009/07/29(水) 18:43:39
>>909
auのBREWアプリだけでしょ。

ドコモもソフトバンクもアプリはJava。
その下の層はもちろんCが欠かせないはずだけど、>>906はそこを言っているわけではないだろうし。
0911デフォルトの名無しさん2009/07/29(水) 19:35:40
それだとWindowsもC#が
0912デフォルトの名無しさん2009/07/29(水) 19:45:05
Obj-C
0913デフォルトの名無しさん2009/07/30(木) 00:07:35
>>905
オブジェクト指向言語を学びたいやつにCで教えるのは嫌がらせでしかないだろｗ
0914デフォルトの名無しさん2009/07/30(木) 00:25:51
まあそうなんだけど、ある程度オブジェクト指向が分かった後で
Cで無理やりオブジェクト指向してみるといろいろ感じるものがあるんだよな〜。
0915デフォルトの名無しさん2009/07/30(木) 00:56:39
俺は最初からOO風なコード書いてたからJavaとかに移行しても違和感なかった
というか構造体に変数入れてついでに関数ポインタ入れてとやってたら必然的にそうならない？
0916デフォルトの名無しさん2009/07/30(木) 01:00:10
まあいまやCなんか誰でも書けるから
希少性の上で価値はなくなったよな
0917デフォルトの名無しさん2009/07/30(木) 02:00:37
むしろCでちゃんと書ける奴は減ってる
0918デフォルトの名無しさん2009/07/30(木) 07:03:36
>>915
0919デフォルトの名無しさん2009/07/30(木) 08:46:42
>>914
C でなんとか OOP しようと悪戦苦闘した後に C++ に触れると
なんだかとてもありがたい言語のように思えるからあら不思議。

>>917
なんで減るん？退職したり死んだり？
0920デフォルトの名無しさん2009/07/30(木) 08:49:33
むしろCでちゃんと書ける奴の増加率は減ってる
0921デフォルトの名無しさん2009/07/30(木) 12:17:41
>>915
んなことするくらいなら c++ つかえ
0922デフォルトの名無しさん2009/07/30(木) 12:34:33
C++無い頃はそうやってた
0923デフォルトの名無しさん2009/07/30(木) 13:52:51
そういう意味では、C → C++ → Java/C# と移行したほうが有り難味があるな。
Cで、ドローツールっぽいのを書いていたけど、C++に移行して感動した。
その後、C++でCORBAやってたけど、Java/EJBに移行してなんて簡単なんだと思った。
そして今は、ScalaやOcamlを勉強しながら、Javaはなんて面倒なんだろうと嘆いている。
0924デフォルトの名無しさん2009/07/30(木) 15:21:19
そうしてどんどんプライドもメモリ使用も処理のサイクルも肥え太っていく
豚が出来上がるのですね
0925デフォルトの名無しさん2009/07/30(木) 17:34:09
Javaはなんで面倒なんだろう
0926デフォルトの名無しさん2009/07/30(木) 17:35:05
中国人とかのC使いが増えまくりだからな
生産効率が悪いCはもう部分的にしか使わないのが普通だよね
0927デフォルトの名無しさん2009/07/30(木) 21:00:32
>>919
C++がありがたい言語なのは当然だろう。
なにが不思議なんだ？
0928デフォルトの名無しさん2009/07/31(金) 00:14:19
宗教スレだから
0929デフォルトの名無しさん2009/07/31(金) 01:49:14
我らが教祖ビヨーン・スポッスポッ
0930デフォルトの名無しさん2009/07/31(金) 02:03:20
ありがたいというか適材適所に使うだけの話で
言語にこだわってると遅れとる原因になるよ
0931デフォルトの名無しさん2009/07/31(金) 10:38:54
組み込みや OS はまだまだ C なんかね。
そういう見方をすれば c 使いがエリート意識もつのもしゃーない気もするな。
0932デフォルトの名無しさん2009/07/31(金) 17:10:05
C言語のコンパイラの1つや2つ書いてから言えよ。
0933デフォルトの名無しさん2009/07/31(金) 20:53:50
Cに限らず、実用レベルの品質、性能をもったコンパイラは
大抵１００人年以上の工数がかかるんだがな。
0934デフォルトの名無しさん2009/08/01(土) 11:54:36

150 名前：デフォルトの名無しさん 投稿日：2109/07/31(水) 21:02:14
　Cコンパイラ作ったぞ
　>>932 出てこいやー
0935デフォルトの名無しさん2009/08/03(月) 07:09:51
といいつつメタコンパイラーに吐かせただけなのでした
0936デフォルトの名無しさん2009/08/07(金) 19:12:22
Google、コード検索から分かった統計を紹介
http://japan.internet.com/webtech/20090724/12.html

＞たとえば、「オープンソース プログラムは、
＞『C』と『C++』のどちらで書かれたものが多い？」といったような質問だ。
＞答えは C 言語ベースのプログラムで、C++ の倍以上あるという。
0937デフォルトの名無しさん2009/08/09(日) 21:08:15
C++やC#は原作者の名前が覚えづらいのが問題。
その点Cは、ダリル・ホール＆ジョン・オーツと、覚えやすいから安心。
0938デフォルトの名無しさん2009/08/10(月) 05:21:42
それ、びよーん・すぽっすぽっに喧嘩売ってるのかしら
0939デフォルトの名無しさん2009/08/10(月) 08:16:50
aho
0940デフォルトの名無しさん2009/08/10(月) 11:00:28
awkの「a」のひと
0941デフォルトの名無しさん2009/08/10(月) 12:06:53
>>1
ボランティアで既存のCのコードを全部新言語でリプレースし
可読性、パフォーマンス、メンテナンス性等で既存のコードを圧倒する。
Linuxカーネルとか。そしてCグラマの引退を待つ。
そうすりゃCのコードなんて99％撲滅できる。
0942デフォルトの名無しさん2009/08/10(月) 12:19:53
なんつー厨房思考
0943デフォルトの名無しさん2009/08/10(月) 12:27:40
カーネルも書けるような新言語ってあったっけ？
0944デフォルトの名無しさん2009/08/10(月) 13:02:56
言語から作れ、つってんじゃね？知らんけど。
0945デフォルトの名無しさん2009/08/10(月) 22:48:19
D
0946デフォルトの名無しさん2009/08/10(月) 22:58:40
これだけ ＊アセンブラに近い言語＊ を他に作れるかの問題だろ
高級になればなるほどアセンブラから離れるわけだし…
0947デフォルトの名無しさん2009/08/10(月) 23:41:35
なつやすみですね、みなさん。
みなさんにしゅくだいです。
これからいっしゅうかんいないに
どくそうせいのあるCげんごのけってんをひとり10こしらべてここにかきなさい。
0948デフォルトの名無しさん2009/08/11(火) 00:32:46
1.すぐ喧嘩になる(書式論争free不要論争その他)
2.インデントがめちゃくちゃでも動く
3.自称なんちゃってプログラマでも参加出来る
4.そのうちコンパイル中の警告が気にならなくなる
5.メモリリークしてても気付かない
6.名前がぶつからないように長くなる
7.ヘッダ二重読み防止機能を自分で毎回書く
8.staticが糞
9.scanfが糞
10.いらない子をいっぱい生んでしまった
順不同
0949デフォルトの名無しさん2009/08/11(火) 01:39:18
>948
1. 別に喧嘩しているわけではないよ、教えをひろめているだけだよ
2. フリーフォーマットを認めていない言語に移ってください
　インデントなんて可読性をあげるだけのただの飾りだよ
3. なんちゃって、せめて規格書を読んだ人だけが使う職人向け言語になってほしいな
4. 無視するのはへぼプログラマ、私はコンパイラの警告はすべてクリーンに保っている
　さすがにlintクリーンはできていないが
5. ただのへぼプログラマ
6. あるある、しかしながら、構造体に関数ポインタで長くならないようにしている
7. あれを書くと始めようという気になる、
　もっとも、最近はIDEで書かずに済んだりしているんだろう
　スクリプトで一発にしてもいいし、UUID必須だよな
8. staticの修飾の意味がスコープによってことなるのは、確かによくない
　まぁ、もう慣れているから今更変えられるのもごめんだけど
9. scanfが糞
10. 確かに

C言語の短所は同時に長所である場合が多い
型の大小関係以外決められていない -> 多くの環境に移植された
入出力をライブラリで提供 -> 言語としてとてもシンプルにできた
ポインタがあるのでアンセーフ -> 効率の良いプログラムがかける
... 別に名前空間とテンプレートが加われば、C言語に不満はないんだわ
0950このプログラム作ってくださいm( _ _ )m2009/08/11(火) 03:11:48
1. 以下のプログラムは、勝ち数と負け数を入力して勝率
(=　勝ち数　/　（　勝ち数　＋　負け数）　）を計算するプログラムである。
勝ち数、負け数に負の値が入力された場合は入力をやり直させ、
勝ち数＋負け数が0　の場合は勝率計算が不能であることを表示する。
ただし、このプログラムはバグを含んでおり正しく動作しない。
デバックを行って正常動作するようにせよ。
修正したソースプログラムと実行結果を示すこと。
0951このプログラム作ってくださいm( _ _ )m2009/08/11(火) 03:13:26
#include <stdio.h>

　 int main(void){
　 　int nwin, nlose;

　 　do
　　　　printf("勝ち数を入力してください:");
　　　　scanf("%d",nwin);
　 　　　if　(nwin<0)
　　　　　　puts("負の値を入力しないでください！");
　　while(nwin<0);

　 　do
　 　　　printf("負け数を入力してください:");
　 　　　scanf("%d",nlose);
　 　　　if　(nwin<0)
　 　　　　　puts("負の値を入力しないでください！");
　 　while(nlose<0)

　　total = nwin + nlose;
　 　if (total = 0)
　 　　　puts("勝率を計算できません。");
　 　else
　 　　　printf("勝率は%dです。\n",nwin/total );
　 　return(0);
　 　}
0952このプログラム作ってくださいm( _ _ )m2009/08/11(火) 03:14:07
２．半径(ｃｍ)と中心角（度）（いずれも整数値）を入力して扇形の面積を計算する
　　プログラムを作成せよ。円周率の小数点以下桁数は任意に決めてもよい。
　　ただし、入力値に以下の処理を加えること。
　　・半径に負の値が入力された場合、入力をやり直させる。
　　・中心角の入力値は以下のように処理する。
　　　ｉ．　　0〜359の場合はそのまま使う。
　　　ｉｉ．　負の値の場合、0か正の数になるまで繰り返し360を
　　　　　加えた値を中心角とする。
　　　　　（例：　-30　->　330,　-450　->　270　）
　　　ｉｉｉ．360以上の場合、360で割った剰余を中心角とする。
0953このプログラム作ってくださいm( _ _ )m2009/08/11(火) 03:15:08
　３．正の整数を繰り返し入力し、0　か負の数が入力されたらそこで入力を打ち切り、
　　そこまでの合計と平均を計算するプログラムを作成せよ。
　　最後に入力した負の数は計算に入れないようにせよ。
　　また、平均は小数点以下まで算出せよ。　　

すいません、明日までにお願いできますか?
0954デフォルトの名無しさん2009/08/11(火) 03:18:49
いい問題なのに勿体無い

>>953
C/C++の宿題片付けます 129代目
http://pc12.2ch.net/test/read.cgi/tech/1247438792/

テンプレ読んでから投げてね
0955このプログラム作ってください！( >_ < )2009/08/11(火) 04:24:05
ごめんなさい。
そっちに貼ります。
0956デフォルトの名無しさん2009/08/11(火) 06:55:35
>>948の1と3はCと関係ないだろｗ
0957デフォルトの名無しさん2009/08/11(火) 07:57:56
Linuxの世界だとCコンパイラよりC++コンパイラのが優秀なんだよねぇ
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=gpp&lang2=gcc&box=1
0958デフォルトの名無しさん2009/08/11(火) 11:13:31
Linux関係ないし
C++はテンプレート使っててるから
早い分コードサイズがでかい
0959デフォルトの名無しさん2009/11/19(木) 22:30:42
googleの新言語goがこんどこそCを駆逐する！
0960デフォルトの名無しさん2009/11/20(金) 00:00:56
>>959
go が GC 使っている以上、GCのない言語の需要はなくならないと思う。
0961デフォルトの名無しさん2009/11/20(金) 01:39:29
GCはいい事はいいんだけど、デストラクタと無関係な点で
必ずしも一番いいとは言えない
0962デフォルトの名無しさん2009/11/20(金) 13:23:53
GCがキチンとしてないと糞ニーのテレビみたいに止まっちゃうよw
0963デフォルトの名無しさん2009/11/20(金) 16:01:29
.NETで書かれたプログラムを走らせながらタスクマネージャを見ていると
explorer.exeのCPU使用率が一定間隔で跳ね上がる事がよくある

ああこの時GCが動いてるんだなあと思うんだけど、何か気持ち悪い
0964デフォルトの名無しさん2009/11/24(火) 21:51:08
OSからは、あと30年は消えそうにない。
0965デフォルトの名無しさん2009/11/25(水) 00:18:29
>>958
純粋な疑問なんだけど、コードサイズがでかいと具体的にどういう問題があるの?
0966デフォルトの名無しさん2009/11/25(水) 00:26:08
そりゃ実行時のメモリ不足とか配布に難がでてきたりとかだろ。
0967デフォルトの名無しさん2009/11/25(水) 00:27:39
命令キャッシュミスとかね
0968デフォルトの名無しさん2009/11/25(水) 00:29:19
それはあんまりないだろ。
0969デフォルトの名無しさん2009/11/25(水) 16:35:29
>>967は、大きな理由。
0970デフォルトの名無しさん2009/11/25(水) 23:45:03
おいおい
テキストサイズ増えたらIキャッシュミスが増えるCPUって欠陥だろw
0971デフォルトの名無しさん2009/12/08(火) 17:10:30
>>936
プログラム板にRubyのスレはたくさんあるけど、
Troffのスレは一つもないね。
0972デフォルトの名無しさん2009/12/29(火) 18:32:45
（´・ω・｀）
0973デフォルトの名無しさん2009/12/31(木) 22:58:12
C言語とC++とC#
0974デフォルトの名無しさん2010/02/23(火) 22:07:28
（´・ω・｀）
0975デフォルトの名無しさん2010/02/24(水) 01:45:02
>>965
流れ見てないけど、単純にROMに入らんことがある。
家電屋です。
0976デフォルトの名無しさん2010/02/24(水) 03:00:41
入りきらないのなら容量増やせばいいじゃない。
1Mb x32とか。
0977デフォルトの名無しさん2010/02/24(水) 07:09:05
>>946
同等の機能で、もうちょっと洗練された仕様の言語が欲しいなあ。
何かC言語って、色んなところになあなあの仕様があるから
余計に難解に感じることがある。
0978デフォルトの名無しさん2010/02/24(水) 09:44:11
>>977
そういう話は聞くが具体的にはなんだろう。
0979デフォルトの名無しさん2010/02/24(水) 11:31:32
>>975
よくある話でワラタ
ファーム屋と回路屋が別会社で喧嘩する話聞くよな
回路屋はアセンブラレベルで考えてファーム屋は高級言語で考えていた溝
前に回路屋はRAMが全部グローバルだと思っていてきっちりマップまで作っていた為に
スタックで潰しまくりんぐｗｗｗｗ

>>976
それだからソフト屋はコスト意識が低いと言われるんだ


でも最近いるんだよな
テレビのリモコン程度にIO足りないとかでSH２やら使う仕様書くメーカの奴
いくらのリモコン作るんだよって話ｗｗｗ
166や595のゲートで済むのにな
OSがいるとか意味不明すぎ
だからと言ってアセンブラで開発工数かけるのも問題
0980デフォルトの名無しさん2010/02/25(木) 07:52:49
>>961
goにはコンストラクタもデストラクタもないべ
0981デフォルトの名無しさん2010/02/25(木) 11:26:18
>>976
私組み込みに関わった事は無いけどその考えはプロとしては最悪だと思うの。
0982デフォルトの名無しさん2010/02/26(金) 08:25:39
ほ
0983デフォルトの名無しさん2010/02/26(金) 19:43:14
へ？
0984デフォルトの名無しさん2010/02/27(土) 02:29:38
転職してC言語から離れたからもうC言語駆逐されてもいいよ
でもC言語は組み込みがある限りは不滅なのかね
0985デフォルトの名無しさん2010/02/27(土) 02:46:38
OSもあるから。
レス数が950を超えています。1000を超えると書き込みができなくなります。