Cでプログラム言語は完成した

ぶっちゃけた話Cじゃ出来ない事って特にないよね

アセンブラで出来ないことも無い訳だが

アセンブラは移植性ないじゃん

Cにはプリプロセッサという素晴らしい仕組みがある

プリプロセッサ自体はcじゃないんじゃ…

チューリングマシンですねわかります

HaskellやRubyなら信者乙、Lispならまじめにその通りだと思うと書くところだったんだが……。

>Cにはプリプロセッサという素晴らしい仕組みがある

その"素晴らしい"仕組みのおかげで地獄を見た人間が大勢いるわけだが。

日頃Cで物事を考える我々が、Cで記述できないことを表現し、考えることなどできるのだろうか。

>>1
できないこと => スタックポインタの設定

人の記憶能力は5±2チャンクしかない。
従って、記憶領域を７チャンク以上消費するプログラムは作成可能であるとは言えない。

この理論に基づいて意見するなら、
Hello worldでさえ
"int", "main", "(", "int", "argc", "char", "*", "argv", "[]", ")"
というように、プロトタイプ宣言だけで７チャンク以上消費してしまう。
そんなプログラミングコストの高いプログラミング言語でできることなど、何もあろうはずがない。

>>7
包丁という素晴らしい道具は、多くの料理を生み出してきましたが
同時にいくつもの悲劇を起こしてきました
物事の片面だけを見るのは良くないですね

やっぱりC++の方がええわぁ

Cのプリプロセッサはウンコ

>>12
まぁ、C++の方が自分もいいと思う。つか、本当に真面目に使った/勉強したのがC++ぐらいで
Cをちゃんとやらなかったからかも知れんが、C++になれるとCって使いづらい。
なんか特別に面倒じゃないんだけど、回りくどい事をやっている感覚があんま好きじゃない。

LISPがもうちょっと上手い具合に進化してくれてたらきっと、
C++の莫大すぎて底なし沼のような情報と格闘しなくてもすんだかも。　と思う事がある。

>>14
Cをよく知りもしない奴が使いづらいとか好きじゃないとか、よくまあ偉そうに言えたもんだ

>>15がCについて深い見識を披露してくれるそうです。

Cで出来てC++で出来ない物ってあるのかえ？

そんなものがあったらBjarneさん死んじゃう

>>17
restrict ポインタ

C++0xでどうなるのかは知らんが。

>>17
マイコンとかでCコンパイラしか用意されていないことがある。
手間暇かければg++が使えそうな気はするんだけどマンドクセ。

>>20
そういう条件もってこないといけないあたりで、CはもうC++に勝てないんだとおもうな。

>>21

私もCはC++に勝てないと思いますが、世の中のソフトウェアは
ROM/RAM64kB以下のマイコンの方が多いのが事実で、そこのソフトを
書くにはCでないと…というのが 20 の真意でないですかね。

C++でガッツリ組むと、仮想関数呼出のオーバーヘッドだけでもはやどうにも
ならない場合も…。って条件もってこられること結構多いです。

あ、すいません。
多いかどうかは未検証です。申し訳ない。

64kByteROMのマイコンにやらせる事にそんな複雑な処理があるんですか？
C++でないと作るのが困難なほどの。

ありますよ。
アルゴリズムの複雑さはROM容量に比例しないです。

むしろマイコン内での責務分割をキッチリする上でもC++使いたいくらい。
Cでもきちんと構造化できる人なら問題ないですが。

メモリが小さいマシンで最大のパフォーマンスを出したいならCで書くべきだね。
C++のオーバーヘッドが無視できるほど大きいメモリ・速いCPUなら関係ないが。
書きにくいとかいう理由で小さいマシンでC++を使うのは品質低下なのだが、
現実にはきちんとCを書ける人間は少ないから仕方ないか。

Cできちんと書けない人が、C++でなら書けるのか。と。

�_

>>26
インライン展開、関数オブジェクトがあるC++の方が性能上

>>29
神コーディングなら、どんな言語でも性能は良いだろう。
問題は狭い道を通るのに、車と自転者ではどちらが楽かだ。

>>29
インラインはC99にあるし
関数オブジェクトはCでも同等の速度で書ける

つまり（同性能のコンパイラなら）
速度はC>=C++になる

>>29
文盲かよ、メモリの小さいマシンって書いてあるだろ
おまえみたいなのがどこでもC++を使おうとするから品質低下になる
いまどきCにインラインがあることも知らないでC/C++を語るな

main(){}

だけCでもC++でも実行ファイルサイズ、メモリ消費量はかわらんだろ。
最低限のヘッダを上手く選び出せば実行ファイルサイズはどっちも同じでは?
メモリ消費量は、言語の違いではなく、アルゴリズムに依存する。

それにC言語専用のコンパイラは少ないし、C++の方が発展しているから
C++でコンパイルした方が性能、メモリの最適化が効く可能性有り。

c++ってある意味、windowsだよな

>>33
クラスとかのメモリ食うものを使わないならCでいいだろ。

クラスがメモリ食うて誰が言った_?

C++ が何だかよく知らない >>36 が言いました。

>>35
どういう意味よ

３６じゃないけど、C++のクラスってCの構造体と違って、デフォルトコンストラクタとかコピーコンストラクタとかいろいろ勝手に作るんじゃなかったっけ？

>>39
最良の選択肢ではないが
なぜか普及している。

どうでもいいけど、
生き残ったものが適者ですって言葉思い出した。

一応、生きてさえいればライブラリの蓄積は進むし
いつかAJAXみたいな復活をしないとも限らん罠

>>40
内容が空ならインライン展開されてCの構造体と変わらなくなる。

>>33
mainだけのサイズ比べたって意味が無い
C++固有の機能を使うならその分のサイズオーバーヘッドはある
C++の中のC部分だけを使うならCで書いた方が良い
何故なら同じ速度・同じサイズなら移植性が高い方が優れているからだ

>>34
ソースは？

>>44
内容が空ならって、空の構造体なんて何に使うんだよ
果てしなく無意味な仮定だな

>>46
空っていうのは、コンストラクタやデストラクタのことだぞ。
もちろんほかのメンバは存在するよ。

>>1
CPLDなんかは、専用言語じゃなければ無理な訳だが。
シーケンサー関連はアセンブリですら無理。

>>40
PODなクラスはコンストラクタもデストラクタも作られません。

>>47
「インライン展開」はどう言い訳しますか？

>>49
X3014を読む限り、PODなクラス（構造体）でも
コンストラクタやデストラクタは作られるように思う。
（もちろん、実際にコードが生成されるかは別の話）

12.1 コンストラクタを読むと、コンストラクタを宣言しなければ
暗黙に宣言された省略時コンストラクタがinline publicで宣言されるとある。
そして、デストラクタも同様の規定が12.4に存在する。
また、9 クラスにPODは利用者定義のデストラクタを持たないという条件があるが、
逆に言えば、暗黙のデストラクタが存在するということではないだろうか。

あと、スレ違いだからこれくらいにしようよ。

>>49
＞ >>40
＞ PODなクラスはコンストラクタもデストラクタも作られません。
＞
＞ >>47
＞ 「インライン展開」はどう言い訳しますか？

馬鹿はスルーしとけよ＾＾；；；；；；；；；；；；；；

>>50
宣言はされるが、定義は (明示的に呼び出さない限り) されない。

>>54
暗黙に呼び出された場合も定義されるよ。

ははは

自動焼人 ★　＝　自動保守 ◆KAWORUKOFI　＝　自動保守#K9K?_D[L

名言集　その３
『いつもサボってばかりのキャップがウゼえ』

http://yutori7.2ch.net/test/read.cgi/news4vip/1249830540/　ID:PVAf+dux0　＝　自動焼人 ★
> 71 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:58:57.28 ID:PVAf+dux0
> >>69
> 大変って言うか
> 毎日、報告されたのを見て、判断して、処理して、完了報告して、以下ループ。
> ちょっとでもミスすると、普段は作業もしてないキャップさんたちがさんざん文句言ってきて
> その言いわけを考えないと、キャップはく奪されたりアカウント凍結されたりするから
>
> 登録されてから一年以上経って、やっといいたいこと言えるようになってきたよ。



----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください