【訃報】C言語およびＵＮＩＸの父、デニス・リッチーさんが死去 -享年７０★５

UNIXの父であり周囲の尊敬を集めたコンピュータサイエンティストのデニス・リッチーが、
しばらくの闘病を経て先週亡くなっていたことがわかった。享年70歳だった。

リッチー（dmrと呼ばれることもある）は、プログラミング言語のひとつであるC言語を生み出したこと、
そしてケン・トンプソンとともにUNIXを創りだしたことで世界中にその名を知られている。
リッチーはキャリアのほとんどをベル研究所で過ごした。彼が加わった1967年当時はアメリカで最も巨大な
電話回線提供社であり、かつ最も有名な研究所のひとつを運営する大企業であった。

60年代後半にトンプソン（彼はCの前進であるB言語を生み出した）とベルで働いているとき、
訪れようとしていたミニコンピュータ時代をにらみ、
より効率的なオペレーティングシステムを開発しようと思い立った。二人を中心としたこの作業は、
1971年のUNIXへと繋がっていった（DEC PDP-11の上で動作した）

TechCrunch Japan 10月14日(金)2時37分配信
http://headlines.yahoo.co.jp/hl?a=20111014-00001491-techcr-sci
画像　デニス・リッチーさん
http://e-bergi.com/2008/Agustos/resim/dennis_ritchie.jpg
前スレ　★１　2011/10/14(金) 11:19:08.25
http://raicho.2ch.net/test/read.cgi/newsplus/1318703183/l50
＞＞２以降に続く

UNIXは安価で、かつさまざまなマシンを動作対象として想定してはいた。いったん動作させることができれば、
その上にさまざまなソフトウェアシステムを載せることができるようになっていた。
しかしOSがマシン語（アセンブリ言語）で記述されていたため、移植性も低く、またメモリの取り扱いにも苦労することとなった。

そこでリッチーとトンプソンは、C言語のシンタックスを発展させつつ機能を増やし、
ついにはOSを記述できるところまでに性能をあげていった。
そして1973年までにはついに、UNIXをCで書き換えてしまったのだ。カーネル部分は同年中に公開された。

今日、C言語は依然として2番目にポピュラーな言語として世界中で使われている（ないし、
これまでに記述されたコード量としては第2位につけている）。
そしてC++やJavaにさまざまな考え方が引き継がれていった。またUNIXについての二人の仕事は、
たとえばLinux TorvaldsのLinuxなどにも引き継がれていった。このUNIXの仕事だけでも、
リッチーは現代でもっとも重要なエンジニアのひとりとして位置づけられるべきだろう。

実際、UNIX関連の仕事により1983年にはケン・トンプソンとともに、チューリング賞を受賞している。
また1998年には当時の大統領であるビル・クリントンからアメリカ国家技術賞を受け取っている。（おわり）

まさかの5スレ目ｗ
以下、ポインタとOOPの話は禁止で

void main()
{

printf("RIP");
}

Kはどうなんだ

10 print "Hello Unix World!"
20 goto 10

9割は記事と関係ない話で埋まるのに
なんで5スレ目も立てるのさ

ぬ

ポインタ話禁止、ユダヤ話OK

main()
学生の頃やっていたが・・・懐かしい何もかも

5スレ目かよｗ

まだやっていたのか…おまいらときたらｗ
…でも、お世話になり過ぎだし、今でもその系譜を使い続けている俺にとっては
…こっちを映画に…というか、スペシャルドキュメント番組作ってくれよ
３時間くらいで

UNIXの偉大さを…

俺も若いころはこんな歴史に名前を残すような計算機科学者を夢見ていたな・・
とりあえず立派なITドカには成れたが。

ライオネル・リッチーもさぞかし悲しんでいることだろう

この人知ってる。
オーナイロ〜ングとか歌ってた人だわ

Ａ言語とＢ言語はないの？

MacってUNIXだったんだな

ＵＮＩＸにあこがれて活気的なＯＳ作るぞーとか力んでた時代があったなｗ
日本のＩＴ業界（笑）は労働力の切り売りとマージンで成り立ってて即効見切ったけどｗ
何年たっても「日本発世界に」とはならない理由がそれだよねｗｗ
目先の利益にしがみつくしかないｗ

>>17
A−アセンブラ
B−BASIC
と一般的に言われてる単なる語呂合わせだと思うけど

スレ５ってまた微妙な

そっかあ、あの人も死んだか。

ヒゲはやしたイイ感じのおっさんだったが、
来日コンサートにも行ったよな。
デュエットのエンドレスラブも良かったなあ。

５ってｗｗｗおまいらｗｗｗ
どうせＩＴ関連なら２ｃｈも長いのが多いんだろｗ

:::::::::::/　　　　　　　　　　 ヽ::::::::::::
:::::::::::|　　キ　　じ　　き　　i::::::::::::
:::::::::::.ゝ　モ 　 つ 　 み　 ﾉ:::::::::::
:::::::::::/　 イ　　に　　は　ｲ:::::::::::::
:::::　 |　　な。　　　　　　　ﾞi　　::::::
　　　＼_ 　　　　　　　 ,,-'
――--､..,ヽ__　　＿,,-''
:::::::,-‐､,‐､ヽ.　)ノ
:::::_|/ ｡|｡ヽ|-i､　　..　　　 ／￣￣￣￣
／. ` ' ● '　ﾆ ､　　　　（＿＿＿＿人
ニ　＿_ｌ＿_＿ノ　　　　（-◎-◎一
/￣　＿　　| i　　　　　（　(_　_)
|(￣`'　　）/ /　,..　　　 （　ε　 　（∴←張勲・郭光雄・黄進煥信者でマルハン・ロッテ・サンセイ御用達の在日
`ー---―' / '（__ ）　　　ヽ＿＿＿＿　珍英米不細工白痴韓国エベンキ人記者出世ウホ　
====（ i）==::::／　　　　　　,/ﾆ>>
:/ 　　 　ヽ:::i　　　　　　　/;;;;;;;;;;;;;;;;

>>20
いい加減なこというなよｗ
http://www.lbm.go.jp/toda/comp/corigin.html

ＢＣＰＬ→Ｂ言語があったからＣ言語っていうんだよ。

じゃあＣはなんの略さ

pythonをほんんんっとに少しだけかじったことあるけど、
賢くなった気がした

言語そのものを作る人って神と同じ発想ができる人だよね

>>26
ＢＣＰＬがＢ言語じゃなくて、ＢＣＰＬの次にＢ言語ができたんだよ。

そういやＤ言語ってあったけど見事に消えたな。

>>26
そういう発想で命名されてない
Ｃ言語はＡ、ＢがあったからＣになっただけ。

>>28-29
なるほどﾄﾝ

>>25
マジレス乙です

>>27
思考回路が違うんだろうね
体のどの部分からでも自在に人物を描き上げる人とか、即興で音楽を作っちゃう人とかさ
ある思考パターンに最適化されているんだとおもう

希に、何種類もの思考パターンを持つマルチタレントな人物とか出てくるけどな
レオナルド・ダ・ヴィンチとかだな

仮に江戸時代にコンピュータのテクノロジーだけひょこっと生まれたとしたら、
どんな言語作ったのかな？

#include <stdio.h>

int main()
{
　　　int　i ;

　　　for (i=1; i<=1000; i++)
　　　{
　　　　　　printf("ぬるぽ\n");
　　　}
}

神はLisp

>>35
はいはいかっこかっここっかこっか

>>34
#include <stdio.h>
void main(){ int i; for(i=0; i < 1000;i++) printf("ガッ\n"); }
int mainなんだからreturn 1でも書いとかないとだな

プログラミング言語Cの日本語訳持ってるわ。
新たに概念を作り出すのは偉大だよね。合掌。

おまえらまだこんなニュースのスレでまでポインタ論争してたのか！

>>37
いや、おまいも void main の段階で論外だろｗ

>>33
和算アルゴリズムとかを組みこんだOSができていたりして

C言語で飯食ってる人間からすればジョブスよりこっちの方が残念だわ

ポインタが解らんのじゃなくて、メモリが解らんのだろう。
だから何に例えても伝わらない

そういえばオイラのMS-QuickCコンパイラ何処行ったんだろ・・・

>>33
紋紙に穴開けて機械語を表現するんじゃないか

>>40
プログラミング言語 Cの第１版ってvoid mainじゃなかったっけ？
あまり正確には覚えていないのだけれど

>>43
最低限、チューリングマシンの原理を教えてからなら理解できると思うんだけどねー
（箱と、無限の長さのテープがあり、箱はテープに書かれている内容にしたがって自分の状態を変えるとか）

PCの原理について何の予備知識もなかったら、ポインタの理解は確かにきついかもね
原理を知ってても理解できないならさすがに適正ないわ

眠れない夜 getchar()のせいだよ
さっきデバッグした ばかりなのに
肩腰が 凝っている
…直った、直ったよ！
wow〜oh〜
はじめてのC
プログラミング言語C
アイウォントエクセプション
配列出ちゃう メモリ確保してないのに
はじめてのC
プログラミングC
アイドンワナユーズポインタ
ポインタのポインタでいっぱいいっぱい
free()忘れずに

>>48
ワロタ

>>46
それがどうした？
現在において論外なのは間違いない。

アセンブラからプログラミング言語Cに行ったのはもう昔の話。

GUIライブラリとかいろいろ引き連れてたpythonとかのスクリプトをやった方が建設的ではある。
チマチマしたCをやりたいなら、1チップマイコンへGO!　そっちの方が面白いよ。

ポインタのことは悪く言わないで。

あたしやっぱりポインタじゃないとだめなの。

だから、さよなら。

ポインタより配列の方が難しい気がする。

テス

>>3
確かに
まさかの５スレ

ポインタは三重までｗ

>>27
>>32

何人もの研究者が大学内で夜な夜な作ったんだｗ
そりゃ多少複雑であっても、当たり前っちゃ当たり前ｗ

C言語とかまったく分からんが
5スレまで伸びてるということは凄い人なのかな？

カーニハン&リッチーで勉強したよねｗ

C → C++ → Java で飽きたｗ

>>58
みんなそうだよ。

人に優しくない言語だから死んでも世界からファンが集ったりすることはないし
精神を病んで殺してやりたいと思ってた奴は喜んでるだろう

C．．．　思えば処理系にずいぶん投資したな。　PC98こんちくしょ〜

K&Rは難しいから他ので勉強したな。

ポインタわからない人は参考書を間違えたんだろ。
今時入門書読めば優しく書いてあるよ。

>>57
神様みたいなもん

Hu-BASIC → Z８０アセンブラ → BDS-C（CP/M） → FORTH FORTRAN７７　N88BASIC　MASM　XーBASIC　

VB３　VB４で飽きたｗ　日立アセンブラ、三菱アセンブラ、perl HTML Javascriptがちょっと分かるくらいｗ

perlが一番楽だったなｗ　JavascriptはC言語並みにメンドクサイｗ

>1
Linux Torvalds?

>>64
C言語の前にアセンブラからやっとけば容易いのにｗ

>>68
インテル？モトローラ？

ある騒動の記憶
http://www.youtube.com/watch?v=DuugQ64Tpo8

> Hu-BASIC
懐かしいなオイ！
オレはそこからだ

>>68
アセンブラやるまでもないと思うけどな。
変数はコンピュータのメモリ上にあってメモリには１バイトごとに
番号（アドレス）がついてるってことだけがわかってれば。
C言語覚えた後にMASMちょっとだけやったけど。
レジスタとか知らなくても全然いい。

>>69
いいえザイログｗ

>>73
Ｚ８０ナツカシス！
６８０９と共に齧ったけど、組み方が全然違った。

ポインタを概念で理解できないなら
ポインタ変数とポインタ変数に格納されてるアドレスを
デバッガのメモリダンプで直接覗いて見ればわかるようになるよ

あと理解するのに重要なのが言葉の意味だな。
pointerは位置を指し示すものという意味がある。
point自体に位置とか先端という意味があるからな。

ベーマガだかアスキーだかの編集後記に
ポインターシスターズネタが載ってたな

結局*pとpと&pの関係がよく分からんのだな。

つまりポインタは変数が物理的なメモリ上のどこにあるかを
番号（アドレス）で指し示しているわけだよ。
なんでそんな面倒くさいことをするかというと
そもそもコンピュータはアドレスを使ってメモリ上の
変数にアクセスしてるからな。変数名はあくまでプログラミング言語において
人間用に用意されたもの。その辺の事情がわかるのがアセンブラ。

>>3
何も喋れんじゃないか…

C言語は動作を記述するもので、述語から始めて、常に俺
俺＝プログラム実体がやる操作（誰を,どのように）{…}

オブジェクト指向はデータを主体として、相対化された述語がくる
日本語の特徴が反映されてる
void mainがintになったように、常に観察者の存在がある
そしてそれは人間であり人間すなわち神ということである

>>78
変数＝*ポインタ
ポインタ＝＆変数
というそれだけの話

ポインタの中身の数値はアドレスということ。

>>82
厳密に言うと、「変数」はアドレスを実行環境が完全に管理しているが
「*ポインタ」はアドレスが「ポインタ」の値（を実行環境が変換したもの）である
という違いがあるんじゃないの。

今調べてきたらおぼろげにわかってきた。
&（*p）ってやれば、これをまた別のポインタに入力できるのかな。

VBは本読みながら何となく覚えたが、
コードが長くなるとすげぇ重たくなった思い出がある。

ポインタ自体も変数でその中身はメモリ上の位置を表す整数（アドレス）ってこと

>>85
できる。結局pと同じ値になるけど。

>>88
ちょっと待て、
*(&x)はxと同じになるが、
&(*p)はダメじゃないか？「*p」って左辺値じゃなくね？

はじめてのC

>>85
http://codepad.org/jDMGEcUE

デニスリッチーさんありがとう
あなたの発明したC言語のお蔭で、家が買えました。

*pは「ボインタ変数pに入っているアドレスの先にあるデータの値」なので&演算子は使えない。

というか、使う必要無いじゃん。
pに入っているアドレス使えばいいんだから。

&(*foo).bar

>>89>>93
お前ら偉そうなこと書いて全然ダメだなｗ
特にこいつ ID:xhQVUSWu0
ｗｗｗ

ポインタ解説にバイト・ワード用いるのは素人
スキー上達者ビデオ見せてさあ同じに滑ろと言ってるもん、過程全省略
構造体から入るべき

>>96
バイトくらい素人でも知ってるだろｗｗｗ

この人とセットのカーニハンさんはどうしてるんだろか

>>46
voidは標準化されてからだな。初版はint main()

>>99
と思ったが、intすらなかったわ。

http://www.lysator.liu.se/c/bwk-tutor.html#introduction

main( ) {
printf("hello, world");
}

これは論文だから、初版本とはちと違うけど、voidはこのころはまだ発明されたなかった

ポインタが理解できないってのは、抽象思考力が足りないんじゃないかな。
そりゃ一読しただけで完璧に理解するのは難しいけど、何回も色々読んでたら分かるでしょうに。

>>95
？
何言ってんだ？

おれが入社したときはvoid無かった。
void導入されてもしばらく社内では禁止されてた。

voidは関数じゃない（サブルーチン）から良くないって言われた。

>>102
お前こそ何言ってるんだwwwwwｗ

&(*p)はpと同じになるし
*pは左辺値にもなる

>>91みろよｗｗｗ
*pが左辺値にもなるのは試せｗｗｗ

>>104
今実行環境なくてね…
でも>>91にはコンパイルエラーって書いてあるけど。

献花はどこにするの？

>>105
まだ悪あがきするかめんどくせえｗｗ
だいたい*pが左辺値にならないとほざいた時点で
お前はポインタの基本もわかってないんだよｗｗｗ

&(*p)くらいCプログラマーなら実験したことあるだろ。

大昔のアセンブラはuseマクロで構造体アクセスに使用する
ベースレジスタを指定できた。
構造体をいくつも使うときはuseマクロの切り替えが面倒でバグの温床になった。
これがポインタからの->アクセスになっとるのがCだなというのが
最初の感想だった。
でもアーキテクチャ上バイトアドレスを持たないDataGeneralのマシンに
Cを移植するときはちと苦労した。

訃報（とほー）です。　 <竹内由恵

>>105
gccだと-std=c89でも-std=c99でもコンパイル通るね。

&(*a)を左辺に持ってくるのは無理だけど。

そもそも、

&((int*)0x00151501)
これだってできるだろう？

http://codepad.org/
これでも試せるから↑
ちょっと試すのに便利だな


#include <stdio.h>
int main(void)
{
int i=123;
int *p1,*p2;

p1=&i;
p2=&(*p1); /*できる*/

printf("%d %d %d\n",i,*p1,*p2);

*p1=456; /*できる*/

printf("%d %d %d\n",i,*p1,*p2);

return 0;
}


結果
123 123 123
456 456 456

>>89
おいおい…
*pが左辺値になりうるのはポインタの常識だろ…
文字列のコピー処理をポインタを使って書いてみそ？

Cのポインタがややこしいと思うのはポインタで型宣言した場合とそうでない場合に
実体（中身の値）とアドレス渡しの時に＊と＆の使い方が逆に見えるのが原因で混乱する事が多いな。
int a, *b;
a　ポインタ型でない実体渡し
&a ポインタ型でないアドレス渡し
*b　ポインタ型の実体渡し
b　ポインタ型のアドレス渡し
間違えてwarningになることも多いけどｗ

peekとpokeが分かれば大丈夫。

int hoge(char fuga[]);
int hoge(char *fuga);

の使い分けがわかんにゃい

ぬるぽ

>>117
同じだろ。好きな方使えばいいんじゃないの。

デニスが父なら母は誰だ！
あ、無性生殖
でもそれなら父という言い方が変

Line入力からラジオを録音をしたいんだけど
簡単なプログラムおせーて

ubuntuなんだけど

#include <stdio.h>
#include <ctype.h>
int main ()
{
int a = 0;
int b = 0;
int c = 0;
int d = 0;
int* p;
int* q[3];

p = &a;
*p = 1;
q[0] = p;

p = &b;
*(q+1) = *(&p);
*q[1] = 2;

*(q+2) = &c;
**(q+2) = 3;

*(&d) = **q + *q[1] + **(q+2);

printf ( "a:%x b:%x c:%x d:%x \n" , a, b, c, d );
printf ( "a:%x b:%x c:%x d:%x \n" , &a, &b, &c, &d );
printf ( "q[0]:%x q[1]:%x q[2]:%x \n" , q[0],q[1],q[2]);
while (isspace(getchar()));
return (0);
}

>>121
Cで？簡単じゃないな多分

>>122
これ動く？
a 1
b 2
c 3
d 6
になるはず。

ポインタの概念がようやく分かってきたところで
ポインタのポインタが現れて悶絶

>>27
発想そのものはそうかもしれんが、全知の能力がありませんからね。
注意深くダメな部分を取り除くしかないわけですけど…
後生の人にそれを託すのはやめて欲しいわけです。Javaとかね。

>>120
母は知らんが祖父は韓国だろう

つまりC言語も余裕で韓国発祥ﾆﾀﾞ

>>121
/dev/audioから読み出すだけでいいのでは？

>>72　アセンブラやるまでもないと思うけどな。
割り込みとかＣだけで書けたっけ？
デバイスの初期化と割り込みはアセンブラで
全体はＣというのが一般的じゃない

>>129
部分的に繰り返す処理で速度を求めるなら
_asmとかインラインアセンブラも必要だけど
割り込みとかioctl()でできるし、不都合はあまりないと思う

>>120
同人誌でやれ。

>>27
実用になってる言語は、すでに確立した発想の組み合わせ。
新しい発想は、実験的な言語で試され、一部でしか使われないことが多い。

言語デザインは、新しい発想だけに価値があるんじゃなくて、組み合わせの妙とか、
美的センスみたいなものがあるけどね。

>>100
int は、省略可能だから、意味は同じだな。

main() の戻り値は、exit(2) の値だから、void じゃないんだよね。

よく考えれば、C プログラムは、関数、ストラクチャ、変数宣言でできてるのに、
defun とかのキーワードが不要なんだよね。
昔の言語の LET とかが、ほとんど無くなったのと同じかな。

>>129
いやポインタを理解するのにアセンブラをやる必要があるかって
話の流れだから。そりゃやっても損はないだろうけど。

93 名前：名無しさん＠１２周年[sage] 投稿日：2011/10/18(火) 04:19:50.32 ID:P2jrd8gJ0 [2/2]
*pは「ボインタ変数pに入っているアドレスの先にあるデータの値」なので&演算子は使えない。

93 名前：名無しさん＠１２周年[sage] 投稿日：2011/10/18(火) 04:19:50.32 ID:P2jrd8gJ0 [2/2]
*pは「ボインタ変数pに入っているアドレスの先にあるデータの値」なので&演算子は使えない。

93 名前：名無しさん＠１２周年[sage] 投稿日：2011/10/18(火) 04:19:50.32 ID:P2jrd8gJ0 [2/2]
*pは「ボインタ変数pに入っているアドレスの先にあるデータの値」なので&演算子は使えない。

ｗｗｗｗｗｗｗ

お前ら、ほとんど悼んでないな…
生きてるうちから神様だったからか

C/C++はややこしいよな
しばらく触ってないと細かいことは忘れるよ
コンパイラ通ればいいんじゃないの

★5までのびたか。
故人の人類に対する貢献を思えば当然だな。

>>134
デバッグにはアセンブラの知識が必要
もちろんバリバリにアセンブラでプログラム必要は全くない
Cコンパイラの吐き出すマシン語が何をやっているか
アセンブラレベルで理解していないと、きちんとしたデバッグが出来ない

特にシステム系

そこまで才能があり努力もしているのに
どうして評価が低いのだろう、給料が普通にExcel使うだけの人と同じなんだろう

>>115
Cだけだと一貫性があるんだがC++で拡張したときにややこしくなったんだよな。
C++参照型の宣言をどうするかって

ベル研も大変だーね ポインタ秋田

>>141（つづき）
なったときポインタがint *a;だから参照はint &b;にしとくかみたいな。
でもよく考えてみたら後者は論理的に少しおかしい。
で"int&"でひとかたまりで参照型と考えてint& a;と書いとくかみたいな。
でもa,bを参照型にしたいときint& a,b;とやっちゃう落とし穴ｗ
じゃあ間をとってint & a;って書いとけみたいなグダグダ感ｗｗ

UNIXはリクシルになったのか？

Think C
マックでこれ使ってた
てか、マックでプログラム言語って
これしか無かった
ツールボックスって今でも引き継がれてるのかな？

ポインタの説明に低レベルの実装例を持ち出すと理解が早い
というのはそのとおりだと思うんだけど、
しかし、K&R（第二版）の説明はもっと秀逸だと個人的には思う。
文字列、多次元配列、コマンド行引数、関数ポインタ…。
つまり、理屈より先によく使われるパターンを覚えてしまえ（習うより慣れろ）、と。
そして関数ポインタの説明の直後に宣言構文の解析がでてくる…それほど、
関数ポインタを「読む」には構文解析の正確な知識が必要だと
カーニハンとリッチーは言っているわけだ。

400ページにも満たないこの本でCがひと通り理解できてしまうのは
天才的な説明法にもあるに違いない。

>>121
お前が今までそうやって生きてこれたならお前の周りの人間はきっとハイスペックな奴ばっかなんだろうな。

unixのmac osとovjective-cがメインストリーム
C++はオワコン
仮想化してunix環境入れるにしてもマイナーなlinuxなんて今時誰も使ってない

>>143
引数の線源に & をつかえるのは、構文糖だと思ってる。
実際には、* つきで宣言してあるのと同じで、関数内で * を省略できるだけでは？

>>145
Think-Cは大昔に少しだけやってたな。まともな参考書がない時代だったんで苦労した。
やっと買った参考書の著者が馬鹿な奴で、北尾と長州がもめたのはどうたらこうたらとか、
どうでもいいことばかり書いてて、頭痛くなった。

おまいら詳しいなｗ

父がこの人なら、母はだれなのー？ねえだれなのー？

何かすっかり昔の知識のお披露目会みたいなスレになってるな・・・・

ポインタは性能はさておき
文法書式がクイズになる時点で言語的にはダメだろう。

「俺はこんな書き方でもわかるぜ！」
なんて自慢するところじゃない。
そこはむしろ恥じて自重するべき。

いわゆるマシン語(アセンブラ)でも裏ワザってあるからw

>>154
はげ同

誰が書いても、同じコードになり、同じパフォーマンスが出る
という言語が最高だな

それじゃ逆に面白くない

名人に頼っていると、名人が死んだときに終わる。
また、名人が生産できる以上の数は決して作れないから、広まらない。

コンピュータだけでなく、どの分野でも同じ。
名人芸は害悪

>>154
そうなんだよね。
今となってはポインタなんて害悪でしかない。

でも、それが出来るから、アセンブラを触らなければならないような
小さい世界の中ではC言語は現役で居続けられる。

>>156
それはいまのところPythonしかないな。

>>159
ポインタわかってないでしょ？
害悪なんてとんでもない。C言語のシンタックスがいまいちなだけ。

chop; chop; chop;

>>143
俺は別に気にせず普通に
int &a;
って書くけどな。
それが逆に一番誤解がないだろ。
実体もポインタも参照もまとめて書けるし
int a, *b, &c;

アセンブラをやったんだけどすぐに挫折してCに移った。
スタックあたりまでやっていたんでポインタで挫折しなくて
助かった。

ポインタそんな難しいかねえ。
配列へのポインタとか関数へのポインタになると
一瞬「なんじゃこれ？」とは思うけどすぐ慣れるしな。
ほとんど使わないけど。

危険な技（ポインタを使ってデータとして書き込んで、関数として実行させる。とか
確保したバッファ以上の場所に書き込める。とか）

は、もう現代社会では不要だと思う

組み込み分野じゃ必須だから。
ピストバイクは危険だからなくそうって言ってるようなもの。

まだやってんのかよ。もうええわ

>>165
いやそういう話じゃなくて、関数もメモリー上にある以上
普通に関数へのポインタもあるわけよ。

ファイル名をTXTからEXEに変えるだけで実行するOSとか
データの領域とプログラムの領域を分けない言語とか
たぶん、時代遅れ。

引数として関数ポインタを渡すなんてのは標準ライブラリ関数の中にでもあるだろ。

>>169
> データの領域とプログラムの領域を分けない言語とか

言語でどうやって対処するんだ？
言語が決めたとすると、リンカが領域決められないから、そもそもリンクできないぞ。

時代が移り変わっていくんだな・・・

Cの言語仕様はコンパクトでシンプル。
Cで躓いてしまうような人が、C++やC#やJavaの複雑な言語仕様を理解して使えているとは思えないな。

蟹飯＆立地ー

>>140
同じわけないだろｗ　もし同じなら　その会社があほ

ポインタのあるべき姿は、オブジェクトを参照する情報であるべきであって、
そのオブジェクトやその内部がメモリの上に乗っている番地（アドレス）
であってはあまりにも原始的すぎるし、リロケーションが効かない。
構造体のメンバーや配列の要素をポインタで直接指せるのも有害。
構造体を指す、配列を指すことは当然出来てよいが、
その内側を直接指せては、安全なプログラムにはならない。

Ritchieさんは、ANSI C風じゃないC言語を使っていたな。
元のK&RでもないPlan 9で新しく作った奴。

最低でもコードと、データとスタックその他を分けないとROMにも焼けないじゃないか。

>>176
＞ポインタのあるべき姿は、オブジェクトを参照する情報であるべきであって

それは例えばPascal流のポインタだね。
ポインタとはどう在るべきかという発想で行けば、
Pascalのような抽象化されたポインタの方が美しい。

けど、そのポインタじゃOSは書けない。CはOSを書くために開発された高級言語なんだから、
「ハードウェアを隠して抽象化されたポインタ」なんて
Cが作られた目的や用途からすれば本末転倒だよ。

>>176
Cはともかくとして、C++ではポインタがメンバ関数を指せることで
汎用性が高くかつ安全なメッセージマップとかが記述できるようになってるよ？＾＾

メンバ関数ポインタバンザイ＾＾

苦労してせっかく得たノウハウを、こんなところで惜しげもなく教えてしまうのが
Geekどものあさはかさ
人間関係が不得手で、承認欲求とやらが強いのと、処世が下手で警戒心が弱いのか
バカだなぁ

Cのノウハウの話なら、ココに出て来た程度の物は
昔の本に詳しかったけど、絶版が多いね。

今はC++がその後釜に入ったからCのノウハウなんて欲しがる奴居ないだろｗ

>>146
書いたのはカーニハン。
リッチーが書いたのは付録Aだけ。

だが、その付録Aが本文に負けず劣らず良かった。

Ｃもいいけど、オブジェクト指向、デザインパターン、ソフトウェアアーキテクチャなどの高次概念も
きちんと教育しろよ。ポインタで躓いているようでは先が長い。

ポインタより開発環境の使い方の方が、俺にはよっぽど難しいわ。

>>173
C言語では、出力されるアセンブラコードを想定できるぐらいバリバリ使えても、
C++やC#やJavaへはついていけないのもいるけどな。



わしじゃ。クラス名とかが面倒で覚えられん。ポインタとprintfさえ使えればがんがんプログラムが書けたあの時代が懐かしいわ

ポインタをν速にあててカーソルをフェッチするんですね　わかります

やはりポインタの機構はワンクッション置いて参照カウンタなども背後に持ち、リロケーションも自由に出来る裏側の仕組みを持つのが安全。Ｃ言語は所詮
アセンブラプログラミングと同じ仕組みを直接提供しているのに過ぎない。
システムプログラマ用の言語を汎用言語として一般アプリケーションプログラ
ミングにも使うという方向は、間違ったトレンドであってソフトウェアの安全
性を無視したもので感心できない。単なるスピード競争だけが頭にあって、
安全性を無視した自動車のようなもの。

>>184
IDEのめんどくささといったらない。
でもJavaとかはIDE使わないと生産性落ちるという。
つーかそれって欠陥言語なんじゃね？と思ってしまう。

実用面から言えば、pythonとかのスクリプトの方がいろいろ出来て楽しい。

Cプログラミングで遊びたいなら1チップマイコンやった方が楽しいよ。
arduino互換のマイコン基板ならCをより簡易化した言語で遊べるし。

Core2Duoのintって、なんbit？

GUIのインターフェースは面倒なんだからさ、
CGIでやることにすりゃいいんだよ。
趣味でプログラムするならこれお勧め。

>>187
そう思うんなら、C 使わなきゃいいだけじゃん。
４０年前にほぼ完成した言語に拘らずに、今なら、代替できる言語が腐るほどあるわけだし。

C を批判するってのは、C を使わなければいけない場面で、より良い選択肢を提示するってことだから。

>>187 は、C を批判してるわけじゃないね。スマン。
でも、似たような論理で、C を批判した気になってる奴がウザかったので、つい。

正直CもUNIXも嫌いだった。
全編小文字ﾊｧ？スカしよってからに
表示がcatとか頭膿んでるのか？

そうLinuxに出会うまでは…

そしてからぶん投げてたK&R読みなおしたよ
ゴメンネRさん。ぼっくんミーハーで(*´ω｀*)

その昔、アセンブラからCへ移行する人ならK&Rを理解しやすかった、そんだけの話。

>>194
逆でしょ。

当時の処理系では大文字固定とかが多かったと思う(Fortranとか)。
CもUNIXも混在出来た。

AVX2に期待AGE

>>195
K&Rにはアセンブラの話なんか殆ど出てなかったよ。
UNIX環境を前提としたサンプルプログラマが多かったから、
UNIXを知らない/触れる環境がないとK&Rを読んで理解するのは辛かっただろう。
アセンブラプログラマが読んで理解しやすい本とは思えないなぁ。

当時K&Rがバイブルだったのは、ANSIでCが標準化されるまでは
あの本がCの事実上の言語仕様書だったからだよ。

>>195
ぶっちゃけ、Cコンパイラとは超高機能マクロアセンブラではないのか、と思う。

>>187
＞システムプログラマ用の言語を汎用言語として
＞一般アプリケーションプログラ ミングにも使うという方向は、間違ったトレンドであって

やべ、アプリをCで書くのがトレンディだったのか
乗り遅れてたぜ

高度に組みあがったマクロアセンブラのコードって今はネットでも見る機会ないよね。
昔、PC雑誌で見て感動したものだ。
値段がすごくて試せなかったが。

>>198
試す環境がDOSでも組み込み用ターゲットでも、
信用出来るのはK&Rしかなかったし、それで必要十分だった時代の話だよ。

俺の綽名はペニス・リッチなんだが、なぜか親近感を覚える。
ご冥福を祈る。

アセンブリ使いでも向いてない人はいるよね？

そんなヤツがC使うと、ポインタ型と整数型を無頓着にキャストしたり、
構造体の存在自体をシカトして配列オンリーでデータ構造作ったり…

ソースコードが悲惨で怒り狂ってデバッグやったよ。

>>33
free関数などなくても配列は自らの散り際を心得て切腹する。
でもたまに失敗するから、介錯関数が実装される。

>>204
Windows APIディスってんなよ

>>50
世の中には、Cで炊飯器の制御プログラムを書いてる
人間もいるのだよ。

>>205
リファレンスカウントとマーク＆スイープの組み合わせ GC じゃん。

>>33
スターリング＆ギブスンに、またディファレンス・エンジン並みのつまんない小説書いてもらうか
黒丸尚が死んじゃったから、誰も訳せないかもしれないけど

>>190
32ビット

>>206
＞>>204
＞Windows APIディスってんなよ

クソワラタwwwwwwwwww！

ジョブズなんて、いなくても何にも困らんが、この人は地味にスゲーな。
知らんかった、合掌。

>>121
マジレスすると一番簡単なのはこれ。
cat /dev/audio > wave.bin

二番目がこれ。
dd if=/dev/audio of=wave.bin

>>210
メガドライブなみか。

>>201
大昔はロハだったよ。大惨事オンラインのころ。
マイクロソフトがプログラムにも著作権があるので金だせと言う前の話。
COBOLのコード効率、性能ではこなせないのでアセンブラが多用された。
つってもPACK形式の四則演算命令があるようなマシン語体系の時代。

>>145
Symantec C使った記憶が。

AIX7.1・・・・・・・・・・・

言語を考えたヤツは天才
プログラムなんて誰でもできるが

「初めてのC」世話になったなｗｗ

おぉ5スレ目かぁ
嬉しいねぇ

ThinkCをsymantec社が買いとった。
その前はlightspeedCっていってた。

ベーマガ廃刊の時もずいぶんスレ延びたよな

>>190
処理系依存

C90で止まってる人が結構いそう

K&R CってANSI Cと引数の記述の仕方が違っていた記憶があるな。
思い出せないしもうどうでもいいけど、pとかqとかiとかjとか意味のわからない変数の命名法だけは
今も参考にさせてもらっているよ。
R.I.P.

>>189
スクリプトには限界があるからなぁ。

ざまあ

初期の信長の野望はよくぬるぽで落ちたのを思い出した。
ラティスで作ってたんだよなあ。

まあ当時はなんていうか処理系の存在そのものにすごく感動したなあ。
かっこよかったんだよなあBasicとか子供だましのように感じたし。
masmとかms-cとか馬鹿高いのをバイク我慢して買ってたよ。

リッチーさんやすらかにお眠りください。
カーニハンさんもご自愛ください。

Segmentation fault(core dumped)
なつかしい・・・

Cは危険だ、ポインタは危険だなどと言うが
理想と現実を、安全性と処理速度の速さ等を
天秤にかけて絶妙のバランスを取ったのが
Cのコンセプトなのに全く的はずれな批判だろ。

>>225
こんな感じだったよな。うろおぼえ。

func
int a;
double b;
{
・・・
}

>230
例えばヌルで終端された文字列という方式をとったことは、
非常に安全性を損ねているし、（事前に文字列の長さを知る術が
ないので）処理速度も稼げない。ヌル終端文字列という方式の
ために、ＡＳＣＩＩコード以外の文字列表現ではなかなか苦労
するし、また文字列を格納する場所が十分に用意されていなくても
それと分からずメモリに書き込んでいってデータやプログラムを
壊してプログラムを暴走させたり、結果が不正になったり、
プログラムの動作を改竄したりできたりもする。
ポインタがオブジェクトを指すのではなくてメモリの番地を指す
だけの機械語と同じ原始的で直接的な方法だけを提供した結果だ。

>>232
そんなこと誰でもわかってんだよ
承知の上で実用性とのバランスを取っただけ

>>232
＞（事前に文字列の長さを知る術がないので）処理速度も稼げない。

いやこれはおかしいだろ

>>228
一番最初の「信長の野望」はBASICだったよ。
ひでぇスパゲティ。

>>232
最後の２行が言いえている。

>ポインタがオブジェクトを指すのではなくてメモリの番地を指す
>だけの機械語と同じ原始的で直接的な方法だけを提供した結果だ。

その「だけ」のおかげで、アセンブラの代用として応用が利いた、
ＯＳも書けた、と言えない？

我々庶民が、小手先で小さいプログラムを作るとき
（必要あれば、毎回、1から作るので）
「再利用」とか、「可読性」とかないから
BASICとかで十分

グローバル変数万歳

>>237
Ｃ言語でグローバル変数使えばいいじゃん。

Cの嫌なところ

「**.h」をはじめとして、本体以外のファイルを追っかけないと
大事なところが見えてこない

{{{}}}}}が多すぎて、っていうか、めんどくさいから
コンパイラにかけて　}　の足りないのを教えてもらう

>>239
そんなのJavaにくらべりゃマシ。
事実、IDEのサポートがないとJavaは使い物にならない。

何かさ、このスレ、
軽トラ（Ｃ言語）とフル装備高級車（後発のオブジェクト指向プログラミング、OOP）を
同列に比べているような感じがするね。
昔アセンブラしかなかった頃、Ｃのおかげで他システムへの「移植」という、
夢のような（？）ことが可能となり、その後随分経ってＯＯＰが出てきたわけで。
アセンブラ時代でもマクロを駆使してＯＯＰ（的コーディング）している人いたけどね。

あくまでＣ言語は、アセンブラなどでゴリゴリとプログラムを書いていたような方々
（つまり、パソコン自体の仕組みや構造を理解していた方々）が手間を省くために
開発された言語であって、パソコンの初心者でも易しくプログラムを書けるように
作られた言語では全く無いからね。

組み込みのC言語使い始めたころはアセンブラ出力を毎回確認してたなぁ。
K＆Rからの移行期で良く間違ってたし割り込み処理が何サイクルになるか気になって。
if(式)の式で二項演算以上のことすると大体間違ってた。
White simith C。。。。

>>236
OSが書けるというより、もともとOSを書くために作った言語だからね。

OS自身を記述するためには、物理アドレスを名指しで指定して
Read/Writeできる機能は絶対に必要だし、
それができない「安全なC」なんて自己否定もいいところだわな。

OSを書くために作った言語
に徹すればいいのに
普通のアプリからウイルスまで手広く作られてしまうのが実態

chomp; chomp; chomp;

Cだと大きなアプリが作れないと思ってるバカがたまにいるんだよな
C++やJavaを使えばそれが可能になると
んなわけねーよｗバカはどんな言語使おうがせいぜい1000行ぐらいのアプリが精いっぱい

>>165
RISCプロセッサってみんな実行中スレッドのメモリ上の命令書き換え禁止なんだよね。パイプライン制御が保証できなくなるから。
PAーRISCも同じ。
ところが本家のhp-ux kernelの中ではやってたのでびっくりしたことがある。

プログラムの大きさを「行」で表現しちゃうところが…

今では、if 文の動作を信じて（信じてあたりまえなんだけど）
恐っろしい長文を、ブロック {} も使わずに書くヤツいるね。
１行の中に沢山詰め込む。特にアカデミック系。
そりゃ言語的に、そう書いても正しいんだけどさ、みたいな。

>>244 >>245
OSはカーネルのみから成り立ってる訳じゃあないし。
UNIXのユーザランドの数々のコマンドも、ある意味Cの思想。

UNIXが流行らない理由は、どこまでがOSで、どこまでが「ユーザーのもの」なのか
切り分けが無いから。

アプリが動かなければカーネルを直そう！

120秒前の訂正 UNIX →　linux

>>250
if（a == 1）{
if（a == 1）{ /*念のため*/
……


ifを完全に信用していない人が、本当にこんなコードを書いたとかw

>>248
あるとすれば、キャッシュ・コヒーレンシーの問題。
インストラクション領域が変更されないことが保障されていれば、iCache の制御が若干、楽になだけ。
キャッシュがサポートして無くても、一旦、iCache を無効にすれば、問題ないと思うが。
特権モードでも書き込み保護される物理アドレスって、普通はないはずだけど。
DMA でしか書き込めないのか？
そもそも、MMU をパスしてると、テキスト領域とデータ領域の区別はないはずだし。

>>252
実際にそんな例があるのか？
Python みたいな複雑なプログラムでも、そのために Linux のバージョンが変わったなんて
聞いたことがない。

>>252
UNIX/Linuxわかってないということはわかった。

（UNIX, C言語の始祖）Dennis Ritchieから学ぶべきこと
http://jp.techcrunch.com/archives/20111015what-can-we-learn-from-dennis-ritchie/

>>255
キャッシュを無効にしてまでやるものじゃないわなぁ…

>>235
そうそう、よく勝手に改造して遊んだｗ

5スレ目まで読んで思ったこと
Pythonがこんなにメジャーだなんて知らなかった

むかしいた会社で、俺が新卒で無知だったのを知って、知識をひけらかしにきた先輩がK＆R覚えた？とか聞いてきやがって、3年後自分が知識を持ったのちに、その言葉を振り返ると、今はANSIがほとんどだろとソイツにツッコんでやりたい

>>96
後から構造体を使ったとき、今までの努力はなんだったんだと思ったよ
構造体を使えば一々操作を書く必要がまったくない
できれば構造体のみでプログラムを書きたいぐらい
そこでプログラムの勉強を放棄したんだけど、また始めようと思ってる
このスレは再入門に本当に最適だから終わるのが惜しいな

>>260
え、PythonはGoogleの3大言語のひとつだよ？
確かに日本ではマイナーだけど普通に使ってるプロは多い。

>>263
すまんね、IT業界から離れて長いもんでのう（´･ω･｀）

>>257
やっぱり最初の原動力は「ゲームがしたい」だよなあw
俺がアセンブラに手を付けた理由もそれだった。

>>262
オブジェクト指向はご存知？少々語弊があるかもしれないけど、構造体のみでプログラムを書くという
発想がそれに近いと感じたから。

>>258
書き込んだ直後に無効にするだけでいいよ。
一次キャッシュなんて、仮想アドレスでキャッシュしてたら、タスクスイッチで破棄されるんだから。

>>255
>>252は完全に知ったかぶりのど素人の可能性が99%くらい、
あとの1%くらいは、ドライバを作ってる作業員。
どっちにしろかなりの低能。

>>222
ベーマガ廃刊したのか！！！！！！

確か、ざべって名前に変わってから廃刊したんじゃなかったっけ？
その昔、I/OとかRAMとかマイコン雑誌がいっぱいあったが、
曲りなりに残ってるのはアスキーだけか。

いや、ざべとベーマガは別物だろｗ
確かざべの方が先に休刊した覚えが

C MAGAZINEとかUNIX USERとかUNIX MAGAZINEとか
以前はCやUNIX関連の雑誌が色々あったね。

ざべはThe BASICだろ。

昔はフロッピーのプロテクト破りばっかりやってた。

後に「電脳曼陀羅事件」が起きる。

>>234
文字列の連結したいときに、いちいち終端文字列探さないといけない。

>>255
組み込み用途とかだと、アプリじゃ対応面倒なのは
カーネル弄っちゃえってのはよくある。Linuxに限らずだと思うけど。

>>243
出始めの頃は、
コンパイラが悪いのか、
ICEが悪いのか、
ソースが悪いのか、
ターゲットが悪いのか、
マジでカオスだったｗ

ソースとターゲットは悪いのは当たり前だけど、
ICEが悪いってのを目の当たりにし、
毎回ダンプリストとにらめっこしてた事がある。

>>274
終端に突き当たったら処理を終わればいいだけで
あらかじめ長さの情報はいらないだろ。

というか高級な文字列型って文字列生成時に
長さの情報を付加する処理をしてるんだろ。
つまり先にやるかあとでやるかの違い。
しかも長さの情報がいらない文字列に対しても
その処理をしてるわけで全体の処理は遅くなる。
長さの情報を付加する分メモリーも余分に食う。

>>268
低能な奴がドライバ作っているのか？ｗ
どこのWind(ry

>>232
パイプ処理される時に、
長さを最初に知る事なんて、不可能。

>>260
Pythonはなかなか良いよ
読み易いし、ライブラリが充実している
アプリを組むだけなら、是非お勧めだ

但し、実行速度は遅いのでそっちで
シビアなものを作るならC/C++で十分

>>237
pythonお勧め
日本語がちょっと面倒だけどな

>>277
文字列上を全て探索する場合と、別に長さ情報を持っておいて参照するのとでは計算量は違うよ。
前者は１つずつ比較していかなきゃならない。後者は割り当て時にその数値を記憶しておくだけだから総比較は最初から不要。

もちろん、それだけでどっちが優れてるかってことにはならないけど。

Pascalなんかは最初の要素に文字列の長さを格納していた。このため文字数に制限ができてしまうんだけどね。

>>158
その発想だと工業の分野はまったく成り立たない
工業、特に機械加工に関しては名人芸によって成り立っている
逆に名人が無くなれば、機械文明は終わる

自動車のボンネットをきちっと開け閉め出来るように
ハンマーでポンポン叩いて調整するようなことは
残念ながら機械には出来ない

リッチーのスレなのに、スクリプト言語への勧誘が多いな

>>277
char buf[1024];
buf[0] = '\0';
strcat(buf, "Hello");
strcat(buf, "World");
strcat(buf, "!");
こんな単純なコードでも、strcatの実行ごとに
1,6,11バイトの走査が行われる。
→処理速度が稼げない。

>>285
いや自作の関数使えばいいだろ

どんなアルゴリズムでも、O(N)下回ることはないだろ。
特化したアルゴリズムとかはまた別の話。

286が言いたいのは、そこまで処理速度を気にするなら
文字列長で管理する文字列を自分で実装すればいいだろ、ということじゃないの？

賛成だ
もともとC言語の文字列操作なんてあってないようなものなんだから

Cが採用した文字列の方式は速度よりメモリ効率重視で、そのほうがC言語開発当時の実情では合理的だったんだよね

だいたいC/C++の処理が遅いって言うなら
なんで処理速度重視の場面で使われるんだよ。
効率の悪い連結の仕方をして効率が悪いって言われてもな。

>>235
ああ、大戦略だったかもしれん、あやふやでｽﾏｿ

でもK&Rってソウルでファンキーだよね。
こういうBGM感覚なんだよなあ。
最近だと、仕事ごとに言語とか環境とか違うけど
昔読んだ本とか思い出すといまでも震える。

いまプログラム始めたやつってそういう空気感性ってあるんだろか。

>>289
何を言ってるんだ？とんちんかんだな

>>291
いやだからそもそもの発端が>>230と>>232なんだよ

Cに文字列なんてないよ、単なるchar型の配列だよ
そして配列はちゃんと長さ情報を持ってるよ
実際、sizeof( char[5] )はsizeof( char )の5倍のサイズだよ
ただ、配列は（K&R的に言うと）定数なので、
参照にポインタを使い、その時に減衰するから長さ情報がなくなるだけだよ
関数が減衰を無視して長さ情報を取得しないから
長さを利用した最適化ができてないだけじゃないかな？
実際、構造体に封じ込めて置けば減衰しないから、
変数をコピーしても長さ情報を利用できるよ

…っていうような話じゃないんだろうね＾＾
文字列リテラルにも長さ情報はあるけど、文字数+1なところが
直感的じゃない気はする＾＾

俺には>>230に対する>>232のレスの方がトンチンカンに見える

まあ、Cは高級化したアセンブラみたいな言語だしなｗ

コンパイラによっては、文字を変数宣言時に初期化しておくと、
コンパイラが自動的に文字数を定数として使ってmemcpyしてくれるのも
あった気がするけどな

１０年以上前のことではっきりと覚えていないから自信はないが

>>292
理解した。そのやりとりなら>>232の方が訳わかめだ。

そんなに難しく考えなくても
増分が指定されたラベルと考えれば、

って釣られてる？
配列表記は裏メニュくらいに考えとけばいいのではと。

またポインタで揉めてんのか。懲りないねぇ。

CとかC++とかパズルみたいで面白い

フィトンってタブで整形しないと動かないとか、単なる色物レベルの言語だと思ってたけど、実際はそうでもないのか。

int main (void)

おまいらKコンパイラのことは忘れたのか？

このスレッドだけスラドっぽいなｗ
愛すべきAnonymous Cowordだらけだぜ。

ｋコンパイラで、どうしても円運動させたくて
配列にSINの値を1バイトの整数の表して書き込んで
三角関数のサブルーチンを作った遠い日の想い出が・・・・

>>285
http://codepad.org/1lrJAtu4
こんな感じでどう？

なんか game コンパイラを思い出した

>>278
WindRiverがどうしたって？

>>305
この際これでもいいんじゃ？
http://codepad.org/yBo2l0M1

>>308
まだ削れた
http://codepad.org/lwirFMYr

これでもっと早くなるのかな
http://codepad.org/0neN34IK

>>305
これは駄目だろ。buf[1024]の範囲内で上手く動作しているが
付け加える文字数がbuf[n]のnを超える使われ方をしたら、どうなることやら。

>>311
要はその辺はプログラマが管理する代わりに
効率を重視してるのがC/C++の利点なわけだよ。
だからそこを批判するのは的外れなんじゃないかなと。
プログラムが多少重くてもいいならJavaなりC#なりを使えばいいんだろうし
そうは行かない場合にC/C++を使ってるわけだから。
シビアな状況でJavaとかC#しかなければ困るだろって話。

>>312
余計な機能をつけると遅くなるもんな。昔のCコンパイラとか８文字超えると無視されるとか、
日本語が通らないのでコメントも全部似非英語を使うし、ネストが８つ以上になるとスタックの限界で落ちるとか。
ハードの制約と併せて効率が重視されたわけで、色々と限界を見せつけられる仕様だったなｗ

その頃からとりあえず仕様通りに動けば問題ない、というイケイケ開発が主流だｗ

>>310
あーあ…やっちゃってるよ…18行目バグあり
bufがたまたまオール'\0'で初期化されてるかなんかだろうな
直しといた
http://codepad.org/uA17POaq

>>310
バグもあれだがそれinline展開できないだろ。
まあコンパイラに無視されるだけだが。

>>314
終端文字'\0'はmain()ではなく、strcat2()の中で追加しなくちゃいけないと思う。

ポインタっていうのは定数にできないIOストリームのバッファポインタのときに
やむをえず使うものであって
それ以外のところでポインタを使うから訳がわからなくなる
こんな定数の連結は速度重視なら定数として最適化されてしまうべきだし
こんなサブルーチン記法のためにすぐポインタを使うのがCの犯罪といっていいと思う

>>317
ポインタを使わないとコンパイラが吐き出すコードが複雑になる
ポインタ自身がスタックポインタのような役割をしているから、
生成されるコードが非常にシンプルで速度を稼げる

Cの言語仕様がチープであるということが、速度を速めるということに
貢献しているわけだ
これ以上を望むならアセンブラでガリガリプログラムを組むしかない
それ以外は選択肢にすらならない

逆にPythonのようなスクリプト言語、LLなどが注目されるのは、
速度を必要としない簡単なプログラムであればCを必要ではないからだ
つまりニッチな需要に答えられた
それ以外のプログラミング言語も、結局C/C++の隙間を埋めるために
存在しているという状態になっている

形式的意味論みたいなのやってる先生もCより速いプログラムを書く言語を作るのは無理っていってまつ

>>318
知っての通り、メイヤーのEffective STLには最高670％という実測結果を伴って
CのqsortよりもC++のsortの方が早い理由が示されている。従って、
「Cの言語仕様がチープであるということが、速度を速めるということに貢献している」
という説明には「プログラマがアーキテクチャに最適なコードを書いた場合」
というエクスキューズをつけるのがフェアだろうと思う。
javaのガベージコレクションについても同種の結果が示されている。

とはいえ、Cが最適化困難でライブラリがプアであることは罪ではなく、
現実との妥協の産物にすぎない。大概の言語はそういうものだ。

>>312
よほど確保・解放の時間やメモリ制限を気にする場面（HTTPサービスとか構文解析みたいなの）
でない限り、C++ならstringやwstring使うよ

トークンセパレートやレキシカルアナライズでポンターのポンターは普通に使うんでねぇの？
CのOOPだと、ポインターのポインターのポインターと重箱のようだぞ！

>>318
もう10年以上も前からCのほうがニッチだと思うけど。

>>316
そうだよな。>>314は、やってることがみみっちすぎる。部品化できないんじゃ、関数にするメリットがない。

>>314
もっと行数減らしといた
http://codepad.org/WFuQLSp4

buf2はいらなかった。
http://codepad.org/3UM9Rbyt

関数名も短くしといた。
http://codepad.org/lBlTXi58

http://codepad.org/Ew3fOB6r

意味がわからないような関数名、仮引数名をつけるのは悪

一人でちょこちょこやる分にはなんでもいいんだよ

>>314 >>325
変な書き方をすれば良いのか？

ttp://codepad.org/BdLlvscF

意味のないコードをどや顔で語られても・・・

>>328
これって、*bが'\0'かどうかを最初に必ずチェックしなくちゃいけないんだから
http://codepad.org/fbiTcZb7
ってやればいいんじゃないの？
そうすればmain()で'\0'の代入しなくて済むし

C++ならまだしも、C言語だとISO準拠の標準スタイルでは
プログラムの開始をmain関数とし、引数がない場合は
int main(void) と記述されてる。
C++だと int main() と記述されている。

>>334
「パソコンマニアは冬眠しよう」の議論を思い出した。
mainは冒頭でなければ許されないのか、という話。

>>328
>>333
なぜおまえらはK&Rにもある由緒正しいwhile(*a++=*b++);をかたくなに使わないんだよｗ
リッチーのスレなのに

>>336
それだと、Hello までしかコピーされない

可変個の文字列を繋げるようにしてみた
http://codepad.org/PSNQ9Q5y

おまいら、ここはニュー速板だぞ。w

>>337
そんなの return --a;にするだけだろ

それよりか速度重視なら関数呼び出すときのスタックのオーバヘッドがもったいない
while(*a++ = *b++); a--;を並べてポインタにはregister修飾子をかませとけ

inlineやconstを知らないとか、K&Rさえ読んでりゃおｋな意見が見られるあたり、
C99まで使ってないか、よほど不勉強か、どちらかの人が多いんだろうなｗ

なんでCって文字列をつなげるだけで3日もかかるんだろ

文字列を順々につないでいくだけの処理をチューンアップして何が楽しいんだ。
さあ、コーディングの作業に戻るんだ。

>>3

じゃあボインダの話題で

むしろこのスレでK&R範囲外でやる意味がわからん

>>340
constはC99より前だろ。

つなげると言えばUNIXのパイプ機能。

sort,grep,sedなどの複数のコマンドをパイプで繋げて
目的となる操作を実施する事にはGUIとは違った快適さがある。

combination of small programsで目的の処理を果たすことが
UNIXの基本コンセプトのひとつだからね。まさに醍醐味ですな。

while(*a++ = *a--);

Cが普及した理由の一つが、言語仕様で扱う範囲を小さくしたってことだろうな。
I/Oや数値計算といった基本的な機能も、標準はあるけどあくまでライブラリとして扱うことで
標準が使えないような環境にも適応できるようになってる。

LispやCは規格が決まる前の方が楽しかった

ポインタは、インスタンスを作らずにただオブジェクトを代入するとオブジェクトのように
ふるまう変数として扱えてしまい、オブジェクトではなくてクラスのようなものなのに、
そこらへんの区別が文法的にあまり明確じゃないし実に粗末な仕様の言語だよ

Cは元々オブジェクト指向言語じゃないし

＞オブジェクトではなくてクラスのようなものなのに
どういうこと？多分Java使いなんだろうけど・・・
C++使いの俺からするとクラスは型、オブジェクトはそのインスタンスと捉えてるから、
あんたの言いたいことがよくわからない、もうちょっと詳しく説明もらえるかな

OOPを盲信するあまり、何でもOOPで解釈しようとする奴っているよね

ぶっちゃけC/C++でポインタの理解に挫折してからJavaに行った人じゃないかと思うけどね
多分C++/Javaにおいて、クラスのメソッド呼び出しや参照からのアクセスが内部でどういうコードになるか
全く想像が出来ないんだろうな、内部的にはアドレス呼び出しによる間接アクセス無くては計算機は動かないというのに

逆にC++に挫折したC使いがC++のOOを、知りもせずに嘘八百で否定するのも簡便願いたいんだが、
ここで言うことではないか

>>336
ああ、あったな。すっかり忘れてた。
でもそれだと結局単語をつなげるたびに毎回
a++;b++,a--;って3ステップも余分な処理が入るんじゃないの。

ああでもよく考えたら
while(*a++=*b++); a--; の方は最後に a++;b++;a--;が余分だけど
while(*b) *a++=*b++; 最初に *b != '\0' の判断が余分なのか。
差し引き2ステップ？

まあわかるような差はでないなｗｗ

歩行珍煙は逮捕でいいよ

よくわからんが、高速に文字列の連結とかしたいのであれば、それに、適したデータ構造つくればいいんでないの？
実体へのポインタと長さか、実体へのポインタと終端へのポインタとかｗ
あと連結操作時に実体を移動、コピーしなくていいようにリンクリストつけとくとかw
頻繁に追加削除があるのか、生成のみなのか目的によって最適解は変わってくるが、cなら自由自在、おまいら得意だろw

今の世の中、「小手先の速い」は不要で
それよりも「安全・確実」が求められていると思う
（forとかwhileとかも全部展開して、1本糞のようなプログラムが一番速いのは当然）

どうせ周辺機器とかネットとか、大半待ち時間なわけだし、
速さの追求は「もっと高い次元のアルゴリズムの改良」で

>>361
今の世の中ってひとくくりにするのはすごいな。
適材適所でしよ。
同じプログラムのなかでさえ、安全可読性重視と速度重視を使い分けるやつもいるよ。

カアニはんはお元気どすか？

蟹飯のコメント有った？

>>362
その通り
未だにC/C++のプログラミング多く、他の言語に置き換わらないのは需要があるから
速度の速いプログラムが求められる分野が非常に多い
ゲーム、組み込み系、通信・マルチメディアなどはC/C++から他の言語に移ることはあり得ないと
言っていいくらい安定した需要がある

Web系のように速度をあまり必要としないものにはCを採用する理由はない
C/C++以外の言語（例えばJava,C#,rubyなど）が出てきても、未だにシェアがNo.1で
揺るぎないのは何故かを考えればいい

あるいはこう考えてもいい

速度の必要としている分野は広範囲に存在する
だが、アセンブラではメンテナンスが大変だ
したがって、アセンブラの代替品としてC/C++を利用する

カーニはんは元気なのか？

>>365
c/c++？
cのみだろ。

安易にc/c++と書くのってどうなの？
特にこのスレで。
リッチーはC言語の父であって
c++は関係ない。
むしろ、リッチーの盟友がやってる
goというシステムプログラミング言語があるんだから、
c/goならまだわかる。

>>368
cとgoはだいぶ違うでしょ…

しかしgoもいまだにフリーフォーマット言語なのが解せぬ。

>>368
トンプソンの B 言語があって、リッチーの C だからね。
C(4) -> go(5) で、語呂も合ってるし。正統な後継者だな。

でも、B が普及しなかったように、普及するためには、go の次世代言語の登場が必要かな。

＞C(4) -> go(5) で、語呂も合ってる
え？／(^o^)＼

C++は他のオブジェクト指向言語の登場で、
利用者数が世界的に減少傾向にあるね。
コンパイル最適化が難しく、Cほど低レベルでなく、
JAVAやC#ほどRADでなく…マシンの進化とコンピュータのコモディティ化で
何でもできるマルチパラダイムがだんだんアダに。

古い原著から．．．

main()
{
　printf("hellow, ");
　printf("world");
　printf("\n");
}

で、
main()
{
　while(1)
　{
　　xxxx();
　}
}

この文がビギナーをことごとく駄目にしてきた。
時間のスライス表現の無い教科書をバイブルとしてきたことに問題有り！
UNIＸ創生者なのに、ディスパッチャーを彷彿とさせる表現にしなかったのはペケ！

>>370
goで書いたOSが普及すればいいんだよ。

Linuxのつぎがそれだ。
そしてまだ誰もやってないが、
Googleあたりが作ってるかも。

まあなんていうか昨今OOPだから
若い奴はそこで思考停止してる自分が認識できてないだけだろうね。

>>361
アルゴリズムを詳しく扱っている本ってあまり書店では見かけないような…
「車輪を再発明するな」というのは仕事の効率や能率の上では正しいのかも知れないけど
巧妙なアルゴリズムは、先人の知恵と工夫の結晶なんだよね。
中身を知らずに成果だけ使っているのは何か寂しい。

K&RがCのバイブルなら、The Art Of Computer Programmingはアルゴリズムのバイブル。
いつかは買い揃えたいと思っているのだが…

>>375
今はデザパタだったり、得たい機能が最初からあったりするから不要になったと思われ。
構造化プログラミング時代の本を漁るしかない。

デザインパターン　=　かつおぶし

間違ってはいないけど、袋に入ったフレークの由来に
想いを馳せれなければ、そこで道の終わり。

>>377
職人の道としてはそれが正しいと思うけど、
今はその「フレーク」より前を考えないのが流行り、主流だと思ってる。
単純な「フレーク」ならその辺に転がってるのを使うだけ。

>>376
プログラミングという枠組みじゃなくて、工学という枠組みで見れば今でもアルゴリズムは有用だよ。
専門的になりすぎて、一般的なプログラマが扱う範囲を超えてるとは思うけどね。

デザインパターンとアルゴリズムは別物だが。

アルゴリズム？
真っ当なプログラムを書くなら今でも必要だろ。

でも今はそんなアルゴリズムよりイベントドリブンで入ってきたパラメータを
処理する手合いのプログラムが多いことは確かだ。

誰も書き込まなくなったな
このスレもＣんと静まり返っている

誰にレスするでもないけど、
「うまいアルゴリズム」と
「ちょっと気の利いたコードの書き方」とが、
混同されてる感じはあるよね。
つか、もともとシームレスなもんかも知れんけど

そういう意味では、たとえば>>381後半の
パラメタの仕分けなんかも、アルゴリズムっちゃ
アルゴリズムかと。

>>379
同意。

今時は、プログラミングその物が目的じゃなくなってるから
そういう意味ではパクれる物を素早くパクって目的を達成した方が良いと思われ。

プログラミングその物が目的なら、より効率的なアルゴリズムの追求や、
コードの短縮化や小容量化で楽しめば良い。

昔はソートのアルゴリズムとか定番だったけど、
今はSTLだったり、メソッドで提供されるから話題にもならない。

それでもたまに基本的なアルゴリズムを自前で組むような場面はあって。

まぁソート機能くらいならネットを参考にすればすぐ組めるんだけど、
なんでバブルソートなんか参考にするんだよってのはよくある。
しかも、この道10年のプロとかで。

>>385
この道10年とドヤ顔する事と、クイックソートは関係無いと思われｗ

>>384
個人的には、その「パクれる物を素早くパクって」って言い方、日本人プログラマの悪いとこだと思うんだよなぁ
誰か、あるいは先人がフリーでアイデアやコードを公開してくれたからこそ、知恵を借りられるわけで。

じゃあどういう言い方すべきかってーと、「ぐぐれ」「車輪の再発明をしない」とかかな
今は目的も多様化されてるし専門外のことをやることも多いから、
細かいテクニックにこだわるより「必要な情報を調べて見つけ出す能力」の方が大事だ
ただその一方で、こだわる場面ではこだわって、また可能な範囲で知識を独占せず公開していくことも
日本のIT業界の発展には必要だと思う

全然分野の違うことなのに比較しても仕方がないだろ。
アルゴリズムに精通してる人が、長期的な保守性や可変性を考慮した
ソフトウェアアーキテクチャなどに精通してるとは限らない。

あと他人が既に作ったものは遠慮なく使わせてもらえばいい。
全部自分で作るやつなんていないだろう。ＣＰＵから全て自分で生産しないだろ。

アルゴリズムだって自分で編み出すよりも、普通はすでにあるものを使うはず。
それがコピペだろうと自分でコードを組むのだろうと、
クイックソートやバブルソートのアルゴリズム自体は既成の発明品だろ。
クイックソートやバブルソートを再発明しても仕方ないだろ。

結局すべてパクリでいいんだよ

実績があるものを使う方が
「最新」より安心だから。

25年前にc言語とアセンブラの組み合わせをマスターできたことが今の自分につながっている。

その後、何社か渡り歩いて、直接のソフト開発からは離れたけど、比較的楽な仕事で年収４桁万円をキープできて、子供も二人育てられた。

K&R本も含めて大量の技術書は実家の一部屋においてあるが、子供には迷惑をかけたくないので、いずれ処分するつもり。
でも、K&R本や初期のMacTutorなど捨てられない本は、いつか読み直すために、いずれ自炊する予定。

dmrさん、c言語をつくってくれてありがとう。

プログラミングも韓流だよね。

>>391
もちろんそのとおりです。K&RのKはKoreaのことです。

>>368
C++はCのスーパーセット
元々Cにオブジェクト指向の機能を持たせようという
目的で作られた言語だから、Cから派生したjavaなどとは
ちがって、Cとしても使える

言語としては異なるが、リッチーの作ったCを完全に
含んでいるし、「より良いC」という位置づけもある

C++プログラマにとってはこういういい方は面白くないのかもしれないが、
C++はCの部分が無くなれば価値のない言語になるのも事実

>>389
パクリは悪くない
だが、パクった内容を理解できなければ意味がない

例えていうなら、

「幾何学で証明する必要はない。だが証明する能力は必要である」

みたいな物だな
「三平方の定理を証明する必要はなくても、証明する能力は必要みたいな感じ

プログラミングで言えば、「人の作ったプログラムをコピペ」するのではなく、
「真似て自分で作れる」能力は必要
そういう意味でならパクリは大いにすべきだろう

三平方の定理ぐらいなら証明できていいかもしれんが、
もっと高度な数学になったら、利用するだけでもいい。

あらゆる分野をマスターするのは不可能だよ。

コンピューターを利用するのに、CPUの細かい挙動なんて知らなくていいのと同じ。
そんなものアセンブリや機械語でプログラムできるやつでも完全に理解してないだろ。

もちろん全てを理解する必要はない
本当にそれをやろうとしたら、チップの中の電子回路まで理解しなければならなくなる

だからと言って、イベントドリブンなプログラムをパーツで組み合わせるだけの能力だけで
プログラミングの全てを語ることも出来ないだろう

耳鼻科の医者がすい臓の知識を一切勉強しなくてもいいということがないように
ある程度の知識は必要になる

更に言えば、丸暗記した知識というのは応用が効かない
理解した知識は柔軟に対応するのに役立つ

分野にもよるよね
ウチは計測機器の開発やってるから、ソフト部隊といえど
回路図みてオシロあてたり、ロジアナでタイミングみたりはできてほしい
ソフトを組む上でのハードの不具合は、あたりぐらいはつけられるのが望ましい

アマゾンだFacebookだって世界で一番上のレイヤーばかり取り上げられるからハードとソフトが一緒に進む組み込みとか制御を知らない層がいるのもしょうがない
そういう人は下のレイヤーは完全なんだから知る必要が無いと思ってしまう